Question

I am writing a social networking android application. I have create a .Net webservice with a database on Microsoft Azure, and I plan to call that web service to get data from the cloud and display it to the user. Similar to Facebook.

Now, I have two approaches in mind, and I’m not sure which one to implement. The approaches follow:

1. “Every time an activity loads, call the web service and reload all the data.” This, of course, is the easiest approach, but is it right? I mean, I have around 30 activities, and half of them load data, while the other half post. As far as I see, this approach can be a problem, because it might slow down the application. It can also increase my cloud bill with so many requests. And I don’t know if it’s right to reload everytime.
2. “Call the webservice every 10 minutes, and store all the data in a SQLite database, and only update the data if it’s been over 10 minutes, or possibly even have a refresh button.” This approach is probably the better one, but I’m not sure if it is even worth writing so much code.

I need you advice in deciding on the right technique. Number 2 looks good, but what if there is something I don’t know, and I’m writing all that extra code for no reason.

Please help me out here. If there is even a better approach, please do tell me.

Answer 1

It really depends on the sort of data, what sort of latency is required for the data and the quantity of data. Also the size of the project and benefit you will get from implementation as complexity will be increased. For a more precise answer provide further information.

Local caching can be a very good idea in this sort of situation. It is fairly common practice and there are multiple mechanisms which could be used. Depending on the format of data retrieved from your web service, you can store in a

1. Database, when data needs to processed (searched, queried etc) or there is a lot of data.

2. File(s), sometimes useful if you are working with formatted data such as xml or json as you can maintain the structure. You can use the native android caching to assist in managing the storage.

3. Preferences, when data is simple types (and strings) and there isn’t much of it.

Local caching will reduce bandwidth consumption (will end up saving the user money which is always popular) and if implemented correctly memory and processing consumption. Possibly most important (depending on the data) it could allow for the effective use of the application when the user doesn’t have connectivity.

By the way 30 activities sounds like a lot, you should really look at reducing that by sharing functionality across activities, this should improve navigation, code bulk and memory foot print.

UPDATE from comments

From the limited information available about your project I would suggest using the database as your data store (if any) as you don’t want to be caching complete SOAP messages in files, and the quantity 40+ records may make preference storage difficult to manage.

However, as I have mentioned previously you need to consider complexity. When using the database you will have to create a method of construction (perhaps some sort of ORM) separate to your de-serialisation of SOAP objects because technically you will 2 separate persisted data formats.

I am not able to get a definitive answer because there is still very limited information but you need to evaluate the cost of adding such a feature to your project and the benefits you will receive.

I few other things worth mentioning when considering this sort of caching.

• How you will manage the cache, it’s size and data integrity.
• When will you cache, as soon as you have de-serialised your SOAP objects? when you have finished with the data? etc..
• How will decide when to use the cache and when to hit the network?