For an application which will allow members of my organisation to see data on their mobile device i need to store pre-formatted data on the device so they can see it offline as well. How they get the data is trough a JSON request-response.
The response is formatted as follows (anonymised ofc):
[{
"firstname":"John",
"lastname":"Smith",
"group":"1",
"age":11,
"installed":"Ja",
"medical":"Is aan zijn linker zijde verlamd geweest.",
"notes":"Heimee. \r\nBeschermend opgevoed. \r\nTerug getrokken persoonlijkheid.",
"Insignes":["test", "Test2"],
"Parents":[]
},
{
"firstname":"Emely",
"lastname":"Watson",
"group":"33",
"age":14,
"installed":"Ja",
"medical":"",
"notes":"Test",
"Insignes":["Veilig & Gezond I","CWO II","CWO III","Kampeertechnieken & Pionieren"],
"Parents":[
{
"name":"ouder ouder",
"address":"op | 0000AA Amsterdam",
"phone1":"",
"phone2":"0612345678",
"mail":"example#google.com"
}]
}]
I have read a couple of discussion on how to best store this:
Is it ok to save a JSON array in SharedPreferences?
How to save JSON Array in SharedPreferences?
Android: what is the best way to store JSON data offline for the app in android?
Android - how to add JSON object to sharedPreferences?
What is the advantage of Using SQLite rather than File?
From reading these I have gathered that SharedPreference files are "faster" than sqlite but are prone to corruption. SQLite is a database and since the data comes from one I am inclined to use that at the cost of processing speed.
Now I only need to store and then read the data, it wont be mutated unless there is an update on the "main server" in which case I will probably wipe the local data and repopulate it. In these threads i have read that storing JSON in sharedpreference is easy but difficult to read.
But after reading these (and more) discussions I am no closer to knowing/deciding what the best way to store my json is.
Any advice is greatly appreciated!
You can try the ORMs like Realm or sugarORM and store the json has object in the database. They also provide the Cipher options by which you can encrypt the data too, Which would be more flexible.
http://www.androidauthority.com/use-android-keystore-store-passwords-sensitive-information-623779/
http://www.androidhive.info/2016/05/android-working-with-realm-database-replacing-sqlite-core-data/
If you don't need to use any ORM by third parties then you can directly encrypt the JSON string with the android keystore keys and then can store the encrypted string in the normal sqlite.
This is opinion based answer. Android no I wouldn't store JSON in a DB or preferences. Store the json in a file. A file can be accessed as stream the same way you stream access json. Virtually no upper limit on size in a file. I might store a link to the json file in a DB or preferences. Depending on application I might just extract json into abstract elements and store in DB for ordering selection.
The data you have provided depending on sensitivity I would extract and insert into the contacts database for the device.
The best option is to go with a database approach, for one it sounds your dataset might be large are rather expected to be large. Database persist large sets of information, however I do not recommend using SQLITE , for it is sql based, no ORM and the operations can get tedious and time consuming and mainly it is slow(debatable). Rather use the hottest and latest no-sql database for android and ios, which Realm, realm is super fast, it is based on java annotations and ORM(like hibernate). To work with json in android I recommend familiarizing yourself with GSON, A Java serialization/deserialization library that can convert Java Objects into JSON and back.
Shared Preferenences are really convenient to store small key value pairs, If you have a relatively small collection of key-values that you'd like to save, you should use the SharedPreferences APIs. A SharedPreferences object points to a file containing key-value pairs and provides simple methods to read and write them. You would of to still work with gson here, I never heard of a shared preference getting corrupted, what I do know is that they are fragile,and live with the existence of your app installation.
Conclusion: If your dataset is large use a database approach to persist large dataset, maintenance and modifications are more fluent here, however if you know that whatever you are storing is relatively small, use a shared pref, and to manipulate json constructs in android to and fro use the google gson library.
SharedPreferences :
If you have small amount of data in Json then you have to store it in SharedPreferences.
You can easily store Json to SharedPreferences using Gson. Just using this :
Convert Json to String :
Gson gson = new Gson();
String jsonString = gson.toJson(jsonData);
Convert String to Json :
gson.fromJson(jsonString, TypeToConvert);
Sqlite Database :
If you have large amount of data in Json then just go with Sqlite.
Related
Implementing and managing remote or cloud databases in Android Applications is new to me. I am currently making an app that would take in thousands of "entries" to a form, think of it as an attendance app. Right now I've decided to use JSON as my database type and Parse as my BaaS. I need some tips on my decision.
I don't actually see JSON suitable for this because it is a "text" file that can easily be modified or if I somehow accidentally append an extra bracket it would render the whole database corrupt whereas SQL use queries like INSERT which I think is more secure. I just picked JSON because it works well with Parse. Do you think this is a good idea?
Another is what if the JSON file will accumulate tens of thousands of entries, how do you manage this huge database? Do you split it into several files (eg. every 1k entries make another JSON file) or is it enough to just dump all the data in that one JSON database file?
When using BaaS do you just sync the data in that server or do you also make backups of some sort (I don't really know how to put this)?
Thanks in advance!
JSON is not a database, but a data interchange format. You can have a database that uses JSON for communication, for internal representation, etc. but that does not make JSON a database in itself.
Parse itself manages the organization of the data. You communicate using JSON but don't have to care about how it's stored, updated, etc. internally.
So in your app, you should use SQLite for storing such amounts of information, or, depending on the app, just send it to the Parse server and execute the queries against it. You can see how it's done in the Parse Android documentation.
In my android app I load some data (JSON) from wed server. And I need to store that data.
All data, which I want to save - it is fixed number (for ex. 5) of JSONObjects with 30-50 fields.
Is this good idea to save each JSONObject in Preference? Or will be better to use SQLite?
note: why I ask?
save in Preference - implementation take 10 minutes.
use SQLite - implementation take one or two days, and required to
edit database, when I will add new fields.
I'd prefer database, and if you need 2 whole days for a reasonably simple database setup, you should perhaps take any chance to practice with it.
However, if you're sure you're never going to have any advantage of (complexer) queries, then saving it into a database might not give you any real advantages.
I would prefer sharedpreference here , because size of data is not too big. If size of data was too big and had many fields then database would be first choice. You can save the whole json String into preference and use it after parsing at run time.
My implementation choice would be a database table that stores the object as something you can then transform into a native intermediate object. By keeping the local data stored as JSON you're potentially locking yourself into keeping a JSON parser within the app for the foreseeable future even if your web service changes its format.
For example, if your web service changes to XML you're still going to have to keep the JSON parser in the app to handle those users who upgrade the app and have to do a data migration.
You could save JSON directly in SQLite database. If you parse data and then save in database then it would take some time for you to make everything work. But think about saving JSON directly in database. It will require two fields only in database link and json response.
Advantages:
- Big time saving
- You could save the same solution in your future apps for saving JSON in database.
Disadvantages
- You will not be able to query data
- You will have to parse every-time
I have 30 objects, each instance consisting of 7 string fields and a small bitmap.
These objects will be destroyed and recreated daily.
In my android app, would it be more efficient to write and read this data from a db? or to simply create a new class and create the 30 instances and store them in an array?
Memory efficient/performance/etc.
Thank you for your time.
If you do not want to write boilerplate code for database you can save your objects in JSON or XML format as files.
You got two ways:
Store in filesystem using serialization to store and deserialization to read
Store in JSON or XML natively and write converter between your class and needed data format
Database is good solution, because SQLite in Android is real fast and so on. But if you will want to change structure of table you will have to write ALTER TABLE queries in onUpdate() method of SQLiteOpenHelper and other troubles.
So I would recommend to use XML or JSON to store data.
Upd
Also, you can mark your custom data class as serializable, store values in ArrayList or other structure and serialize it to store, then deserialize to read.
Write the items to a database because they need to be persistent, if only for 24 hours.
You should store the image files in your Internal Storage sandbox and reference them by filename in the database because it is usually inefficient to store even the smallest Bitmap blobs in the database.
For a limited number of object I think you are batter with Object representation and storing them in an ArrayList. DB design for a large number of entries.
But if the data needs to be saved for all day you are risking in loosing it by a GC if you leave it in memory, in that case you have no option but to store it in the DB.
where are you getting this data from?
I am accessing the datas from json, storing the datas from json in sqlite and then retrieving it and display them on screen. It takes too long time for this process. Which is the better way to reduce the time consumption instead of storing and retrieving the datas from sqlite? Can anyone help me in this issue?
You can store the JSON as plain text in a file.
A nice place to put them would be your application's cache directory.
https://developer.android.com/reference/android/content/Context.html#getExternalCacheDir()
https://developer.android.com/reference/android/content/Context.html#getCacheDir()
You can store a JSON Data in a File or in a Shared Preference. Check Saving data in android training
I also use the file system to store json. It can be easier for debugging as you can have the json.tostrong methods indent the json yo make it easier to read using the android file browser.
i make a filesystem class that accepts and returns json so apps just see the file system as a json store.
I'm very new to Android and I'm currently working on Android app that will parse JSON from a Restful API and display some of the data in a list view. I've looked into using GSON for parsing as the JSON was quite complex. Now my main problem is figuring out how to store the data somewhere so the app doesn't need to reload itself every time the activity is clicked on. I've looked at few questions here but they all seem to point to JSON only not GSON. Could anyone recommend an efficient way of doing this?
Thanks
if you want to store the data permanent it's the best way to insert your deserialized objects into a sqlite database or store them local to the disk as a file.
if your intention is to load the data for each startup, it's easier. just put your object into a public static object. so you can check if the object is not null or not. if it's null you have to load the data.
another opportunity is using the SharedPreferences.