feat: expose device token

[Shahroz16]

Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

• Assign members of your team to review the pull request.
• Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
• Wait until the pull request has been reviewed and approved by a teammate
• After pull request is approved, and you determine it's ready add the label "Ready to merge" to the pull request and it will automatically be merged.

[github-actions]

Pull request title looks good 👍!

If this pull request gets merged, it will 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.1.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: shahroz/expose-device-token (1688723164)
• kotlin_compose: shahroz/expose-device-token (1688723153)

[codecov]

Codecov Report

Merging #235 (f2262b6) into main (85022d1) will increase coverage by 0.31%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main     #235      +/-   ##
============================================
+ Coverage     62.64%   62.95%   +0.31%     
- Complexity      231      234       +3     
============================================
  Files            94       94              
  Lines          2147     2149       +2     
  Branches        282      282              
============================================
+ Hits           1345     1353       +8     
+ Misses          693      690       -3     
+ Partials        109      106       -3     

Impacted Files	Coverage Δ
sdk/src/main/java/io/customer/sdk/CustomerIO.kt	75.00% <100.00%> (+0.66%)	⬆️
...ava/io/customer/sdk/repository/DeviceRepository.kt	97.67% <100.00%> (+0.05%)	⬆️

... and 5 files with indirect coverage changes

[github-actions]

Build available to test
Version: shahroz-expose-device-token-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/

[mrehan27]

This looks fine for cases when the token is already there. But shouldn't we have an option for callback or future kind of thing? Where customers don't have to attempt fetching token again if the token was not fetched the time of first app launch?

[Shahroz16]

This looks fine for cases when the token is already there. But shouldn't we have an option for callback or future kind of thing? Where customers don't have to attempt fetching token again if the token was not fetched the time of first app launch?

I am not sure if we need that, haven't seen the ask for it from any customer nor does our sample app needs it like that... so we can probably create a separate ticket for it if we ever need it

[mrehan27]

@Shahroz16 I'm not concerned about the sample app, it will work fine for it. I'm here asking for cases where customers need to utilize token for other SDK (e.g. tracking installs, etc.), generally they will be fetching the token at app start. Assuming network and everything else is working fine, do you think the token will be available every time at first launch as well? If yes, then I'm okay with this, if not, I would recommend to make it async.

[Shahroz16]

@mrehan27

generally they will be fetching the token at app start

I don't think that's always true, because I believe it is usually done after onboarding/sign-up. The adjust library also doesn't need it for the app starts but anytime in the app lifecycle.

Additionally, we don't generate token in iOS we are reliant on Apps providing us that information, so in that case, if we make this call async for android, and sync for iOS there will be a disparity.

[mrehan27]

@Shahroz16 I think it strongly depends on the product, we cannot assume if it has to be done at the start of onboarding or after completion.

For the async part, we can always make it async ourselves and returns the results wrapped in future/promise instantly. The original ticket was also updated as async design to avoid any changes to this later.

I still think having it async is more flexible for cases when we are fetching directly from FCM. But if you think the current solution will work fine for customers, I'm happy releasing changes without making it async.