0

I have a problem with my data import at my app launch. At first launch, I create a lot of core data objects (almost 400 objects). The problem is, when I try the app in simulator, all seems to be right but on a device, I have to wait a lot of time because of my importation and maybe, the app crash (not everytime).

Is someone ever had this problem ? Should I try to make my importation script more efficient ? Is some good practices about data importation with Core Data exists ?

Thanks a lot in advance !

Vinestro
  • 1,072
  • 1
  • 10
  • 32
  • 1
    some code would help. – Rakesh Feb 21 '13 at 14:59
  • Are you running all of this on the main thread? – Mike D Feb 21 '13 at 15:27
  • I create and insert about 1000 objects at the first start, this takes less than 2 seconds. But this depends strongly on how big the objects are and how often you have to save the context. Optimizing the data-model helps a lot. Using a highly normalized DB-model with many relations will most likely perform very bad in ios. – Jonathan Cichon Feb 21 '13 at 15:29
  • Yes I'm running the import on the main thread and I save the context only one time at the end of the import. – Vinestro Feb 21 '13 at 15:58

2 Answers2

0

I usually use the same technique as Gopal. Other than file size, the only downside I've hit is is you find errors in shipped data. If that happens and you need to fix the data, you need to determine if the bad data exists in the user data and update it. I dealt with this at launch by checking a didUpdateToVersionX value in the NSUserDefaults for the app, querying the user data store to find the erroneous records, updating the relevant objects, saving the store, and setting the preference flag.

Is your seed data meant to be user-editable or read-only? If it's read-only, you should be able to have separate read-only and user-writable stores (the former in the app bundle, the latter in the Documents directory). Marcus Zarra's did a nice writeup of this technique in response to another question. Depending on your setup, it might involve a little extra work. I wanted to switch the aforementioned app over to using this technique, but I never had the chance.

Community
  • 1
  • 1
Jablair
  • 5,036
  • 4
  • 28
  • 37
-1

I normally bundle the sqlite file which has the initial data in the app itself. On app launch, check if the db file exists, if not copy it from the bundle to the documents directory or wherever.

Faster launch times at the cost of increased app size.

Gopal R
  • 732
  • 5
  • 8
  • I don't think this is a good strategy. What if Apple change their internal Core Data <-> SQLite interchange? Your app in the store will broken until you notice and get an update out. – occulus Feb 21 '13 at 15:51
  • The purpose of Core Data is not manipulate data directly in the SQLite file. Core Data is an ORM who makes the intermediate between SQLite database and objects in Objective-C. – Vinestro Feb 21 '13 at 16:09
  • If apple made incompatible changes to their .sqlite format, everybody's apps will break. Apple isn't likely to do this. – Mike Weller Feb 21 '13 at 16:14
  • I wonder why the downvote? I've use this method since iOS 4.3, no issues till date. Just to be clear, I don't create the 'seed' sqlite file by hand, its created using coredata by the actual app itself. Once I have the needed 'seed' data stored, I zip up the sqlite file and bundle it with the app binary – Gopal R Dec 28 '13 at 18:24