Closed Shahroz16 closed 1 year ago
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.
Merging #235 (f2262b6) into main (85022d1) will increase coverage by
0.31%
. The diff coverage is100.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%) |
:arrow_up: |
...ava/io/customer/sdk/repository/DeviceRepository.kt | 97.67% <100.00%> (+0.05%) |
:arrow_up: |
Build available to test
Version: shahroz-expose-device-token-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/
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
@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.
@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.
@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.
Complete each step to get your pull request merged in. Learn more about the workflow this project uses.