Develop Reference

Caching in Android

I'm currently developing an android app in which I'm dealing with php files that returns json, the json then gets parsed and is used to fill up an arraylist of different objects.
What I'm trying to do is, I want to cache these objects in case of no internet so I can reload them and make the application useable offline.
Currently I have 2 solutions for this:
A) Make an SQLite database and creare tables with the same structure as the objects I'm trying to cache and then reload them on startup
B) Save the JSON strings inside the shared prefs and parse them on startup.
I didn't really find any best practices or tutorials when I came across data caching so I'm lost now and I have no idea what to do. So if you guys can please help out I'd be thankful.

You might find the following talk interesting:
https://www.youtube.com/watch?v=xHXn3Kg2IQE
As you can see, a lot of scaffolding goes into the ContentProvider approach. For a very simple app, it can be acceptable to just cache some JSON in a SharedPreferences. However, as your app becomes more complex, the advantages of the ContentProvider will be worth it.

You can use files instead of sqlite and shared preferences.
Shared prefrences is using for small data.
Sqlite is using when you need to make queries on stored data.
So I think it's better to cache in files, or if you are using something like retrofit or any network lib you can check if they support caching and use it.

Definitely not option B. Shares preferences are not suitable for storing large amounts of data. It's XML so cannot be queried like Sqlite. The time to retrieve a single item will increase linearly with the amount of data stored. Secondly JSON will have special character these will need to be escaped which means the storage size will increase even more.
There is however an option C. Using cache files. This approach and other store options available to you are described in the google developer guide and this is essential reading.
So in summary: you options are to parse the JSON and store it in sqlite or to save the json as a file in the cache directory.

Using XML to store data

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.

SQLite or Serialization

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.

Deploying large amounts of static data with Android application

I have an Android app that needs to work offline and requires a lot of static data.
Currently I'm using a JSON file in the /res/raw and loading it with the Jackson parser into my POJO scheme. It works really well since I have an external program that will be generating this data and once in a while when there is a change I'll just publish new version to the Market so I don't have to deal with running an update server and so on.
However, right now my JSON file is about 2.5MB with limited dataset for testing, in the end it'll be about 5-10MB.
The issue is that it already takes about 3-5 seconds to parse the file and this needs to be done every time the application is restarted.
So, what are my options here? I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit. But then I could only query the things I need at the moment and not loading the entire thing at once.
Is there some easier/better way? Also, is there a good way to publish the app with the sqlite database? All the articles I've found talk about creating the database for user data at first startup, but this is not user data and I need it to be deployed from the Market.

JSON feels like the wrong approach for this - it's a good way to encode data to transfer, but that's pretty much it.
It'd be nice to have a bit more info on what exactly your app does, but I'm struggling to imagine a use-case where having several MB of POJOs in memory is an efficient solution. I think it'd be much better to use SQLite, and this is why:
I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit.
You can still use your other program's JSON output, but instead of loading everything into POJOs with Jackson, you could populate the database on first app launch. This way, the app boot time is negligible if the dataset is unchanged.
If you still want to work with POJOs in the rest of your app, it'd be trivial to write a query that retrieved data from the database, and created objects in the same manner as Jackson.
But then I could only query the things I need at the moment and not loading the entire thing at once.
What're you doing that requires access to all the data at once? Searching or ordering a set of objects is always going to be slower than a SQL query to achieve the same thing.
Also, is there a good way to publish the app with the sqlite database?
You can definitely ship your app with a database, though I've not done so personally. This is a relevant question:
By Default load some data into our database sqlite
Hope that's of some help.

There's an excellent API called JExcel (just google it) that works with .xls spreadsheets. If you're not going to be doing any selecting and just loading data from a source, I like to use JExcel because it's more manageable from a desktop and produces easier-to-read code.
Not sure of any performance differences, however. Just throwing in my 2 cents :p

Store JSON in an sqlite field?

I'm writing an application that communicates with a web API, which responds with JSON. Currently, I'm translating the JSON objects to Java objects using gson (which is awesome, by the way).
Now, I want to store some of these objects in an SQLite database. However, they have lots of properties that would never be used in queries (i.e. I won't be ORDERing, WHEREing, or anything like that with those properties), so I feel it's unnecessary to create columns for all of them. What I'm thinking of doing is:
Only have columns for the essential data that will be used when querying the database
Have one TEXT or BLOB column (which one do you recommend?) that stores the actual JSON, so I can recreate my Java object from it and access all the data.
This would both make my life easier and streamline my code (I would not have to write very different code when dealing with data from the API vs. data from the database).
However, although I see no downsides, it feels a bit fishy.
What kind of trouble do you think I would run into if I use this technique?

The main thing I wouldn't like about it is relying on the structure of the stored/retrieved JSON to be valid, since it's completely out of the hands of the database. Not that you can't take precautions against possible issues, but if the JSON is somehow truncated or otherwise compromised in a way that trips up the parser, you're then missing the entire object instead of just one invalid or truncated property. If that's an acceptable risk, then it's probably a reasonable technique.