I'm working with Core Data for the first time, with the Stanford iOS app development course as a guide. I pretty much copied the code from the demo app (of course I adjusted it to my needs), but I'm having two problems currently.

My app is a map view which on the tap of a button presents a modal view controller. This modal view checks whether a UIManagedDocument was created. If not, it creates one and inserts the data. This data is coming from a property list (258 items, so nothing too excessive). If it was created already (by previously displaying that view), if my logic holds, it should be safe to assume it also has content because the NSManagedObjects are created at the same time a document is created. The first run works perfectly fine, the table loads and all my data is correctly displayed.

However, when I dismiss and then re-display my modal view, the table stays empty. I'm checking the document's state, which is UIDocumentStateNormal, so querying it should be fine. But it isn't: my fetchedResultsController returns 0 rows. If I understand UIManagedContext correctly, the behavior I'm experiencing could be caused by a wrong/different context, but I make sure that: 1) I pass my document (not just the context) to the modal view in prepareForSegue:sender, and 2) I pass my document with the context back to the presenting view when the modal view is being dismissed. That's why I think it's probably not the context, but something else.

One other thing: inserting the 258 records when the app is first launched is fast enough in the simulator. However, on my phone it could take a whole 13 seconds. The insertion code is shown below (modified for readability):

To be clear: this code works just fine, but it's really slow. It's encapsulated in a method which is called exactly 258 times. informationElements has at most three elements, which means there are 258 * 3 = 774 loops maximum. In reality it's much less than that, but even if it were 774, that shouldn't take 13 seconds, right?

have you tried it on a different thread?
–
owen gerigDec 23 '11 at 20:46

I have not. Is there a chance that there's just too much data to handle it fast enough?
–
Scott BerrevoetsDec 23 '11 at 20:48

could be, i use core data to save my singleton object and it works fine but yours does seem a lot more complicated. i say it as kind of a blanket statement for something that works but is slow. unless there was reason to suspect otherwise.
–
owen gerigDec 23 '11 at 20:50

Ok, I've limited my loop to do only 15 items and that runs a lot faster, so I'll try running it in a thread. However, the issue of my data not being saved remains.
–
Scott BerrevoetsDec 23 '11 at 20:54

2 Answers
2

For the speed issue, I would look into using predicates; that should speed things up a great deal!

Predicates make it so that the context returns only the values needed based on whatever criteria you choose. The reason they are faster is because it does not have to convert each stored entity object into a managed object, rather it can pull straight from the property, which speeds up comparisons drastically.

Yeah, that would be an option, except that I really need all those objects. It's a table that is displaying all departments from which the user can then pick one. If there really is no way around the speed thing, I'll have to change that, but for now I'd like to see if there is anything else I could do to keep my current UI with speeds less than a second.
–
Scott BerrevoetsDec 24 '11 at 12:33

When you're inserting Department objects into the context, are you saving for each object? Inserting is relatively cheap, but saving (i.e. -[NSManagedobjectContext save:]) is expensive (since the database has to do locking and file I/O).

I actually relied on UIDocument's auto-saving mechanism, so I wasn't saving at all. Even with a manual save, my data isn't stored between view switches. I was also aware of the fast enumeration, but since my current method was used in the lecture also, I figured I'd just use that.
–
Scott BerrevoetsDec 29 '11 at 4:17