Repository navigation
Proposal: Support Amazon and Samsung Galaxy app stores - #14
Conversation
8f15096 to
128ed73
Compare
128ed73 to
800e669
Compare
|
Hi @osilviotti - I am open to add these changes as this is a very good addition this this library - as other libraries do not have it. Once you make the changes, do let me know and send me video recordings and screenshots so i can add them as proof that this library offers Google, Amazon, Samsung Android Playstores - with proof, so people can benefit. I am open to any new additions as I myself and the libraries I have made are not rigid in any way and I want it to be very flexible as it is required to me it useful to every one in the react native community. So do let me know. |
|
@zeeshy30 - if you can give me working screenshots and videos on iOS and Android, I will merge it. |
|
Thank you @Gautham495, I’ve picked up a PR from my colleague and I’m currently verifying the changes, cleaning up the PR, and updating the documentation. Once that’s done, I’ll let you know it’s ready to be reviewed / merged. |
|
@zeeshy30 - I will be merging this. Can you confirm with screenshots and videos that this is working on all 4 platforms. Google Android, iOS, Samsung and Amazon. CC: @osilviotti |
f1f9143 to
10ae644
Compare
@Gautham495 A heads-up on testing scope before this is merged: Everything in this PR was verified against mock data only — the JS mock APIs (setGooglePlayMockUser, setAmazonMockScenario, setSamsungMockScenario) driving the example app through every scenario. I've added a demo of this to the docs. I don't have physical Amazon or Samsung devices, and the automated checks (yarn typecheck, yarn lint, Android compileDebugKotlin) all pass, but none of that exercises the real store APIs on-device. The Android side I'm fairly confident in — the mock providers mirror each store's documented response contract. The part I can't validate is iOS: I don't have a way to smoke-test the Apple Declared Age Range flow, since the simulator won't drive the real age-range sheet. Could you smoke-test the iOS APIs on my behalf confirming getAppleDeclaredAgeRangeStatus() / getIsConsideredOlderThan() behave as expected, before merging? Happy to make any changes if something doesn't line up. Thanks! 🙏 |
|
Hey @Gautham495, just a friendly bump on this. A quick update since my last message: the iOS CI is now green. The build-ios job was failing during pod install because GitHub’s macos-latest runner moved to Ruby 3.4, which no longer includes several libraries in the standard library (first base64, then kconv), causing CocoaPods to fail. I fixed it by adding the required gems (base64 and nkf) to the example app’s Gemfile/Gemfile.lock. The full pipeline is now passing: lint, typecheck, Android, and iOS build. The only thing still pending is real-device verification on iOS. I’ve been able to test everything against the JS mock APIs that power all scenarios in the example app (and I’ve added a demo to the docs), but I haven’t been able to test against the real APIs on a physical iOS device. Whenever you have a chance, would you mind doing a quick smoke test of getAppleDeclaredAgeRangeStatus() and getIsConsideredOlderThan() on a real iOS device before merging? No rush at all, and I’m happy to make any changes if you spot anything. Thanks again! 🙏 |
This work is incomplete and requires testing, but wanted to present it early to gather feedback and see if it's something you would be happy to be merged back into the main project.
If a user installs the app through a non-Play app store - in this case Amazon's app store or the Samsung Galaxy store - they will be the authority that reports the user's age signals. This PR aims to add support for the Amazon GetUserAgeData API and the Samsung Galaxy Get Age Signals API.
The surface API should be largely unchanged, with the idea being to expose a method of getting the raw results from the API across the bridge and then writing any logic to act on those response in TypeScript to make it more easily unit testable (for this reason, I've moved
isEligibleover the TS side as it's just a null check natively so that is easy to recreate and test).There is more work to do, but just wanted to see if you'd be open to including these APIs in the library