Core Data vs. SQLite vs. ?

[redkronos2]

Hi,

My app includes a large drilldown menu the content of which originated in XML.
Each menu item results in 1 of 6 possible values when selected by the user. Here's the format:

<item style="TEXTStyle4">
<value>PARENT CATEGORY NAME
<value/>
<value/>
<value/>
<value/>
<value/>
<item style="TEXTStyle5">
<value>Child 1 Pick A</value>
<value>Child 1 Pick B</value>
<value>Child 1 Pick C</value>
<value>Child 1 Pick D</value>
<value>Child 1 Pick E</value>
<value>Child 1 Pick F</value>
</item>

The XML is huge. The team's first approach was to load this into an SQLite database. But, at launch, the load is taking 15 minutes.

Obviously, a new approach is needed. Any ideas?

The Core Data approach is in memory, right? So if we use that there should be no loading time, I hope

The concern is how easily the app will be to update with Core Data, since the XML will be modified every 2 months or so.

Thanks for any advice.

[Duncan C]

Originally Posted by redkronos2

Hi,

My app includes a large drilldown menu the content of which originated in XML.
Each menu item results in 1 of 6 possible values when selected by the user. Here's the format:

<item style="TEXTStyle4">
<value>PARENT CATEGORY NAME
<value/>
<value/>
<value/>
<value/>
<value/>
<item style="TEXTStyle5">
<value>Child 1 Pick A</value>
<value>Child 1 Pick B</value>
<value>Child 1 Pick C</value>
<value>Child 1 Pick D</value>
<value>Child 1 Pick E</value>
<value>Child 1 Pick F</value>
</item>

The XML is huge. The team's first approach was to load this into an SQLite database. But, at launch, the load is taking 15 minutes.

Obviously, a new approach is needed. Any ideas?

The Core Data approach is in memory, right? So if we use that there should be no loading time, I hope

The concern is how easily the app will be to update with Core Data, since the XML will be modified every 2 months or so.

Thanks for any advice.

Core data is a smart object front end on top of a "backing store" that can be XML, plists, or SQLite.

For very large databases, you would want the SQLite option.

Core Data is pretty smart about not loading actual records until it must. At first, it loads a placeholder that it calls a "fault". Its only when you actually fetch one of the fields of a record that it loads the record itself. This makes it both fast and easy on memory.

I'd suggest trying Core Data with an SQLite back-end. It's not magic, but it is pretty well optimized.

[redkronos2]

Ok, thanks Duncan. The fact that this menu is taking 15 minutes to load on initial launch and then 10 minutes on subsequent launches is a hint that they're probably not including the database "in memory" right?

Yeah, I've read elsewhere that Core Data with backing SQLite is the way to go. One fellow came just shy of calling it magic actually. But I don't want to get my hopes too high up.

I just hope it works. And I hope we haven't given an iOS app an impossible task

Originally Posted by Duncan C

Core data is a smart object front end on top of a "backing store" that can be XML, plists, or SQLite.

For very large databases, you would want the SQLite option.

Core Data is pretty smart about not loading actual records until it must. At first, it loads a placeholder that it calls a "fault". Its only when you actually fetch one of the fields of a record that it loads the record itself. This makes it both fast and easy on memory.

I'd suggest trying Core Data with an SQLite back-end. It's not magic, but it is pretty well optimized.