chore: add activity to handle push click

[mrehan27]

helps: https://github.com/customerio/issues/issues/10830

Changes

• NotificationClickReceiverActivity for handling notification clicks
• NotificationClickBehavior for customizing notification click behavior
• DeepLinkUtil updates to avoid adding unwanted flags to intents

Notes

• Intent flag changes in PR are not fully final and still being tested with all sample apps, which may force changes for flags in future PRs
• Options and default values for NotificationClickBehavior may be re-reviewed after feature changes are complete so we have clear picture of there implementation and behavior with different sample apps

[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.

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---

• java_layout: rehan/push-click-activity (1695651962)
• kotlin_compose: rehan/push-click-activity (1695651979)

[codecov]

Codecov Report

Merging #249 (e9d8395) into rehan/push-click-behavior (50cd640) will decrease coverage by 1.18%.
Report is 1 commits behind head on rehan/push-click-behavior.
The diff coverage is 7.47%.

@@                       Coverage Diff                       @@
##             rehan/push-click-behavior     #249      +/-   ##
===============================================================
- Coverage                        50.78%   49.61%   -1.18%     
- Complexity                         249      250       +1     
===============================================================
  Files                              108      110       +2     
  Lines                             2786     2858      +72     
  Branches                           366      374       +8     
===============================================================
+ Hits                              1415     1418       +3     
- Misses                            1255     1322      +67     
- Partials                           116      118       +2     

Files Changed	Coverage Δ
...messagingpush/CustomerIOPushNotificationHandler.kt	0.00% <0.00%> (ø)
...push/activity/NotificationClickReceiverActivity.kt	0.00% <0.00%> (ø)
...sagingpush/extensions/ApplicationInfoExtensions.kt	0.00% <ø> (ø)
...ava/io/customer/messagingpush/util/DeepLinkUtil.kt	8.82% <0.00%> (-0.07%)	⬇️
...ustomer/messagingpush/MessagingPushModuleConfig.kt	91.30% <71.42%> (-8.70%)	⬇️
.../messagingpush/config/NotificationClickBehavior.kt	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[github-actions]

Build available to test
Version: rehan-push-click-activity-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/

[levibostian]

Sorry, github is giving me error messages while trying to leave inline comments.

Before I leave those, I do want to point out that github annotations are showing up for many lint errors for deprecated code being used and automated tests not being written.

Do you plan on adding automated tests for this PR and addressing lint warnings?

Hopefully by the time you address these concerns, github will no longer give me errors can I can leave a more detailed review!

[mrehan27]

@levibostian I think the only deprecated code we are using in this PR is what isn't available on older APIs. I fixed one small issue. Please feel free to point any are that is still using deprecated code.

For tests, I think a lot of changes we made in this PR rely on Android OS callbacks. So testing them may be quite hard with mocks, but I do plan to write some tests. And they will probably be coming in the last PR for this feature (after wrapper ones).

[levibostian]

I would prefer that tests get added to this PR because it does make reviewing much easier.

GitHub gives you annotations helping you find parts of the code missing tests. If a future PR was made adding tests, the annotations would not show up and therefore, would make reviewing the PR for missing tests much harder.

---

As far as the deprecations, I also use github annotations to highlight them. There are lint warnings that are annotated (see screenshot above). I suggest enabling them if you have not already.

[mrehan27]

The deprecations shown are for existing code, not the code added in this PR. Fixing the warnings is definitely a good idea, but this PR isn't the right place for those updates.

Holding up this PR for tests complicates testing and finalizing changes on wrapper SDKs. The PRs were split to keep them short and simplify reviews. I'll write tests after validating changes in the wrapper SDKs. Since this PR is merging into a feature PR, we can still use GitHub annotations to identify code that isn't covered with tests.