I have an existing iOS app that uses core data for app data and user data. My problem is that updating app data is a nightmare (my first app, so I didn't do it ideally the first time). I would like to split the app data and user data into 2 separate sqlite dbs (or stores, correct me if my terminology is wrong).
Any tips would be appreciated.
Having two sqlite files is a good idea. The pain is splitting them now.
Create a new store that only exists in your app bundle. Make sure the data is unchanged from when you first released the app.
You are going to need to walk the "user" store and find all of the data that is identical to what exists in the "reference" store and delete it. If the user has changed that data then I would leave it and let the user sort out duplicates.
Once that is complete your app can resume normal function and load up both stores. I would set a flag somewhere so that you know this has been done and you don't run the check on every launch. The "user" store's metadata is a good place.
Note, this will need to be done before the user can "use" your app. This probably means changing your launch routines so that if a migration and filter is needed you tell the user what is going on.
I don't think having multiple persistent stores is the right solution. You can simply have separate entities within a single persistent store. Core Data will handle it properly.
Related
I have an app where a UITableView is used to represent a friends list. Now, this table is updated by values stored in core data, and I'm downloading friend values to core data via Parse. Instead of accessing Parse to update the tableView directly, I decided to update Core Data and then the tableView because I need the friend information in other parts of the app, and thought it would be more efficient to use Core Data than to have calls to Parse again and again. Everything works fine!
However, my app has a log in system before users can use the app. And when I created another dummy user to test it, I found that the friend values stored in Core Data by my actual account were being used to update the friend list tableView! When actually the tableView should be empty (new user).
I don't know exactly how Core Data works but I figure it uses some segment of the device's memory to store entities. My question is this, is it possible to use Core Data to store private information related to a particular user that can't be accessed by other users that log into the same device? Or should I continue to make calls to Parse whenever I need information?
Hope you guys understood my question, thanks!
iOS is not a multi-user system. Your app stores its files in a sandboxed folder structure and this sandbox is independent of any user logins you have implemented in your app.
When a new user logs in (or, if you prefer, when a user logs out) it is up to you to remove any data you have stored in Core Data that you don't want another user to have access to.
Parse can save data offline by Local Storage or cache the request by Cache Policy
They are much faster than creating your own database (by CoreData).
I've checked a lot of sites and answers and I can't find any solutions specific to my problem.
I don't need to change the schema for my Core data model, all I need is to modify (add some) content to the current backing SQL Database.
Any direction on this will be welcome. Thanks.
PS: I tried Apple docs and they were about as useful to me as sunshine on Mecury.
Also go easy please, I'm a beginner.
Thanks.
UPDATE;
To shed more light on my issue, my app works as thus. I have preloaded static information on the app that can't be changed by the user, each day has new content. Every month, I push an update with entirely new content specific to that month. However, when my app entered production, upon the update I pushed for this month, my users were complaining that they couldn't access the month's data. This led to me spamming them with Push notifications to have them delete the app and do a fresh install to access the new data.
How can I fix this issue? my schema stays the same, only the data changes.
If I understand correctly you want to pre-fill a Core Data database ?
If you don't care about pre-existing data on existing app, you can make an iPhone or Mac app with the same model, and let it generate the database, like explain here (Any way to pre populate core data?) it's also the way recommended in a really great book if you want to learn more about Core Data (http://pragprog.com/book/mzcd2/core-data).
Do not ever make SQL request directly, Core Data work in his own magic way.
Don't work on the SQLite-Database directly. Change all your Data through NSManagedObjectContext! To find a good strategy look up examples from Batch-Importing.
Update: You could actually have two PersistentStores (one with just static data (readonly) and the other one with user-generated data). You could interchange the readonly which you prefilled with a commandline util and downloaded from a server. You cannot have direct relationships between those two store though.
I would say that it depends on the amount of data in this prefilled store wether you should go this way or just use a plist and reference some string constants in your user data store. Try to do it with a plist as this is the simpler approach.
My app was rejected recently due to the fact that it installs a database within a directory which will be backed up to iCloud. As the database comes with a lot of prepopulated data and the app stores user generated data into the same file.
So mixing up user-generated-content with prepopulated data is not was Apple wants us to do.
So far so good.
Separate my database into two and mark the store file with the prepopulated data with NSURLIsExcludedFromBackupKey = YES.
But what happens if the user wants to modify the data in that store, because he found a failure and wish to modify it.
Or myself make an online update available which modifies values with that store.
How do I cope with that.
Do I have to delete the store file, create a new one (now with NSURLIsExcludedFromBackupKey = NO) or store the database under /tmp or /Library/caches right from the beginning and move it into /Application Support (which is backed up automatically) but with the threat that my database is being removed by the system for some reason what is the case for /Library/caches?
It is a bit annoying that Apple will not allow you to backup prepopulated data if your app is of the kind where you could actually change the prepopulated data in the app. If the prepopulated database is big, I can however understand that they don't want your app to waste the user´s iCloud space with information that is already in the AppStore.
Woody has a good idea on the approach, but I'm not sure Apple would look away from the fact that you are actually wasting just as much space if you copy the prepopulated data to the user-backed-up DB on app startup.
What about something like this:
A: DB with pre-populated data, not backed up
B: DB with user added
data, backed up
When user make changes to object in A, crete a new row in B that "overrides" the row in A, for example by using the same ID or by having a column in the DB that tells the app which object in A should be replaced by the new row in B.
Whenever you need to update your app, you will replace DB A with new content and that's it. This could lead to conflicts with the data that the user has changed. You will have to decide whether the user data is more important than the updated data, and how to handle these conflicts (for example by trying to keep them both).
If you need to change the structure of DB B in an update, for example if you need to add a column, you will have to include an update routine in your app that detects that the user is having an old DB version and write code to migrate the user data to the new database on first startup after the update.
When you startup, if the user database is unpopulated you could copy the data across from the pre-populated datatabse, and maybe give the user an option to reset defaults which does the same again?
I've looked all over for an answer, but it seems like I'm missing something obvious. I've made a rather complex Core Data app before, but the answer to this question has eluded me for the past few months.
Here's the problem:
1) I have about 20 entities in my Model.
2) Some of these entities have user-editable objects, others have pre-loaded data
3) I would like to know if it's possible to update the pre-loaded entities with each new app update.
I know I can do this the "manual" way by specifying each updated attribute, but this is way too cumbersome. I want to just update all the pre-loaded entities once the user opens an updated version of the app. I don't want to touch the user-data.
Thank you so much for your help!
You could have a version number field in your schema which you can use to associate a version number with each record. If it has a value, it's a preload. Then for the preload stuff just insert the new data when the app opens, and then ignore/delete the old. Seems simple enough.
UPDATE:
The other alternative I believe is to separate your preloaded data into an entirely different data store. I have an app wherein I do this by delivering my preloaded data via a custom SQLite file, and user data in a CoreData store. I can do this because my preloaded data is read-only, which saves me from needing to copy the SQLite file into the documents directory. What this means is that, at every update, the new data file automatically overwrites the old by virtue of the app installation. The user's data is maintained as it should be.
Of course if your preloaded data is not read-only, then there's no way around the need to write code. In this case there's not much I can do for you, not having any more details about your problem.
First, Thank you for any help provided.
I have an iOS leveraging CoreData to retain various presentations, this data comes from a sqlite file and there is no server connection.
I will have to be able to provide App updates (via appstore), this update may add more data to the database.
The tricky part is that it can not simply overwrite the current database, there are a few user tables that I will not like touched.
Please provide any information I should consider when accomplishing this or any links are greatly appreciated.
Thank you.
Given your app has no server connection, you will have to rely on shipping data within the updated application itself. I would recommend using a plist file or define your own xml or json structure. You can then read this data to create/update core data nsmanagedobjects.
It looks like someone in the past was using plist->coredata on SO
Would you have relationships between user created data and shipped data?
If not, you might go the route of connecting two stored to the persistent store coordinator. The shipped store would be read-only. The store with user created data would be read-write. You can use this approach, too, if you have relationships between shipped and user-created objects, but it's a lot more complicated, since CoreData doesn't manage cross-store relationships for you, and you'll need to write your own logic (doable, but not straight forward).
If you need to have relationships between shipped and user-created objects, you can still ship a CoreData store. When the app launches for the first time (no user-created objects), you copy the store to the Documents folder and user this store to create your CoreData stack. User created objects will be added to this store. Once you have new 'shipped' objects (i.e. a new store in the app-bundle), you'll have to manually migrate that stores data into the store that the user has changed. You'll have to be able to find
(1) objects that need to be deleted
(2) objects that need to be updated (changed)
(3) objects that need to be added
If you mark your shipped objects with a special flag such that you can tell if it's a user created object or a shipped one, that would be doable. You also have to have some sort of ID to be able to tell which objects in the new store correspond to which ones in the existing (old) store.
You do not need to go the route of using plists. In fact, I'd recommend against it. You can easily open two stores at the same time. Either to use both stored, or just to migrate objects from one store to the other store.