Is it cheaper to send data across Activity using Parcelable or using SQLite? I am using SQLite (through Content Provider) to persist my data. So really I always have access to my data through SQLite. But I am not sure whether I should send data across Activity using Parcelable or should I just grab them each time.
The details. say I have a Village object. So naturally Village is relatively big: it contains Lists of People for instance, which in turn may contain List of Clothes. In onPause of each activity I persist Village to my Content Provider. But sometimes I want to send a Village object from one Activity to another. I have two choices: I can send the dbId to the next activity and then query the URI (and then convert the cursor to a POJO), or I can send a Parcelable of Village. Which is more expensive?
Say Parcelable is cheaper (I don’t know yet). Right now I am struggling to get the Parcelable to work. Is it worth the effort to get Parcelable to work?
If your object can be large, then accessing via the ContentProvider is the way to go. Not only will you avoid the marshalling/unmarshalling time & code, but Parcelables are limited to 1MB.
The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process.
Related
I have a MainActivity that fetches a large-ish amount of data from a web server using Retrofit. This data is shown in a recycler view.
Now, I want to have another activity which works on the exact same data set. What's the most efficient way to do this? Earlier I have done this using a static Controller that keeps track of the data, but I keep hearing a lot of critique about static containers like that. Passing the data in the intents is not optimal, since the data is rather complicated and there's so much of it.
Optimally, I'd like to be able to modify the data set in either of the activities so that the changes are reflected to the other activity as well.
I think you should consider 2 options (depending on the amount of data you would like to share, and the type of devices your app is suppose to run on)
You can extended the application class to include global data between your activities. You can read more about it here: http://www.helloandroid.com/tutorials/maintaining-global-application-state
You can use persistence storage (i.e. sqlite/file).
There are trade-offs for each approach. And which one will suit you best depends on your specific setup.
Of late I have been into an issue which has been really difficult to sort out.
I have an Activity A which has a view pager with fragments. I am loading data from server and feeding into the views. The data received from server is stored in a singleton class which can be accessed across the application. Now user moves to another activiy B which uses the server data through singleton class.
Now when user presses home and launches variety of application, my app gets killed in background. When I relaunch the application, OS try to load activity B again with its saved state(I am not doing anything in onSaveInstance), but the data in singleton class is already lost and app crashes. The thing is I cannot get the server data again in this activity. Should I save the entire data in onSaveInstance of this activity? Is it not encouraged to use singleton class to store all your data?
What is the ideal way to handle situation like this?Any help is appreciated.
How sensitive is the data? In Android is is not recommended to use a skeleton to move your data around(Passing it through intent? Static(please say no)). Ether way was commented you should probably store the data to main memory. Android provides a few options besides actually writing it to a file. Depending on how much data and its structure there are a few options.
ContentProvider & ContentResolver, Basic Overview. I would not recommend this unless you plan on making the data accessible to other applications.
SQLite. Good if you have preexisting sql knowledge or large amounts of data where a relation db is needed.
SharedPreferences. As its name implies is generally used for storing user presence data, but it can also be used to store any data. I would not recommended it where there is a lot or complex data is needed to be stored.
File. Good old java file classes, no explanation needed.
With our data I would recommend creating a DataStore managing class which handles the io to any of the above methods, so when referencing the data you simply pull from that class.
To avoid such situations, you should relate to these:
App crashes when restoring from background after a long time
http://www.developerphil.com/dont-store-data-in-the-application-object/
I have a database from where i need to extract quite a lot of data.
Now i get that data when required, i.e. I have made a class that handles database interactions and whenever an activity requires data it will call that class for the data. So at a time an Activity only has the bare minimum amount of data in memory (i.e. the data that it is using). But everytime i change an activity i have to perform database access to fetch data for the new activity.
Method 2
As opposed to this i have this other alternative, in which i make an application object and then perform database access in the beginning and then store all the data that i would require (in all the activities) in the application object. Whenever i need the data, i refer to the application object. The downside of this that i will be holding too much extra data that i am not using at a given instant.
Which of the above 2 approaches is better?
Thank you in advance.
It depends on your requirements and their priorities. If the time required for solution 2 is too long for you to accept then optimize (e.g. by using method 2, but in general I would advise against storing potentially all of your database in memory ... assuming the amount of memory will suffice).
Did you try solution 1. If the problem is only to read the data from database, it should not take too long to load the data for one activity. If complex calculations are involved you might be pressed to optimize. But don't optimize just in case!
I prefer the first approach because making a call to database is not costly until and unless it is being accessed by multiple applications.
I have a small app that records messages and stores them in an object which implements Parcelable. In the app I have a LOT of messages (about 2000) and it takes a considerable amount of time passing between Activities through intent.putParcelableArrayListExtra
Is this not the correct usage of Intents+Parcelable? I've been really wanting to avoid SQLite, but I suppose I'll get my hands dirty if its absolutely necessary.
You should definitely persist your messages in a database. If you want to avoid all the SQLite hassle check db4o, painless object persistence in your apps using an OODB.
I would like to pass a considerable sized amount of data (~1500 bytes) between two applications in Android where performance and resource allocation is a priority. The data is basically key-value pairs. The rate at which it needs to be passed from one application to another can vary from a trickle to ~50 packets within a second. I figure I can either:
Wrap all the data inside a bundle, and pass the bundle via an Intent from one application to another. I worry about the performance implications of allocating and de-allocating all that memory to store the bundles.
Write all the data to a SQLite database and provide it to the other application via a content provider. Here I worry about the performance implications of writing all that data to disk, and then having to read it back from disk when it is requested.
So, which is the lesser of two evils?
Consider using a service connection. You pay some overhead in setting up the initial connection, but after that, you can use an RPC-like interface to make method calls (passing Parcelable structures in either direction) with very little overhead (well under a millisecond). See this page for details.