-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
identity v3 #250
identity v3 #250
Conversation
62dd6f5
to
89b5c22
Compare
58dfa2c
to
44b1592
Compare
common/src/test/java/com/revenuecat/purchases/common/BackendTest.kt
Outdated
Show resolved
Hide resolved
common/src/test/java/com/revenuecat/purchases/common/BackendTest.kt
Outdated
Show resolved
Hide resolved
feature/identity/src/main/java/com/revenuecat/purchases/identity/IdentityManager.kt
Outdated
Show resolved
Hide resolved
purchases/src/main/java/com/revenuecat/purchases/interfaces/LogInListener.java
Outdated
Show resolved
Hide resolved
*/ | ||
@JvmOverloads | ||
internal fun logOut(listener: ReceivePurchaserInfoListener? = null) { | ||
val error: PurchasesError? = identityManager.logOut() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed reset
also does
deviceCache.clearLatestAttributionData(identityManager.currentAppUserID)
Do we need that here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot to add a comment to request feedback for this, but it's something I'm torn on. I didn't do it on iOS, since reset
doesn't do it there either.
I wanted to maintain consistency with the reset
method.
However, it's not technically needed for a reset or logout.
and, if after logging out you log in as the same user, attribution could be re-sent needlessly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that logOut
does call clearLatestAttributionData
, but it happens in identityManager instead of Purchases, since it does seem to pertain to identity management.
I just am not sure whether we should be doing it at all in a reset / logout scenario. @vegaro thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the only reason we had it was to not let the SharedPreferences grow forever. Note that if we never remove it, it will always stay cached since it's dependent on the identityManager.currentAppUserID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure what I was thinking when I replied before 😂 but yeah, I actually am clearing attribution data, both on iOS and Android. It's just done in IdentityManager instead of purchases.
And thinking about it further, I don't see a reason not to do it - it's just a cache, so the worst case here is that if you log in again with the same user and we've cleared the cache, we just send it an extra time.
I think it's a good tradeoff for having cleaner shared preferences.
common/src/test/java/com/revenuecat/purchases/common/BackendTest.kt
Outdated
Show resolved
Hide resolved
common/src/test/java/com/revenuecat/purchases/common/BackendTest.kt
Outdated
Show resolved
Hide resolved
subscriberAttributesCache.clearSubscriberAttributesIfSyncedForSubscriber( | ||
oldAppUserID | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being nitpicky here, but the line breaks are not needed
subscriberAttributesCache.clearSubscriberAttributesIfSyncedForSubscriber( | |
oldAppUserID | |
) | |
subscriberAttributesCache.clearSubscriberAttributesIfSyncedForSubscriber(oldAppUserID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the formatter is set to 120 characters, so it auto-adds them. I'll fix for now, but maybe we should have a strict set of rules for this? I thought detekt was set to 120 as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
120 is good, that's what I have too. My formatter is not auto-adding the breaks. Maybe there is another config thing going on? Let me know if you want to compare settings to figure out what's going on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, would love to have shared settings. we should probably even share them somewhere so they can be reused by other RC members
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
purchases.logIn(appUserID, mockCompletion) | ||
|
||
verify { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to specify the number of calls that should be verified. It's possible that mockBackend.getPurchaserInfo
is called from another part of the code, and logIn
never calls it, and this test will still pass. I think making sure that what is being passed to the mockCompletion
is what's fetched from the backend could also work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed that explicit > implicit. I was just following the style that was already in the file, but I'll update for all the stuff in this PR
purchases/src/test/java/com/revenuecat/purchases/PurchasesTest.kt
Outdated
Show resolved
Hide resolved
…ct the backend. Added tests for logIn in identityManager
…Info can't be parsed from the backend's response
…d for the old app user id instead of the new one after a successful login
5f16f25
to
e48287e
Compare
feature/identity/src/test/java/com/revenuecat/purchases/identity/IdentityManagerTests.kt
Outdated
Show resolved
Hide resolved
@vegaro I believe that's all comments addressed, give it another look if you'd like and we should be ready to 🚢 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
Introduces a new take on identity.
Public changes overview
New methods
logIn
, a new way of identifying users, which also returns whether a new user has been registered in the system.logIn
uses a new backend endpoint.logOut
, a replacement forreset
.Deprecations / removals
createAlias
identify
in favor oflogIn
reset
in favor oflogOut
allowSharingAppStoreAccount
in favor of dashboard-side configurationNote: the methods are kept
internal
in this PR so that it can safely be merged before the backend support for it is ready.The deprecations are also not included in this PR for the same reason. Those changes are done in a separate PR