-
Notifications
You must be signed in to change notification settings - Fork 11
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
Need a way to migrate data into a shared container without requiring the user to explicitly launching the containing app before using the extension #2
Comments
@brianmichel mentioned that Pinterest is doing something else here. We should look into that. |
For Pinterest, the only pieces of data our extension needs is authentication details from the shared keychain, and the user's boards. If the user's boards aren't available in the shared container when the extension is launched, it (the extension) makes an API call to fetch them and write them to the shared container. We don't do anything too special for this case. |
@steveram So if I'm understanding correctly, you already had a shared keychain configured with an app group prior to iOS 8, which allows you to now read from the keychain from your share extension without having to do any extra work? |
@irace We've never setup keychain sharing until our iOS8 release. Any logged in users who would update to our iOS8 version app would have had their credentials previously stored in the keychain. Once they got the new update with new keychain sharing entitlements, that keychain was now able to be shared between the containing app and extension. This is how I understand it. I never ran into issues with having to do any extra work from the containing app (migrating data, etc.) before the extension could read from the keychain successfully. At this point I can fallback to making API calls if the shared container doesn't have the data that I need. |
@steveram Thanks for clarifying. I think I was incorrectly under the impression that simply adding the new entitlement wouldn't be sufficient for items that already existed in the keychain, but sounds like it was! 👍 |
@irace Cool. Let me know how it goes. Great job on your extension too. |
As mentioned, the shared container is where everything that you need to access from both your app and extension must be located: user defaults, keychains, databases, files that you’re serializing via
NSCoding
, etc.For existing apps, the problem is simple; the data already exists somewhere outside of the shared container, and only the container app can migrate it over. Thus, if the user installs an update that adds an extension, and tries to use the extension before launching the application and giving it a chance to perform the migration, they’re going to have a bad time.
Workaround
There’s no great option here. If the user opens our extension first, we just throw up a dialog telling them that they need to launch the application first. Inelegant but necessary.
The text was updated successfully, but these errors were encountered: