views:

110

answers:

3

As a follow up to this previous question, I have a Core Data-based iPhone app that gets its underlying SQLite database file pre-loaded by a small utility, written in Cocoa, which I also wrote. Basically, I'm taking data from text files and building my data off-line, so the app is as fast as possible when it runs (i.e. no data parsing on my end).

Part of the project will involve creating a detail view from this data, and since the best way to render a few screens worth of formatted text is to use HTML and a UIWebView, I could extend my data converter to generate HTML during the conversion process.

My question is: what are the pros and cons of storing arbitrary sized blocks of HTML using Core Data? As I mentioned, I am using SQLite as my persistent store. I'm wondering about performance, especially if it's appropriate to store (say) 10-50k worth of text in a database column.

My alternative is to generate individual HTML files, store them as resources, and find them dynamically. However, that takes more time to implement, and is not as simple as just plugging into my existing Core Data flow (i.e. adding a new property to the entity).

A: 

Though I did not benchmark it, I store several dozen HTML pages in a CORE DATA application with very satisfactory performance (read instant...).

-t

Tim
+2  A: 

You might want to think about moving these larger blocks into their own entities, so that they don't HAVE to be loaded into memory all the time. Otherwise, 10-50k doesn't sound too bad.

Ben Gottlieb
A: 

Hi, a bit late. Do you mean you preloaded the UIWebViews, and then store all the preloaded instances into Core Data? And whenever you need them, you just call the instances from Core Data?

ngzhongcai
You should not use answers for asking a question or making a comment. Stack Overflow doesn't work like a forum. To answer your question: no, not at all. What you're suggesting doesn't make sense.
Shaggy Frog