Hey @UlyssesAlves,
Calling logIn before configure (setup in our Flutter SDK < 4.0.0) will just give you an error, since the setup step is supposed to happen first.
What this documentation is pointing to is that if possible, you should call setup once you have the appUserID available, and pass the appUserID to the setup method.
If you have an accounts system for your app, though, and you don’t know the appUserID until the user creates an account or logs in, then you should just call setup with no appUserID when your app starts, and then after the user logs in, call logIn.
Hope this helps!
Thanks @Andy for replying to this post.
If you have an accounts system for your app, though, and you don’t know the appUserID until the user creates an account or logs in, then you should just call setup with no appUserID when your app starts, and then after the user logs in, call logIn.
I was using this approach, but I am now changing it because it makes my app not recognize when the user has an active subscription after an uninstall and reinstallation of the app on Android, which can be simulated by deleting the app data and cache from the Android device. When I tried this out, the app behaves weirdly afterwards beause it acts as if the user has no active subscription, even though I can see the subscription is active on Google Play Store. Also, this error is proved to be there because when I try to buy the subscription again, Google Play returns error “You are already subscribed to this plan.”, which clearly shows a mismatch between the real current status of the user subscription on Google Play (subscribed) and the wrong status reported by RevenueCat for this particular user (not subscribed).
For what I could understand this error happens because, after the fresh reinstall, RevenueCat creates a new anonymous user when I call configure without passing the user id. Then, after my user does log in, RevenueCat treats it as a transfer, and don’t restore the user purchase automatically, since it looks like a different user to RevenueCat.
The solution I am implementing for this is to not call configure without passing my user ids to it anymore. Thus I stopped calling configure on the app startup, and I’m now calling configure on the first sucessful login of my user. If when the user logs in to my app RevenueCat has not been configured yet, then I call configure and pass it the user id. On the other hand, if when the user logs in RevenueCat has already been configured previously, then I call RevenueCat’s login method and pass the user id to it.
This solves the problem I stated above, because with this fix RevenueCat correctly detects that my user subscription is active even after I uninstall the app and reinstall again, and it also works when I delete the app data and cache from the Android device.
So, this is what works. Even though it may not be the intended way for it to work, it does.
That approach should work. You should try to ensure that no purchases can be made while the SDK isn’t configured, though, to ensure that the SDK doesn’t miss purchasing activity for the user.
Renewals will continue to work even while the SDK isn’t configured, since the backend will take care of keeping track of them.
One alternative approach is to configure the SDK as soon as possible, but call syncPurchases right after logging in, to ensure that if there are any purchases that got transferred to the anonymous id after uninstall, they get transferred back.
One alternative approach is to configure the SDK as soon as possible, but call syncPurchases right after logging in, to ensure that if there are any purchases that got transferred to the anonymous id after uninstall, they get transferred back.
At first sight it doesn’t look like this will solve the problem I am facing, because after uninstall, no purchases are transfered to the anonymous id, which means after logging in, there will be no purchases on the anonymous id to be transferred back to the authenticated user id, and thus the logged in user will stay in a state of inactive subscription. Looking at it another way, it’s as if the anonymous id inactive subscriptions would be transfered to the authenticated user id, which is the same of the user is not logged in at all.
But I’ll verify it running the code and tell you if it did work or not.
But now I got really curious about it, @Andy . Isn’t this the very problem this section of the docs alert us to avoid by ensuring to call configure only after we know the user id upfront?
Google Play on Android
Due to platform limitations, purchases will be transferred as soon as you call configure
if a user's purchases are already associated with another app user ID.
This may cause unexpected transfers of purchases between app user IDs, especially for apps with optional logins or users with multiple devices. To prevent this behavior, you should wait to call configure until you have the appropriate app user ID for your customer.
syncPurchases will ensure that any purchases tied to the Google / Apple account get tied to the currently-logged in user.
The call to it is to make sure that if any purchases had been transferred to the anonymous user id, they get transferred back.
Let me know how it goes!
To be clear - this is a workaround to the issue that the docs are warning about. If your app can reasonably wait to get the appUserID in order to call configure, then that’s the easiest away around it. Some apps can’t wait that long, so the (configure w/o appUserID + logIn + sync) is the workaround for that setup
@Andy , what does it happen when the app is offline, with no internet connectivity available, and the app tries to sync the user purchases from the anonymous id to the authenticated id? Will RevenueCat tries to sync them once the app is connected to the internet after this first failed attempt?
I ask this because there will be times when my app will authenticate the user with the auth token which is stored in the file system, so that the user does not need to type in his user name and password in every session. Thus, syncing the user purchases may work when the user is first authenticated, because in this scenario the app will have internet connectivity (or else it would not be able to reach the authentication server). But on other sessions, the user will be automatically authenticated on my app initialization, where internet may be or may not be active.
@UlyssesAlves the SDK does a similar thing to what you describe, where it caches data about the current user, so that if there’s no connectivity on the next app launch, it’ll continue to provide access until the latest known subscription date.
If you call setup with the same appUserID, things will continue as normal (same if you call logIn with the same user that is currently logged in).
If you call log in with a different user, though, the SDK will return an error if there’s no connectivity.
Syncing purchases when the app is offline won’t have any effect, since there’s no way to communicate with the backend.
One alternative approach is to configure the SDK as soon as possible, but call syncPurchases right after logging in, to ensure that if there are any purchases that got transferred to the anonymous id after uninstall, they get transferred back.
This solved the issue, @Andy . And it was much simpler than the way I was trying to solve it. Thanks a lot!
Happy to help! Have a great day!