refactor: fcm sample app rich push

[levibostian]

No description provided.

[github-actions]

Pull request title looks good 👍!

If this pull request gets merged, it will not cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[Shahroz16]

With the challenges, we have faced with sed or other text-replacing tools in the past. The only thing that really worked for us is adding the complete file as an environment and inserting it. Worked seamless for RH and Ami apps.

Do you see any advantage with this approach rather then just inserting Env file completely?

[levibostian]

I plan to never use sed again, haha! We have indeed faced lots of issues.

I did find a popular sed replacement called sd which is what we are using here. It seems to be easier to use and doesn't have the macos/linux issues we have always had.

I came up with this solution of text replacement of a file because I encountered problems with creating a whole file as a secret. If you ever change the syntax of that Swift file, you have to update the GH secret and then all commits in your code base up to that point will not compile since the syntax changed. This happened once where Jatin updated the GH secret with a new syntax update and all previous releases would no longer compile.

I think this solution is less fragile to break and is easier to be backwards compatible.

Android has gradle build config files that make this sort of thing easier to do. iOS has something kind od similar (xcconfig files) but those have lots of boilerplate involved and complexity when using with cocoapods. Seems overkill. This is the most simple solution that I could come up with.