Question

I have a content based, read-only iPhone app. Users can select favorite topics, which I need to track. Some topics I’d like to make available between app updates through the App Store. I’ll need to track if users have downloaded these particular topics or not until the App Store update is available. This approach will consist of two tables for user tracking. All other tables contain mainly static content, save any new downloaded entries.

Before I began tracking user content, I’d always deploy the database on app updates. An overwrite – simple. But now I need to track certain user configurations. Rather than trying to keep track of which app version a user has and running through a list of sql scripts in the correct order, so the user is at the right database version, I’m thiking to use two databases. One contains static content and the other user data. The static content database is always overwritten. That keeps things simple. The database currently is 250kb. It will grow very slowly.

I have plans to use SDK 3.0 push notification and peer-to-peer as well, which will store any user config data in the user database.

Any one see problems with this approach?

Answer 1

This sounds alright to me. If you’re using SQLite, you may want to look into the ATTACH DATABASE command, which lets you keep two databases open on the same connection.