What will be the better way for data retrieval on application that needs to handle limited amount of data.?

Question

This is not really a coding question since, I am not adding any code in here. Since, adding my code snippets itself would make this question really long. Instead, I am pretty interested in knowing a better ways for data retrieval on application that needs to handle limited amount of data which isn't updated regularly. Let's take this example:

I am writing an application which gets a schedule as an XML from server. I have written a logic in order to parse XML version and update database only if the version is newer than the local version. Although the update is checked automatically/manually on daily basis based on user preference, the actual version update happens only once per few months or so. Since, this is done by some other authority which doesn't provide API but, rather inform publicly on their changes.

The actual XML contains a "(n number of groups)(days in a week) (n number of schedule)" . The group is usually 6 and the number of schedule is usually 2. So basically there would usually be only around 100 strings.

Now although I have used SQLite at the moment. I want to know how to make update on database. Should I show progress dialog that the application is updating and exit the app when it's done? Since, my updates are infrequent i don't think this will really harm user experience but, is there any better ways to do it? Because I don't want update to be made when user is searching which is done using database. This will cause an database already open exception. Atleast I have faced this problem before.

Is it better to rather parse XML every time when user wants to view certain things or to use SQLite? Since, I make lots of use of adapter in my app to create lists, will that degrade the performance?

It would really be a great help if anyone can give me better overview about it. Or may be counter argument against each.

Many thanks!

Answer 1

1- Since the updates are infrequent, you have a good chance to do them in a background service, so it won't interrupt the user experience.

2- It is a bad idea to parse the XML every time since it does not change that often, using SQLite will be much faster.

Answer 2

Your architecture is fine, you just need some tweaks for updates:

• have your app close the SQLite file when not actually reading/writing to it. This will let the background process update most of the time.

• have your background process loop around, waiting for the sqlite file to be free

• (alternately) have your background process write to a updates file, and your app checks for the updates file at startup and periodically (when running). It then imports the data from the updates file. (Note: when creating the updates file, write somewhere else, them 'move' the file to the updates file to prevent races from a partially-written updates file.)

Also, do you need updates when the app is not running? If not, just have the app update at startup (if the data is stale) and periodically (in case the app is running for days).

There is no need for a progress bar as long as updates are quick. Even if updates are slow, you may not need a progress bar -- especially if you do background updates when the user is working on something else.

Ideally, at app startup you show the stale data, but have a little indicator that says "updating". When the indicator goes away, the user can assume the data is up-to-date.