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.
Related
I am creating an Application in Android that uses a SQLite database. So far i have 3 table, one of which is used to link the first two tables together with foreign keys.
I have been reading a lot online about CursorLoaders, Content Providers, AsyncTask, URI's.... etc. A content provider seems like over-kill for my application, I do not intend to share this SQLite data with other applications.
My question: Is it a good idea in Android to create an object model of each row of Data from the database? My application wouldn't realistically have more than 500 objects from these databases, but is this good design/approach?
More Details: If I were to go down the Object route, I would use these objects and map them to Listviews mostly. Some of these objects may contain arraylists of other objects, Say for instance mapping these kinds of objects to expandable listviews. I tried this approach and it worked really well, I am just unsure of making all of these objects is wasting resources, slowing things down, or will it become a problem later if I decide to expand the application? What if i had 5000 Objects? Just unsure if it's a valid programming approach.
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 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.
I am unsure if I should use or not Android SQLite database with my Android program.
The program has several tables, and I have operations for quering, updating and displaying these tables. However the total amount of data is not very large (maybe tens of rows at most).
I was told by some people that I should not use databases any more as storing everything into flat files is easier to implement, the finished implementation is easier to maintain and the database engine can be replaced by collection framework that stores pre-loaded flat files. These people have some weight in decision making so I need argumentation if I still want to use the database.
Would it be possible to get argumentation when Android SQLite database should and when it should not be used?
The concept of a ContentProvider abstracts away from the actual technique used to persist your data. It allows you to nicely separate the implementation of your data source and the visualization of this data. In this respect, I don't think that easiness of implementation is a good argument for or against SQLite. If you use Cursors, you probably will use a ContentProvider anyway.
If you perform a lot of (complext) queries, the query performance might be an argument in favor of SQLite since this is what is is built for. Moreover, it seems much easier to debug an SQL database than a flat file.
In my app I have to download JSON data from numerous web services. The data classes I use are fairly complex ones (lots of properties, quite deep inheritance tree, etc.).
I intend to do caching, using a single db table, where I'd store the downloaded JSON data in a VARCHAR column (along with other meta-data containing columns). JSON serialization is being done with the Gson library.
It seems quite convenient to just dump the instances into JSON, and parse them again later when I need them. No need to create custom tables for every class, or write loads of custom serialization code. Also, I can do queries on the cache table this way.
The question: Is this approach an anti-pattern by any means?
There is absolutely nothing wrong with this approach; however, I am going to recommend that you instead use the built in caching storage. See the section called "Saving cache files" in Data Storage for more details.This way you don't hog any precious space if your JSON objects are large in the event of a low memory situation.