views:

757

answers:

3

I am developing an application that periodically sends information to an external server. I make a local copy of the data being sent, for backup purposes.

What is the best option to store the data in terms of saving battery life? Each data submission is a serialized object (the class has 5 fields, including a date, numbers and strings) of about 5K-10K.

Any other idea?

+3  A: 

I have no idea in terms of battery life directly but one criteria would be which is easier to manage? Fewer operations to manage the data would mean fewer CPU cycles and in turn longer battery life.

I would say the SQLite option is easier. You can put a date column in the SQLite table which stores your data which makes removing old submissions which you don't need any more very easy - and all handled via the native SQL library. Managing a whole load of file - or worse a single file - with your own Java code would be much more work.

Additionally, you can write data the to database and just forget about it until you need to read it again. If you're storing data in files, you'll need to work out when you should be reading and writing files in terms on the Android application life cycle. If you're worried about battery you probably wouldn't want to write files more often than you should, and cache data in memory, but you'd need to make sure you didn't lose any data when your app is Paused or Destroyed. In my opinion it's much easier to use an SQLite database and not worry about any of this.

Dave Webb
Thank you for your comments, seem very reasonable. Do you know if the database is always running in the background (as a traditional database), or if it is only running when an application uses it? I mean, if the "SQLite server" (if such process exist in Android) is started just because of my application... maybe it is not a good idea.
Guido
afaik sqlite is just a file that you access through libraries, there is no database server running.
tosh
+1  A: 

I don't believe it matters whether you use SQLite or a File, because the SQLite db is simply a file on the system (stored in /data/data/<your_package>/databases/). You'll need to commit to the db at the right times, just as much as you would need to save a file to the hard drive at the right times. In other words, one way or the other you can use just as many hard drive writes.

I think that what you choose depends more on what sort of data you are saving. If you need the powers that having a db can bestow (such as querying), then by all means use SQLite. However, if you don't need a db, or you've got data that varies wildly (and can't be easily setup in a relational database) then I'd go with files.

What I can tell you for sure is that you should not use serialization for saving a file, if that is the route you choose to go. Android serialization is slow, slow, slow and creates large files. It is much better to either write your own XML or JSON format for performance reasons.

Daniel Lew
+1  A: 

Is your application multi-threaded? If you have multiple threads accessing the data store then I would go with SQLite. Let SQLite worry about locking issues.

Bryan Bedard