Open mtrezza opened 2 years ago
Those developers seeing this issue should note that this is not true and is not a bug. If you really want to migrate from the Objective-C SDK to the Swift SDK, see the convo, sample app, and a developer who successfully migrated here and #407.
Since I’ve already solved this problem, I will not be spending any additional time on Objective-C SDK migration, so those looking for a better way will need to depend on someone else to provide a different solution which will provide a feature to make it easier than it already is (it’s already easy).
I've opened this issue because it's still in the migration guide. What is the status of this issue, so we can update the guide?
a developer who successfully migrated here and https://github.com/parse-community/Parse-Swift/pull/407.
We want to be mindful about developer experience and provide migration support via the migration guide. A forum thread and a PR are not conveniently accessible resources so I'm hoping we can better document that for developers.
I've searched for instructions how to migrate the installation:
let objcInstallation = PFInstallation.current()!
let swiftInstallation = try await Installation.become(objcInstallation.objectId!)
It seems to expect that the Parse ObjC SDK is installed in parallel to the Parse Swift SDK, is that correct? And if yes, is that even recommended and tested or could they interfere with each other?
It seems to expect that the Parse ObjC SDK is installed in parallel to the Parse Swift SDK, is that correct?
The description of https://github.com/parse-community/Parse-Swift/pull/407#issue-1368984914 states:
Adding a method like this allows developers to use their own ways to get a particular objectId and use it to migrate to the Swift SDK.
So it doesn't matter if a developer has both SDK's in their app or if they have saved the objectId
for their installation somewhere else.
is that even recommended and tested or could they interfere with each other?
Why would they interfere with each other? These are two different SDK's and the only thing they have in common is transmitting data to/from a Parse Server. The probability of these SDK's interfering with each other is the same as using any other two frameworks in the same project. The sample app linked imports and configures the SDK's in the same file. The sample app even uses ParseUser
, PFUser
, ParseInstallation
, and PFInstallation
in the same file. Any conflicts between the SDK's will be those created by the developer from within their own app.
Thanks for confirming that there is no interference. These answers may seem obvious to you, but these are questions that developers may have when migrating. I will add that to the migration guide.
it doesn't matter if a developer has both SDK's in their app or if they have saved the objectId for their installation somewhere else
It sounds like we have no easy approach? Having both SDKs in the project certainly looks odd and is not ideal from a resource standpoint. Storing the objectId somewhere else again requires an app update to be adopted as the basis for migration, also not ideal. Theoretically the method exists to migrate the installation, but practically one SDK cannot be replaced with the other. With both approaches it seems to require a long-term migration over months or years.
I don't mind changing this to "feature", we just need to track the issue.
New Issue Checklist
Issue Description
After migrating an app to the Parse Swift SDK, launching the app will create a new
_Installation
object with a newinstallationId
. It will appear as if the app had been uninstalled and then reinstalled, even though it only changed the Parse SDK. See migration guide/known issues.An SDK change should not create a new installation, because it is not a new but existing installation. This bug also could make it difficult for developers to migrate from the Parse ObjC SDK, as data that is stored in the original installation object and any references to that installation object need to be migrated.
Steps to reproduce
n/a
Actual Outcome
A new installation object is created.
Expected Outcome
Any existing installation object should be used as the current installation.
Environment
Client
4.14.2