PurchaseTesterSwiftUI: allow configuring API key at runtime#1999
Conversation
PurchaseTesterSwiftUI: allow configuring APIKey at runtimePurchaseTesterSwiftUI: allow configuring API key at runtime
|
Actually I'm gonna save it in user defaults so it remembers the last used one. |
e1b2431 to
f1458de
Compare
d45eed4 to
6cb1fc6
Compare
00ab935 to
e24e7ce
Compare
tonidero
left a comment
There was a problem hiding this comment.
Just some questions but looking good!
|
|
||
| func purchases(_ purchases: Purchases, readyForPromotedProduct product: StoreProduct, purchase makeDeferredPurchase: @escaping StartPurchaseBlock) { | ||
| makeDeferredPurchase { (transaction, customerInfo, error, success) in | ||
| print("Yay") |
There was a problem hiding this comment.
Should we print something more meaningful? I guess this will not be called usually but something more meaningful would be better :P
There was a problem hiding this comment.
I agree, I just copied the existing implementation. There's tons we could improve but this PR focuses on just this feature.
| .toolbar { | ||
| ToolbarItem(placement: .navigationBarLeading) { | ||
| Button { | ||
| self.configuration = nil |
There was a problem hiding this comment.
Does the iOS SDK keep some sort of shared instance of Purchases? Just wondering if this is enough to reset it.
There was a problem hiding this comment.
Technically not, but it will be re-created when it gets re-configured.
| } | ||
| } | ||
| .onChange(of: self.data) { _ in | ||
| self.saveData() |
There was a problem hiding this comment.
A UX question, should we only save data when pressing the "Continue" button? I think it shouldn't matter much, but seems more intuitive for me... For example, if a user wants to reconfigure the sdk, starts changing the data but then restarts the app, I would expect to still have the old information... NABD though.
There was a problem hiding this comment.
Yeah, I could see either way. I don't think this is that "wrong", so if you don't mind I'm going to leave it as is so I don't have to re-test this 9-day old PR.
Fixes [CSDK-510].  Depends on #1999. Also set up CI as per [the docs](https://docs.fastlane.tools/best-practices/continuous-integration/#storing-a-manually-verified-session-using-spaceauth): Added these 2 environment variables: - `SPACESHIP_ONLY_ALLOW_INTERACTIVE_2FA` - `FASTLANE_SESSION` [CSDK-510]: https://revenuecats.atlassian.net/browse/CSDK-510?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
**This is an automatic release.** ### Bugfixes * `ISO8601DateFormatter.withMilliseconds`: fixed iOS 11 crash (#2037) via NachoSoto (@NachoSoto) * Changed `StoreKit2Setting.default` back to `.enabledOnlyForOptimizations` (#2022) via NachoSoto (@NachoSoto) ### Other Changes * `Integration Tests`: changed weekly to monthly subscriptions to work around 0-second subscriptions (#2042) via NachoSoto (@NachoSoto) * `Integration Tests`: fixed `testPurchaseWithAskToBuyPostsReceipt` (#2040) via NachoSoto (@NachoSoto) * `ReceiptRefreshPolicy.retryUntilProductIsFound`: default to returning "invalid" receipt (#2024) via NachoSoto (@NachoSoto) * `CachingProductsManager`: use partial cached products (#2014) via NachoSoto (@NachoSoto) * Added `BackendErrorCode.purchasedProductMissingInAppleReceipt` (#2033) via NachoSoto (@NachoSoto) * `PurchaseTesterSwiftUI`: replaced `Purchases` dependency with `SPM` (#2027) via NachoSoto (@NachoSoto) * `Integration Tests`: changed log output to `raw` (#2031) via NachoSoto (@NachoSoto) * `Integration Tests`: run on iOS 16 (#2035) via NachoSoto (@NachoSoto) * CI: fixed `iOS 14` tests Xcode version (#2030) via NachoSoto (@NachoSoto) * `Async.call`: added non-throwing overload (#2006) via NachoSoto (@NachoSoto) * Documentation: Fixed references in `V4_API_Migration_guide.md` (#2018) via NachoSoto (@NachoSoto) * `eligiblePromotionalOffers`: don't log error if response is ineligible (#2019) via NachoSoto (@NachoSoto) * Runs push-pods after make-release (#2025) via Cesar de la Vega (@vegaro) * Some updates on notify-on-non-patch-release-branches: (#2026) via Cesar de la Vega (@vegaro) * Deploy `PurchaseTesterSwiftUI` to TestFlight (#2003) via NachoSoto (@NachoSoto) * `PurchaseTesterSwiftUI`: added "logs" screen (#2012) via NachoSoto (@NachoSoto) * `PurchaseTesterSwiftUI`: allow configuring API key at runtime (#1999) via NachoSoto (@NachoSoto)
…tances in memory We allow calling `Purchases.configure` multiple times. Likely a programmer error, but it's common in tests, or for example in `Purchase Tester` where users can re-configure the SDK at runtime (#1999). When this happens, the SDK was creating the new instance before clearing the old one from memory (clear thanks to #2082, notice how the first `deinit` happens after the second `init`): ``` [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600003ca4200) [Purchases] - INFO: ℹ️ Purchases instance already set. Did you mean to configure two Purchases objects? [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600003c8a100) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600003ca4200) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600003c8a100) ``` With this change, we avoid that, which could also avoid issues with concurrent requests ([CSDK-517]): ``` [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600002b6e600) [Purchases] - INFO: ℹ️ Purchases instance already set. Did you mean to configure two Purchases objects? [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600002b6e600) [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600002b68100) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600002b68100) ```
…tances in memory (#2180) We allow calling `Purchases.configure` multiple times. Likely a programmer error, but it's common in tests, or for example in `Purchase Tester` where users can re-configure the SDK at runtime (#1999), which is where I saw this issue. When this happens, the SDK was creating the new instance before clearing the old one from memory (clear thanks to #2082). Notice how the first `deinit` happens **after** the second `init`: ``` [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600003ca4200) [Purchases] - INFO: ℹ️ Purchases instance already set. Did you mean to configure two Purchases objects? [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600003c8a100) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600003ca4200) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600003c8a100) ``` With this change, we avoid that, which could also avoid issues with concurrent requests ([CSDK-517]): ``` [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600002b6e600) [Purchases] - INFO: ℹ️ Purchases instance already set. Did you mean to configure two Purchases objects? [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600002b6e600) [Purchases] - VERBOSE: Purchases.init: created new Purchases instance: Purchases (0x0000600002b68100) [Purchases] - VERBOSE: Purchases.deinit: Purchases (0x0000600002b68100) ``` Unfortunately we don't have an easy way to test this, especially considering that we prohibit multiple instances in tests (#2100). [CSDK-517]: https://revenuecats.atlassian.net/browse/CSDK-517?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Fixes CSDK-456.
Configuration screen:
Displaying errors:
_Note that if you enter an invalid API key and there's a credentials issue, you can tap on "reconfigure" to start over: