What is the best way to store a data set locally on a mobile device for further processing in Java?
The data set is going to be retrieved using SOAP and will consists of about 50 to 100 'objects'. Each object is like an email thread - main message followed by several updates (mainly text, occasionally graphics).
Expected actions on the 'objects':
read
add new update / send an update to the server
change status / send an update to the server
Is it better to operate directly on an xml file, implement a local data structure or perhaps use a database of some sort?
Target devices: Android & Blackberry. I would like to keep the solution as generic as possible to make it easier to reuse parts of the code the mentioned platforms.
Many thanks, Luke
It depends on you:
If you want something fast - use SQLite database or Store it in XMl File.
If you want something easy to implement (but slower) - use SharedPreferences
If you are thinking about to use SQlite or Xml file than i will suggest you to use SQlite database because you need to perform such operation on the data.so reading from xml file and again writing it to file will be little slower than SQLite database.
Hope this helps.
Related
I am wondering if there is a way to cache arbitrary data from web requests onto the disk with Android. The flow I am thinking of is as follows:
The data is stored as a key value pair where the key is some identifier and the value is the raw data. Before actually making my web request, I check to see if the key is in the cache, if so, I skip making the web request. If the key does not exist in the cache, then I make the web request and store the data on the disk. I would like the cached data to be accessible across multiple runs of the app so that I don't have to make the web request again every time I start the app.
I was considering using SharedPreferences for this. Would SharedPreferences be the best way to go about this? Is it okay to store 1 megabyte of data in a single key in SharedPreferences?
The best solution to storing cache files is to store them in a cache directory. Luckily, the Android API provides a solution to this problem: Context#getCacheDir. You are able to create files in the directory returned, you can use a map to store an identifier for each file in order to retrieve them.
Although, this solution has a few limitations:
The system will automatically delete files in this directory as disk space is needed elsewhere on the device.
Cache data should only be used for temporary storage of information.
I may be coming late, but a couple years ago I made a library just for this:
https://github.com/fcopardo/EasyRest
The idea is to allow the app to operate with unstable or no connection without having to implement a secondary data layer for persisting data, instead, it keeps the responses for as long as you want, and refresh them without forcing the user to wait. Take a look, you may get some ideas.
I'm creating an app where it can have tons of messages (let's say around 10,000). The user can browse them, see, select, send (e.g., those apps that show quotes and allows to send to someone). What should be the best way to store these messages? In the strings.xml, or in my own xml file. The app should work offline, so I do not consider using any internet connection or remote database, or even SQLite (once the messages will come with the app when the user installs it). When the user executes the app for the first time, the idea is to get all these messages (from strings, or other xml) and create a SQLite database. Which suggestion do you have?
What should be the best way to store these messages?
SQLite.
once the messages will come with the app when the user installs it
Use SQLiteAssetHelper to ship a SQLite database with your app containing your quotes.
Bonus points for using FTS3 (or FTS4, depending on your minSdkVersion) for supporting full-text searching. :-)
Since it seems like you don't want to use a database, you can just make use of your strings.xml file and hardcode the quotes. Or like you said you could create your own xml. Whichever consumes less space on the user's device will be more preferable. Choice is yours...
I am trying to do an eclipse java android app using internal storage.
It is a notepad. What it should be able to do is write and save notes, search for them an edit them.
the most similar application of what I need is this:
http://developer.android.com/training/notepad/notepad-ex3.html
but I dont know how to modify if to use internal storage and not external, i also found this file that allows you to read and save in internal storage
http://www.androidaspect.com/2013/09/android-internal-storage-tutorial.html
but now i dont know how change the database for the inernal storage
Okay let's break it down. You want to make something that will let you take notes. Fair enough. You need the kind of storage that will make retrieval and insertion easier.
Let's start with a single text file that you store somewhere (internal or external). If you use this approach, inserting and deleting data becomes difficult because any changes will require you to make changes to the actual text. Not to mention, you will need to format your notes in a way so that you can differentiate one note from another.
Okay, so will using multiple text files solve this? In a way, yes, but you can go for a better approach using SQLite.
SQLiteDatabase has methods to create, delete, execute SQL commands,
and perform other common database management tasks.
SQLite seems like the prime candidate for your storage because it makes CRUD (Create, Read, Update, Delete) easier. Instead of trying to modify the code, start from scratch.
Have a look at this tutorial https://www.youtube.com/watch?v=j-IV87qQ00M
I am working with an application which has offline mode. In order to do that we store the information in a local SQLite Database and using Content Provider which provides a wrapper around the SQLite, and sync it every once in a while with the data from the web service.
We are also keeping the images which are taken by user on the sdcard and send them to the server during the sync service.
The problem is bandwidth and data usage. In Android 4.0+, we have a section in device setting named Data usage. It is showing too much data usage and it annoyed the users.
My first question is : Do you think using ProGaurd which is a tool to shrink the code, can have any impact on reducing the Data Usage?
I would appreciate if you share any experience and suggestion with me in order to reduce the Data usage in such an app.
Addenda:
1 - User login to the system and during first sync sqlite file generated and transferred from REST (initialization).
2 - We have sync-status flag for entries in database. If record(using json string for data) or picture is not synced, it will transfer to the REST during sync and status-flag get updated.
3 - An updated database file receives from REST and merge with the current database on the phone in the sync service (if initialization is already done).
ProGuard has nothing to do with the amount of data you send/receive from a server. ProGuard can shrink and obfuscate code (thus making your APK smaller).
You need to analyze the data you send and receive. There is no silver bullet here that will magically solve any bandwidth issues you may come across in an app. You need to ask yourself several questions and take action depending on your answers:
What kind of numbers are we talking about?
In 2011 the average bandwidth use of an app was around 10MB per hour. There are probably more recent surveys if you search a bit. Are you far above the average number? If not, then I don't think you have to worry too much.
How often do you send and receive data?
If it's a real-time app that absolutely require live data then there's little you can do. If it's not a real-time app maybe you can reduce the frequency of send/receive or wait and collect more data before sending it to reduce overhead? If you're sending many small chunks of data you'll get a lot of overhead in HTTP headers and so on. Hold on to the small chunks a while longer and send them in one go to change the data to overhead ratio.
Can you change the protocol?
Maybe you can send data over a socket instead of HTTP to reduce overhead? By your description it doesn't sound like this would work in your case.
Can you compress data before sending it?
Make sure that your server GZips data before sending it to the client. There is a lot to gain by doing this.
Can you use another data format (binary, json, xml, custom)?
You mention that you use JSON. JSON usually/always perform better than XML, so you're already good there, but maybe you can send data in another format that is even more compact?
I use PHP to access my database and generate an XML file online. My android app then gets that XML file, parses it, and inserts the data into a SQLite database.
This works just fine but is INSANELY slow. We have an iOS app and an Android App both doing the same thing... the android app takes 7-10 seconds every time the user wants refreshed data, while the iOS app only takes 2-3 seconds at most.
There aren't a lot of records - 30-50 on average. There is a lot of content - some large articles, and each with 2-10 photos (I'm not downloading the photos - just importing their url, size...etc)
I followed an example on how to use Sax to import my XML (supposedly the fastest way).
TLDR:
Is there a better way I can format my data to make it MUCH quicker than how I'm doing it now? CSV? Use PHP to generate SQLite Insert statements? What is the "norm" and/or "best" for this?
Edit:
The more I read, the more it sounds like the difference between JSON and XML are miniscule, and can even be faster with XML if it's large data (like articles) instead of JSON. Not sure this is correct, just details from further reading.
You should try using JSON instead of XML i think it might be a lot faster to work with that. It is supported on Android and as far as I know iOS can handle it as well.
I used to create a SQLite db file and gzip it, then unzip it on device and use that directly. (Not a good way for sure)
For later data updates I used json to transfer data. JSON can surely handle large articles, but if you prefer you can just put urls to the articles in JSON and fetch them in subsequent transfers.
Instead of using XML or JSON, look into Google's Protobuf :
https://developers.google.com/protocol-buffers/docs/overview
http://code.google.com/p/protobuf/
since you are on PHP, you will need to find an implementation that works for you, here is a list :
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Going forward, this will be a very nice way to transfer and marshall data around. Please let us know if this works for you.