Closed cbaker6 closed 2 years ago
Merging #391 (b62ee9b) into main (675168e) will decrease coverage by
0.06%
. The diff coverage is75.23%
.
@@ Coverage Diff @@
## main #391 +/- ##
==========================================
- Coverage 89.17% 89.10% -0.07%
==========================================
Files 156 156
Lines 14553 14778 +225
==========================================
+ Hits 12977 13168 +191
- Misses 1576 1610 +34
Impacted Files | Coverage Δ | |
---|---|---|
Sources/ParseSwift/API/Responses.swift | 95.00% <0.00%> (ø) |
|
...thentication/3rd Party/ParseApple/ParseApple.swift | 86.25% <0.00%> (ø) |
|
...Swift/Authentication/Internal/ParseAnonymous.swift | 100.00% <ø> (ø) |
|
Sources/ParseSwift/LiveQuery/LiveQuerySocket.swift | 64.70% <0.00%> (ø) |
|
Sources/ParseSwift/LiveQuery/Subscription.swift | 97.87% <0.00%> (ø) |
|
...es/ParseSwift/LiveQuery/SubscriptionCallback.swift | 70.45% <0.00%> (ø) |
|
Sources/ParseSwift/Protocols/Objectable.swift | 92.10% <0.00%> (ø) |
|
...ources/ParseSwift/Protocols/ParseCloud+async.swift | 100.00% <ø> (ø) |
|
...rces/ParseSwift/Protocols/ParseCloud+combine.swift | 100.00% <ø> (ø) |
|
Sources/ParseSwift/Protocols/ParseCloud.swift | 100.00% <ø> (ø) |
|
... and 34 more |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
The Swift SDK will also create a new _Installation with a new installationId as well.
What is the rationale behind this? Why isn't it updating the existing installation? Technically the app isn't newly installed, it's updated which wouldn't create a new installation in other Parse SDKs.
the Swift SDK should hydrate the _User ParseObject from the server instead of relying on the Objective-C SDK.
Could you explain?
What is the rationale behind this? Why isn't it updating the existing installation? Technically the app isn't newly installed, it's updated which wouldn't create a new installation in other Parse SDKs.
The server doesn’t let an app login with the same session token and same installation using “become” method. The installationId has to be different when leveraging the same sessionToken. The server is designed that way.
Could you explain?
I’ve stated the SDKs are completely different, https://github.com/parse-community/Parse-Swift/pull/391#issue-1342325742 in which they are, classes/structs, the way they encode/decode, etc. The Swift SDK knows how to speak to the server, not the Objective-C SDK or any other SDK.
The server doesn’t let an app login with the same session token and same installation using “become” method.
Why can't the Swift SDK migrate an existing ObjC SDK session token without using become
? I assume that's what you mean by "hydrate" the ParseUser. The token has already been verified, because it has been stored previously by the ObjC SDK, so what verify it again with Parse Server?
Why can't the Swift SDK migrate an existing ObjC SDK session token without using become?
The Swift SDK can get the sessionToken
, which is already handled by the methods in this PR. The problem isn't the sessionToken, the problem is PFUser->ParseUser
and PFInstallation->ParseInstallation
.
I assume that's what you mean by "hydrate" the ParseUser. The token has already been verified, because it has been stored previously by the ObjC SDK, so what verify it again with Parse Server?
I've answered this in the comment above. The developer will want to access ParseUser.current
and ParseInstallation.current
the same way they access PFUser.current
and PFInstallation.current
. To do this properly, the developer needs to:
structs
on the client that conform to ParseUser
and ParseInstallation
structs
in 1 so they can be decoded (hydrated) from the serverParseObject
's the way the Swift SDK needs them to be stored and the developer can convert the rest of their code by observing similar methods in the Playgrounds without disrupting the user.
New Pull Request Checklist
Issue Description
Currently there's no way to migrate from the Objective-C SDK to the Swift SDK. This enforces developers who convert to have to ask users to log into applications again after migration. More discussion in here.
Related issue: #n/a
Approach
Use the session token (assuming it's still valid) from an already logged in user in the Objective-C SDK Keychain to become/login into the Swift SDK. This allows a seamless migration/login without interrupting the application flow and does not modify the original Objective-C Keychain or the original session token. There is no need to have the Parse Objective-C SDK as a framework in your project as the Swift SDK doesn't need it to access the keychain since the keychain belongs to the respective app and can be access via the
bundleId
. The methods introduced to allow this are:ParseUser
ParseInstallation
Note that logging in via the linked methods is the proper way to migrate to the Swift SDK as the SDK's themselves are entirely different and the Swift SDK should hydrate the
_User
and_Installation
ParseObject
's from the server instead of relying on the Objective-C SDK.Developers should also ensure the latest
PFUser
andPFInstallation
is saved to their Parse Server before migrating a user using these new methods. After initializing the SDK, migration should look something like:TODOs before merging