In my android application I have to store some application settings and some user information within the phone.
I can go for the shared preference option explained in this DOCUMENTATION.
But wondering if I can store data as objects wise within the phone. I found this Stackoverflow Question regarding saving serialized objects in files and bit not sure of any issues if I go with this way to store persistent data.
Also would like to know what the best way to deal with insert/delete/update and read with XML files in android. Would appreciate any guidance. Thanks in advance...!!!
If it is only a small amount of data you need to store, then go with the built-in shared preferences, that is what the functionality is there for. SQLite and OrmLite are a bit heavyweight in this situation IMO. Even if you want to handle the data as Objects; in which case I would serialise to / deserialise from JSON or XML stored in text files and handle the insert/update/delete on the deserialised objects in your model.
If you want to persist some objects I think you should use SQLiteDatabase, it would be a more cleaner solution than using serialization in files. You will indeed need to write some extra code for your Database but you will end up with a cleaner implementation in my opinion. You could also be using OrmLite for Android which is pretty robust and easy to use if you have some basic orm knowledge.
Related
I want to write an android calculator app like the one on my android phone. It saves history for operations and by clicking a button it shows last operations. Now my question is what is the best way to save operations? Is it reasonable to save them to a file in internal storage or what?
There's some options..
1) Include a SQLite Database, as others mentioned. This makes storing lots of information really easy. You can find tutorials on how to include one properly in your project, and don't hvae to care for much more. You can then work with content providers to read and store data.
http://developer.android.com/guide/topics/providers/content-providers.html
2) SharedPreferences. If you just intend to store like the last, or the last 3 Operations, you can just use shared Preferences. This is way less overhead than adding a Database, if it is a small project, albeit you will have to keep your data structured yourself.
http://developer.android.com/reference/android/content/SharedPreferences.html
3) If you just want to store the users current session you can just Keep a Stack of the used operations. On undo, or however you call it, you would just pop the stack.
By implementing onSaveInstanceState and Parcelable you can make sure that no data is lost on rotation / low memory and such.
I personally would advise you without knowing more about your project to use plain java objects and storing the state. A calculater would in most cases not need persistent storage. If you really want to know what the user did 2 weeks ago, you should use a Database.
I would recommend you to use database(SQLite) for storing the data.
If you don't know more about SQLite in android have a look at these
tutorials.
I think database should be handy for history if more than one operations has to be stored else for one operation you can use shared preference.
I have read through the Android Storage Options and I have a question that I haven't been able to find the answer to:
Should I use SQLite to store my data or should I use a JSON object that is written to a file?
Requirements:
Store (up to) a few hundred instances of the same object. Each instance will be somewhat complex, storing reference to images, smaller objects, etc. The data will be stored locally, with the option of cloud backup. All the data will be loaded on startup and saved when manipulated by the user.
The reason I ask this is because I don't have a lot of data to store - for a SQLite database there will probably never be more than a few 100 rows, which makes me think SQL is overkill.
Also, exporting my data to a JSON file will allow me to easily import/export from different device platforms (I already do this on iOS).
Or, maybe there's a better option? If there was an NSCoding type library for Android I would probably use that.
Any opinions are helpful.
Thanks!
From the presented so far, storing in files will be more advantageous.
Considering that each "unit" is less than 16 attributes, a json file with short identifiers will likely generate a larger file representation than the SQL representation equivalent.
However, the local file manipulation will allow for easier interactions, as well as easier backing up/down.
Also, the File class is simple enough to generate less issues when compared to SQL.
Finally, given the choices, you are going to have to evaluate the operations used.
If you are going to compare the data, then SQL is likely to go faster, but if you are just inputting/outputting each data as a separate object, than files are going to be as fast as SQL.
Finally, please, particionate your objects, do not create just 1 file with all the info.
I have read through the Android Storage Options and I have a question
that I haven't been able to find the answer to:
Should I use SQLite to store my data or should I use a JSON object
that is written to a file?
You need to analyse your requirement again.
maybe there's a better option?
It depends upon your requirement.
if Your requirement is fixed to simply storing and retrieving then you can have a look on tinnyDB, which is basically using the SharedPreferences as storage mechanism. But if you need case base based selection/query of data then you should go with SQLite.
I have a custom object, "TimeSheet", which itself contains Calendar, DateFormat, and int fields. The App is designed to use several of these objects, so I'm planning on storing them in a List as they're created and I'd like the App to be able to save these objects to internal storage when the App closes and reload them when it opens.
I'm still something of a novice when it comes to Android development (I've only published one App so far), so I'm not entirely sure of the best way to go about this. I'm guessing an ObjectInputStream and its Output counterpart are probably the best options, but I'm not entirely sure. I'm completely willing to change my design strategy to store a collection of these TimeSheet objects in the easiest way possible.
Can anyone recommend a good direction to go from here, and if possible, provide brief, simple examples?
Thanks!
There is no single right answer for something like this. A lot of it depends on the amount of data that you are storing. If you don't have much data, used SharedPreferences, if you have lots of data and it is complex, use a database. I wouldn't use a database if you don't have much data. You want to keep things as simple as possible and adding a database can complicate things. Here is a link that talks about the different options. Check it out. Hope it helps:
http://developer.android.com/guide/topics/data/data-storage.html
There are 2 ways to do this
Save it in a SQLite database..
Save the objects in a json format in a file
See this discussion
I'd honestly recommend using a SQLiteDatabase to store them: write functions to map your 3 fields to the database (Calendar would become a NUMERIC, DateFormat would be a String, and the int fields would all be NUMERICs) and to rebuild your object fields from a row in the database. Its a bit heavy up front but will make the inevitable feature expansion much easier.
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.
Is there any other alternative to SQLite in Android for persisting data in the phone? I am looking something like iOS coredata or something simpler like a key-value store. If we need to embed it with the apps, something that is relatively small in size is also great.
Thank you for your assistance.
If you need just a simple store for a couple key/value pairs, SharedPreferences is the way to go. If you are looking for something more powerful, that compares to Core Data, you should give greenDAO a try. Like Core Data, greenDAO a layer between your objects and the data store (Core Data on iOS usually takes SQLite, too).
I don't know anything about iOS but take a look at SharedPreferences
There are a few different methods for persisting data in Android. Read this Android article about it.
You could look at http://jdbm.sourceforge.net/: 78kb jar, transactions, will save to a file.
You could serialize to xml. Take a look at Simple http://simple.sourceforge.net/ it's less then 500kb in size.
There are three recommended methods to store data of your Android application ( according to Android docs).
If you need to save settings, configurations, user credentials
You could use SharedPreferences.
Pros: The data saved in SharedPreferences are comparably better than static global variable.
Because it is thread safe, data will not go away even after killing the app.
If you need to save big data ( e.g. accelerometer data, gps data), which is frequent, you could use SQLite database.
However if you just store big data but process them rarely, it would be better to save to a file. But make sure to cache data and save/append to a file at once ( Because I/O operations are CPU intensive and drains more power).
Exist a alternative call REALM is a complete library to manage the database like objects, similar to ActiveRecord (in Ruby on Rails). And one of his advantage is the speed in transactions. But be carefull because is a new library maybe is a good idea first read the all documentation.