Develop Reference

When should I use android SharedPreferences and when SQLite? [duplicate]

For persistent storage of data is there any distinct advantage of using a SQLlite database over SharedPreferences or vice versa? Currently my application data is only a couple of kilobytes in size, though it could conceivably rise to ten times that size in the future. I can't find anywhere that states how much storage is available using SharedPreferences but would imagine this would be one limitation of using it? Is there any difference in speed between the two methods? I'm looking to weigh up the pros and cons of those two storage methods.

Off the top of my head:
SharedPreferences:
Pro:
Lightweight
Quick and easy to use
Easy to debug
Config file can be edited by hand if need be
Con:
Slow when dealing with lots of data
Not helpful when the data is more than a simple key/value affair
Entire file needs to be read and parsed to access data
Takes up more space, each entry has a considerable amount of ASCII data around it, and all the data itself is ASCII too.
SQLite:
Pro:
Scales nicely
Changes don't require rewriting the entire data file from scratch
Powerful queries
Con:
More code to write
More heavyweight (code and memory), overkill when dealing with a little bit of data

What's the better method to store Android app's data -- in SQLite or on the file system?

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?

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.

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.

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.

Implementing Serializable in Android

I want to save my Android game state so the user can pick up and play from where he/she left off.
I have been reading about the serializable interface, but have some questions.
Aside from background rendering and a few other things my game is performed from one class.
Let me explain what that means. I have a class A, and all the different elements of the game are stored in various arraylists and such, in A. SO I have dozens of instances of classes B,C,D,E... all being called and updated (when the screen updates) from class A.
My problem is I am unsure what needs to be serializable. Every class B,C,D.. (i.e. every class? or just A? I don't see why serializing A and then saving the output in SQLite DB wouldnt store all the data.

Just as a suggestion, you may also want to look at Berkeley DB Java Edition, specifically at the DPL (Data Persistence Layer) API. Like SQLite, it's a transactionally protected, recoverable, fast, small footprint database library. However, the DPL allows you to directly persist your classes, making it a much easier choice for Java application developers.
Here's a technical white paper describing the API and how to use it.

if you want to serialize some object. then look at this link use other object in place of hashmmap object that has been specified in this link.

Where to store large application data on android devices?

I'm currently facing a problem where I should store my object structure on the android device.
The usecase: I'm starting a call to an applicationserver (with the great help of AsyncTask), get a well known response (xml-response) from the server, parse the data and transform it finally into my object structure (highly complex class diagram with many associations between the classes). So far it's working, thanks to the great XMLPullParser ;)
I'm wondering where to store (and of course share) the fetched data between my activities... I already know that I can use sqlite, but I do not have an or-mapper (like hibernate in the j2ee environment). I'm also not allowed to store this sensitive data on the device (in sqlite or file system), so my first approach was to store this data in a singleton (which is of cource being held in memory...). But what happens when system is getting on low memory, can android "destroy" the data stored in my singleton? I already read about extending the android.app.Application class... So what is the best way to securely store object data (called from "webservice") on android devices?
BTW: Android development is that cool! We are currently porting a Windows Mobile 6.5 App to Android and iPhone, and my colleague (reponsible for iPhone-dev) is complaining all the time^^

Regarding an OR mapper, I came across OrmLite the other day. It is a general ORM tool for Java, but it also has some special adaptations that makes it work for Android. I haven't had time to test it myself yet, but it looks promising :)
As for storing sensitive data on the phone, you really don't have the option of storing it only in memory (using some kind of singleton as you suggested). As soon as your application goes to the background, it can be killed instantaneously, so you have to persist what data you want to keep in some way. That being said, if you save data to Internal Storage, this will not be available for any other app on the phone (given that the phone is not rooted, because if is rooted this is easy to get around). I do believe that this same goes for data you store using SQLite, but I'm not 100% certain, so I won't guarantee it.
But basically, if you are sure that your app will only run on non-rooted devices, you should be pretty safe saving your data to Internal Storage. And if that isn't good enough, there there is the javax.crypto package, but I've never used that so I can't really say anything about it.

Android data storage - File vs SQLite

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?

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.

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.

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.