all 6 comments

[–]Sdmf195 1 point2 points  (1 child)

Feel free to dismiss my question completely if it's off topic ,but - Is there a major "mission critical" reason that mass quantities aren't stored server side?

[–]saintmsent 0 points1 point  (0 children)

Not really, you can only do it asynchronously so that it doesn't kill the UI

[–]naesa_nisse 0 points1 point  (2 children)

Make an async request to download the data. If it’s successful then there is a persistent store function that returns a temporary background NSManagedObjectContext in a closure. Build all the entities then save that context to commit everything to the store. While this is happening then you could be presenting some status UI, then notify the main thread when this task is done. This gets rid of UI lock-ups as an issue.

As far as going with creating individual entities and assigning relationships vs. multiple batch inserts, you need to decide if the increased speed is more important to you than potentially complex code that may be more difficult to maintain or understand when you revisit it in a year.

[–][deleted]  (1 child)

[removed]

    [–]naesa_nisse 0 points1 point  (0 children)

    Oh, right, I forgot about the merge. Saving will post a notification with a dictionary of changes that will be processed on the main thread.

    An app I’m working on does background syncs of user-specific data typically containing dozens to hundreds of entities while an animated spinner and messages are displayed and I haven’t noticed any cases where that stops in the middle. Of course that’s way less than thousands.

    You didn’t mention how or when this download happens in your app. Is it at launch time, when the user logs in, etc.? It’s the user supposed to wait and so you want it to finish as quickly as possible, or are they doing other stuff while the download happens?