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).
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.