I am developing an Android app that will display a list of PDF documents. The document list is a JSON file (which is currently used in a web application). My question is: does it make more sense to store the JSON file as an asset or store the JSON as stings in a variable in a class? The JSON is static and I only read from the file, there's no writing.
I don't think it really matters - an assets file is a little more complicated to read, but it's not a huge deal.
But it might be easier to work with - you can just replace the file, edit it in whatever external editor you want, maybe generate it automatically from some other tool. That's easier with a separate file than something that has to edit a string within a Java file or whatever, you know? Plus JSON can be awkward to work with without a nice editor checking it for you
And it makes testing easier - you can write it so you provide a different source file, have a different set of assets etc, which you can't do so easily if you hardcode the JSON.
And you'll probably get better build times if you're just modifying an external assets file - no changes to the actual code files means they don't need to be rebuilt.
Most of this stuff probably doesn't matter! Just laying out the stuff that could be a consideration - but if the string form is working out fine for you, why complicate things?
Related
I am about to implement backup for my Android app, and my issue is: The data resides in an sqlite db. Some of the data are just there for user convenience, and can be recreated from other sources. So in order to minimize the size, I wish to export relevant data only (the limit for backup using the Google API is 1mb).
All the data has class equivalents, which are populated via my SQLiteOpenHelper implementation. This means I can implement serialization.
So far I can see the following options:
Serialization using Java Serializable, and write all objects into a binary chunk and pass it to writeEntityData()
Serialization using XML or JSON, perhaps together with the zip API and dump the file as a binary chunk
Clone the database with relevant objects only. Probably a lot of work.
So far, using XML or JSON seems to be the best option, as I can reuse that for data sharing across users/devices. Java Serializable seems to bloat the size..
Would like to hear your opinions on this !
I recommend you to use vacuum() in order to shrink the db size, or use the auto_vacuum pragma.
If your db is something big, you can try to zip it.
Delete all unnecessary libs (compat_v7, for example, if you don't need it).
Try to compress images with optipng.
Try to convert your wav or mp3 to aac.
And... we are talking about how many Mb?
We are currently writing an app for mobile platforms which is going to use a quite sophisticated data structure.
The data structure is organized in a tree structure and should contain both data and text.
Of course XML is a really good choice to store data organized in a tree structure. Our problem is that we need raw data blobs (a couple of MBs in size) to be written into the file.
When using XML, the blobs need to be encoded in base64 or similar which will significantly increase the file size ...
Thus, we considered creating our own binary format.
We don't have any experience in designing file formats and we are having a hard time figuring out how to get a tree structure and also variable length data blocks in a self-designed file format.
We need this to run on iOS and Android.
Does anyone have experience in how to do this or what to use for this?
I want to give backup facility in my android application. So for that purpose i don't know which which format will be suitable. I am thinking either XML or CSV. Please tell me which is efficient.
It's my opinion that you're probably better off using JSON, as it has many great advantages as listed below and given your data, wont be considerably larger than CSV or Binary.
Take a look at this post for details on how to implement it:
How to parse JSON in Android
The following is a general breakdown of the different data format options:
XML
This format is the least efficient (file size and time to parse), but comes with the advantage that it can be easily debugged or modified/read by a person. In general, use this if you are going to be reading the content, displaying it in some other program or the file will be small enough that it's size and processing disadvantages don't have a significant effect.
JSON
More concise than XML, while still maintaining it's human readability. It's syntax isn't quite as simple as XML but it's still very simple. I would recommend this over XML.
CSV
This format is much more efficient than XML, but is prone to errors if modified manually and can be very hard to read. You will likely require special care in dealing with the delimiting character so you'll want to find yourself a simple CSV library. It's disadvantages are that although
Binary
These formats will be read/written to a file as bytes. They are structured in such a way that only your specific application/reader will know how how the bytes are structured. This format is the most concise and has the best read/write performance, but of course, it's practically impossible to modify or read.
Edit: Also worth considering is your ability to modify the format of the data, for the purposes of supporting future version changes. Using JSON or XML allows you to easily add new fields or ignore existing ones and so can be easier to maintain backwards compatibility for existing applications without breaking their functionality. A similar solution for CSV or Binary would require that you store and check the data format version number with the files, and then manually switch between loaders in code.
I'd go (and I use them in my apps) for CSV files, since the data are crude and concise (i.e.: small file size and fast to read/write).
I won't choose XML files, which put a lot of garbage in the file, bloating them ridicolously.
I've been messing around with Android, after having read Android Application Development for Dummies, and nothing else (just to illustrate how little I know) I'm trying to create my first useful, but very simple app.
The app should do the following:
prompt me for a password
read a string (persisted somewhere in the memory)
use my password as a key to decrypt the string
parse the string as xml and display the data to me
other than being a coding exercise, this would serve me as a sneaky way of storing sensitive data that's too copious to remember.
I don't want the app to handle input of this data, I want it to come pre-filled with it. (never mind reusability right now) I don't want to hardcode the string in the code though.
I've decided to store the string in a file in the app's internal storage (if this is a bad idea, feel free to suggest something else). I've found plenty of examples on how to work with these files. But they all deal with creating the file at runtime. What I'd like to do is create the file as part of my Eclipse project, and then have it available to the app at runtime.
Is it possible to do this?
What I'd like to do is create the file as part of my Eclipse project,
and then have it available to the app at runtime. Is it possible to do
this?
Yes it's possible, you can create your file in the assets or res/raw directory, then fill its content when the app is running.
However, I'm not sure if this is the best place if you have sensitive information to store in.
I want to keep some information in a xml file, and I want to let the user update that file. Later I will parse and use that information in my app.
Before rolling my own code to create the UI to let the user do this, I was wondering if Android already has something along the lines I could use?
Android doesn't provide XML generation code itself, but there are plenty of Java resources for it, such as JAXP.
Take a look at using the DOM parser library, that Android has as standard. There are a number of tutorials for this online. For general parsing you might tend to use the SAX parser library due to the fact that it has lower memory requirements, but the DOM parser library appears to contain all of the standard methods that you would use to modify the DOM structure once it's in memory. Just as an example, the Node class has an appendChild() method.
Once you've modified the DOM in memory, hopefully there is some way of persisting the modified Document object for later use (e.g. persist to file), though I have no first-hand experience of doing that.