mono
mono

Reputation: 4335

Are there any weak points to store all data in App Groups' container area on iOS8?

I'm considering store all data in App Groups' container area to create the app which supports AppExtensions.

Are there any weak points to store all data in App Groups' container area on iOS8? Should I store limited data in App Group's container area?

App Extension Programming Guide: Handling Common Scenarios

Upvotes: 2

Views: 832

Answers (1)

Daniel Galasko
Daniel Galasko

Reputation: 24247

Naturally it depends on your app but here's my two cents:

Storing all of your information in a shared directory is complete overkill and doesn't sound like its coming from any sound reasoning. If you feel that your widget needs all the information that your app needs then perhaps you need to reconsider the complexity of your widget.

What you are achieving by this is convenience (future you headaches) rather than simplicity (hiding complexity through singular responsibility). The caveat is that as your application grows and becomes more complex you will end up spending a lot more time facilitating information inside of the App Container (a la massive view controller). What you want to strive for is singular responsibility. Instead you now need an object to facilitate the information of two apps into one container.

Shared containers are also different to the App Sandbox as you need to worry about coordinating reads and writes. Thats why typically its best to go ahead with either Core Data or NSUserDefaults (instantiated with the suite name). If your app stores images and other content then you are in for a world of pain. Even Apple recommend User Defaults (since its the only example they give) or CoreData:

After you enable app groups, an app extension and its containing app can both use the NSUserDefaults API to share access to user preferences [...] To avoid data corruption, you must synchronize data accesses. Use Core Data, SQLite, or Posix locks to help coordinate data access in a shared container.

The purpose of a widget is to provide the at-a-minute overview of your app. By minimizing the amount of data the widget has access to you will reduce many headaches as well as make your widget better contained. Remember, with great power comes great responsibility and if you think storing all of your information in one shared container then you have a lot to be accountable for...

Example

I have recently finished building a widget for a news app that displays the top news stories as well as the ability to personalize the content the widget displays. Heres a basic breakdown of the data persistence to give you an idea:

Storage Breakdown

Widget

  • Images its currently displaying
  • Last Modified Date of the JSON Feed (So we know when to tell the widget that new content has been added)

App

  • All Stories, Images and User content etc

Shared Container

  • Users chosen topics
  • List of top stories

When the widget is asked to fetch content it downloads a JSON file containing the top stories for all topics. This JSON is persisted to the shared container. The reason we store all the stories is in case the user changes their favorite topics, the widget can then simply update its selection as all the topics are stored. This also allows the app to update the top stories and the widget to reflect that immediately.

The widget will then extract 3 of the top stories that match the users specified topic tags. These top topics are persisted in a shared user defaults item. Naturally its possible that the widget is opened before the user chooses topics, in this case the widget will automatically choose the first three or so topics.

TL;DR

A metaphor - If a Widget and an App are colleagues in the workplace, the Shared Container is like a computer. How productive would you be working with someone all day, every day, on the same computer?

Upvotes: 5

Related Questions