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.
Related
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 am looking to use an XML file to store the data my Android app generates. With that in mind, I have two questions for the community:
Is XML the best way to store data on Android and most efficient in cases where data may be added or altered every second or less then a second.
If XML is indeed the best for the scenario described in #1, how do I go about setting it up?
1.) Is XML the best way to database data on android and most efficient in cases where data may be added or altered every second or less then a second.
Definitely not.
2.) If XML is indeed the best for the scenario described in #1, how do I go about setting it up?
If you plan to store data just locally, the best way would be SQLite which works as a local database on every device.
If you later plan to synchronize this data with a central database, you may do this asynchronously within an AsyncTask or a Thread which would run periodically, but writing each second into a XML file is a bad idea as far as performance goes.
It's probably also a bad idea synchronizing a remote database at each insert/modification/deletion operation as if you had many users you could collapse the remote database.
I think the best approach is (as previously said) having a local database where you would store that data, and implement a webservice in the remote side if needed and use it to periodically synchronize both databases.
I would use JSON over XML and I would highly consider using GSON from Google. You maybe want to consider writing directly to a database with it's own structure and use transactions and sets. Is there are reason you want to go through JSON/XML?
XML is one of the worst ideas to keep local data in Android.
Most common used is SQLite available on the Android platform, but it all depends on what data and how you want to use.
In many mobile applications you don't need the relational database for one of the following reasons:
You have no relational data (i.e. settings) => no point in making relational tables with 1 record each
You have small, and dynamically changed data (like cache for downloaded content)
You don't need to search for data (using indexes etc.)
What alternatives can be used?
Shared preferences - simple key/value storage of primitive objects
Data serialization - for your consideration - binary (native java), JSON, parcelable (can be combined with the shared preferences)
For most of my app I'm currently using the binary serialization for "local storage".
- It's fast enough (usually much faster than starting the local SQLite engine)
- It's extremely easy and quick to implement, especially when you are using it for json/xml downloaded data parsed to POJO objects. All you need to do is just put "extends serializable" and put few lines of code to serialize/deserialize whole structure
- You can use those same classes for keeping data locally and communication with backend
Of course - it all depends from the situation - if you want to keep locally log of data from some sensor, or allow others apps to use this data, have to quick filter 1k+ records, or you really like to write few hundreds lines of code SQLite will be the best option for you. But most of mobile applications has no clear reason to use the relational (and trust me - not perfect one) engine.
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.
I can't choose between SQLite and SharedPreferences.
I can use
JSON.parse(SharedPreferences.getString("data","qweqwe");
and
s.putString(key,JSON.stringify(JSONObject));
Or create a new, big class to store my (text) data in SQLite. (PS: JSON.* is my own class)
What will be faster, better?
I know that SharedPreferences is for "key-value" data, SQLite - for big amount of structured data. But in my case storing JSON-formatted data in SP and accessing by key would be easier. Main question - will it be slower or faster? Pros and cons?
On the one hand this is a slightly subjective question (and not the best fit for stackoverflow). On the other hand, taking your question title literally, the objective answer is "No, it's not bad".
The reasoning is, however, slightly subjective as it 'depends' on the situation.
The SharedPreferences class is effectively a wrapper / helper for a file stored in an app's private (internal) storage - as I understand it, it's an XML file. Based on that fact, ask yourself again..."Is it bad to save a JSON-formatted string in an XML file"?
As you mention in the commen on your question, using a SQLite database will mean writing extra code whereas the advantage of SharedPreferences is that a given preference file is accesible by name by any Android class which extends Context including Application, Activity and Service.
I thought about this and had some practice.
So, using SQLite (in my case) is better that using JSON-formatted string in SharedPreferences, because I can just update only one-two rows from a table. With SharedPreferences I have to:
use new JSONObject(sharedPreferences.getString("json_string","qweqwe");
some manipulations with object
edit my SharedPreferences.
seasoning to your taste
Put my JSONObject().toString() back into SharedPreferences. It's all.
IMHO, it's more complicated for the device. Because it cannot be seasoned
If I wouldn't need to update an individual parts of data, I'd rather to use SharedPreferences, because for static data, which I don't need to update, is faster.
I have used this approach in several projects without any issues so far. But there are certainly several advantages to using an SQLite database; particularly, the versioning/upgrade features of SQLite, and the powerful SQL querying language. If you ever need to migrate data to a new structure of storage, the upgrade and onUpgrade callbacks in the SQLite framework can be immensely helpful.
If you are keeping it simple, JSON in preferences can be very quick and extremely easy to implement. In terms of security, preferences are slightly more "exposed" than a database in that they are simply stored in xml, but ultimately the database file for an SQLite database is stored the same way and can be read during an intrusion as well.
I haven't had any performance issues using JSON/SharedPreferences yet, but I also haven't done any profiling to test this. My mindset has been to keep the code simple and not optimize prematurely - if performance issues arise, do the work of profiling it at that point.
Ultimately, I'd say that there is nothing inherently wrong with using SharedPreferences in this manner.
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.