Added object class check to current user controller's cache #964
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
| if (currentUser) { | ||
| // Verify that the current user matches our expected registered subclass | ||
| Class expectedClass = [[PFObjectSubclassingController defaultController] subclassForParseClassName:@"_User"]; | ||
| if(expectedClass == [currentUser class]){ |
There was a problem hiding this comment.
We probably should do [currentUser isKindOfClass:expectedClass] here instead of direct class comparison.
|
Probably a good idea. I've been working in Swift too much lately. :D |
|
Let's continue the discussion on the linked issue. This looks good and I love the idea, but not sure whether a temporary patch is the right solution. |
|
Updated as requested, in case we decide to use this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a fix for the issue identified in #963.
If the
_currentUserobject is set early on before a custom user subclass has been registered, it will never be updated with the subclassed user. As the current user loading is asynchronous this can create a race condition, and for some app launchescurrentUser()will return a PFUser and other times it will return your custom subclass.This adds a check to verify that the cached user object is of the class that we expect to get. If it isn't, it continues with user loading which will create the correct class.
This all means that
currentUser()will return a PFUser before the user subclass is registered, and aMYUsercustom subclass after the registration completes. This seems like expected behavior and should prevent hard to track down bugs, especially in Swift projects where the + load method isn't available.As an aside, it seems this issue may also be fixed by the merging of #5. That has been sitting around for a long time, and this PR should get us by until that old PR can be evaluated and merged.