1

My app needs to store data on the phone, but I'm not sure what's the more efficient method. I don't need to search through the data or anything like that. I just need to be able to save the app's current state when it closes and restore when it's back up. There is between 1mb and 10mb worth of data that will need saving.

There are basically a bunch of custom classes with data in them, and right now I have them as Serializable, and just save each class to a file. Is there any reason for me to change that to store it in SQLite?

user496854
  • 6,461
  • 10
  • 47
  • 84

3 Answers3

0

If you where to use sqlite you could save as you go, and know that whats in the DB is pretty much uptodate if the app/activity holding the data is suddenly killed by the os. Other that that I cant see and obvious reason to use sqlite for your use-case. Also for the sql approach you have a clear cut way to change the structure of your domain objects at a later time and to migrate the data from a old to a new version of your database. This can be done using serialized objects as-well, but then the objects needs to be duplicated, both new and old at the same time. And that to me sounds very very scary and messy, especially considering that you might need to go from version x to y, so you might end up with some pretty tricky problems if you ever need to update the domain objects. And I can honestly not see any benefits of using the flat-file/serialized approach.

Carl-Emil Kjellstrand
  • 1,233
  • 1
  • 10
  • 17
  • So purely from the speed and memory menagement standpoint, the way I have it now (saved as a file) is better? – user496854 Apr 14 '12 at 01:43
  • Might be faster to write to file from a serialized object, rather than writing all the data to a sqlite, but that's really up for debate, and only when your refreshing every single value. So if the normal case is that you only need to refresh 10 out of 200 values, the sqlite would be far superior for writing. For reading on start-up i guess you always need to read everything, and then the speed difference would not depend on the amount of data, but to know what alternative is faster, you really need to try on a device since there are so many variables that comes into play here. – Carl-Emil Kjellstrand Apr 14 '12 at 06:00
0

You mention in your question that the data is only meant to save the state of the app, therefore my initial response would be to keep it on the devices especially since you mention that the file size would not be much more than 10MB, which is quite reasonable.

So my answer to you would be to keep it as is on the device. If your usage of the information changes in the future, you should then reconsider this approach, but for now it's totally logical.

Jean-Philippe Roy
  • 4,752
  • 3
  • 27
  • 41
  • It's on the device either way, whether it's on the fice system or in a database. I just want to know if it's more efficient in any way to use SQLite. – user496854 Apr 14 '12 at 01:42
0

If you're only saving serialized classes, you could use an ORM mapper as discussed in this thread . This saves you the inconvenience of writing your own mapper and is easily extendable to new classes. Also, if your requirements change, you COULD lookup data.

The only reasons for changing your system to SQLite would be more comfort and maybe a more foolproof system. E.g. now you have to check if the file exists, parse the contents etc. and if you'd use SQLite, you don't have to verify the integrity of the data and Android also helps you a little. And you could use the data for other causes, like displaying them in a ListView.

Community
  • 1
  • 1
mistalee
  • 881
  • 6
  • 14
  • So purely from the speed and memory menagement standpoint, the way I have it now (saved as a file) is better? – user496854 Apr 14 '12 at 01:45