I work on an application which contains complex data, like user list, images, long ArrayList etc. I look for advices to save properly the data. I wonder if marshalling was safe or do you suggest me to use SQLite ? Because if I save an user created object in a file, I think that I couldn't open it if the object class changed (for exemple if you add a field to your class).
I have no idea what to do exactly.
SQLite is very powerful, but not always necessary. You can get along just fine by serializing your data to disk using something like Gson in many cases. If you're dealing with lots of data, SQLite probably the best bet, but as you observed, it's inflexible at times. You'll have to map your model objects to tables and then write upgrade logic when the structure of your models change.
I recommend starting with serializing/de-serializing your data to/from the disk to start. If the amount of data you need to handle makes this unwieldily, migrate to SQLite. If you do go that direction, look into GreenDAO or OrmLite.
Use SQLite. It will process the data in the fastest way possible while creating the possibility to execute complex queries.
Related
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.
I'm writing an application which needs to store data. A single pack of data is about 4 classes with many dependencies between them. For example, class A has a list of objects B and B has a list of objects C and few more dependencies...
And I wonder what would be better. Keep them in SQLite db or serialize each pack separately and store them in serialized files?
For me the only right solution would be to save the data inside a database especially if there are any dependencies. For beginners it might be hard at the beginning to get into database creation. but after you have created a database in the right form you just have to insert the data and you won't have any problems in the future if you want to change something or expand your app. With simple serialisation the logic has to be solved inside the app and might cause more problems especially if you have any dependencies.
If you need a good tutorial for saving data you should look at this tutorial
http://thenewboston.org/watch.php?cat=6&number=111
For other different solutions for saving data there are also some tutorials on the website, Nr. 108 - 110 of Android programming
IT depends on the usage of the data. You may do well choosing JSON/GSON serialization and avoid the overhead of doing ORM over SQLite. (Overhead meaning additional coding to marshall to/from the db) However, if your data is subject to growth or something that would be better managed by a db (a lot of non-sequential or random access across a larger data set) then go for SQLite and ORM. In the end it comes down to what type of data you are trying to manage. Again if your data set is something that could grow and involves a lot of random access it may be worth using SQLite.
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.
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.