parse-community / Parse-Swift

The Swift SDK for Parse Platform (iOS, macOS, watchOS, tvOS, Linux, Android, Windows)
https://parseplatform.org
MIT License
308 stars 69 forks source link

Auto-reuse existing installation object when migrating from ObjC SDK #426

Open mtrezza opened 2 years ago

mtrezza commented 2 years ago

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 new installationId. 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

parse-github-assistant[bot] commented 2 years ago

Thanks for opening this issue!

cbaker6 commented 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).

mtrezza commented 2 years ago

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.

mtrezza commented 2 years ago

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?

cbaker6 commented 2 years ago

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.

mtrezza commented 2 years ago

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.

mtrezza commented 2 years ago

I don't mind changing this to "feature", we just need to track the issue.