I have encountered a case where the data is being read/written to/from SharedPreferences instead of using Intent to pass it across the Activities. Ignoring the use case argument for using Intents and SharedPreferences for a moment, I would like to know if Android writes an Intent to disk before sending it to the intended Activity.
Because, if it does, there would not be any performance difference between using an Intent and a SharedPreference and I might go with the existing flow with SharedPreference.
So, does it?
Intent is only in memory and absolutely better than SharedPreference, which is formatted to xml and then read/write to disk.
Where shared preferences are stored in disk? (source)
SharedPreferences are stored in an xml file in the app data folder, i.e.
/data/data/YOUR_PACKAGE_NAME/shared_prefs/YOUR_PREFS_NAME.xml
or the default preferences at:
/data/data/YOUR_PACKAGE_NAME/shared_prefs/YOUR_PACKAGE_NAME_preferences.xml
SharedPreferences added during runtime are not stored in the Eclipse project.
Note: Accessing /data/data/ requires superuser privileges
What about Intents? Wait, what is an Intent?
The intent is an "intention" to perform an action; in other words,
a messaging object you can use to request an action from another app component.
It can be thought of as the glue between activities. It is basically a passive data structure holding an abstract description of an action to be performed.
(additional info) In intents, the data to operate on, such as a personal record in the contacts database, expressed as a Uri.
If the above statement does not make an abstract visualization in your mind, simple answer would be
"Intent is just passing of data from one "Class"/"Object" to another and everything resides inside "The Memory" perhaps cache too.
Related
Hi to anyone who can answer,
So I came across this question (it was an assignment, I already submitted it anyways). It was regarding shared preferences and explicit intents. I know both can pass data (through putString, putExtra, putInt etc and getExtra, getString, getInt). However which method is better to pass data and why? It can be in terms of functionality or just how much lesser the codes are when comparing each method to each other.
If you want to pass data when transitioning from one activity to another activity, then it's normally better to use intents to pass data.
However if you want the data you are passing to still be retrievable after the user exit your app and reopen it, then you should use SharedPreferences.
Intent is better to use when you are passing data when you are going from one activity to another. Otherwise, you should use SharedPreferences instead. And as mentioned above, if you want the data to be stored and retrievable even when the user reopens the app, then you should always go with a storage option like SharedPreferences.
those are two completely different functionalities that should not be mixed.
Intent extras are used to pass data from one activity to another. If the intention is having one activity put data and the next one receive you should use Intent extras
SharedPreferences is a very lightweight data storage. It's meant to store data on permanent memory and can be retrieved by any entity within your app. If you need data to be saved and access any moment in the future from anywhere in your app, you should use this.
I'm using IntentServices to call a restful service and then turn over the result to a receiver. The back-end requires a user id and authentication token, which I stored in a singleton class. I've run into issues with this singleton being cleaned up when the process is terminated, and its data isn't around when Android tries to restart my activities. User preferences seem like a great place to start this kind of data, but those require a reference to your context.
Where can I put this data so it can be accessed outside of the view? I realize I could just pass it with every single Intent that triggers my IntentService, but am hoping there's a better way.
Thanks!
Service is a ContextWrapper which is a Context so you can use the keyword this when getting an instance of your shared prefs.
For lightweight data such as a few strings etc, SharedPreferences is fine. Just pass any context, every component has one or is one itself. Or pass the application context. Lack of context shouldn't be an issue. Pass it along into your singleton as a parameter.
Using a database, or inventing a proprietary storage mechanism using a file, or creating a content provider, all seem overkill to me.
If you don't want to pass it all the time (which is not that bad), and you still want to stay in the Android framework philosophy, create a ContentProvider for this task.
Or you can go full classical and save them in some file. Or in a sqlite database (Android offers easy support for this).
In my Android Application I have to pass data (Variables regarding the state of the application) from an Activiy to another one. And I have to do this many times in others Activities. What's the best and more efficient way to do this? Should I read that information from the share preferences every time I need it or should I send it as an extra in the intents?
It really just depends on how long you need the data. If you only need it for the lifetime of the application then just pass the data with Intents. This will be the easiest. You can put the data into a Bundle to make passing them around even easier.
If you need it the next time you log in or you need it to be saved if your app is killed for some reason then use SharedPreferences
You also can store it in SharedPreferences and open them up say, in the MainActivity, and pass certain data around. It really just depends on what you need. I hope this helps but if you need a better explanation then please be a little more clear on what you want
In case you aren't familiar with SharedPreferences, the docs have a good example to get you started
SharedPreferences
I think that it depends on why you need this data... If it is some general settings of the application, I think that user preference is better as it persists, but if it is just some data required by the others activities, you should use intent extras.
Given that a Service may be running even when the launching activity is destroyed,
and also that data is passed usually using the extra bundle along the intent,
I wonder if the Service is able to directly access the activity's preferences.
My guess is no, it cannot. But it would save me writing a chunk of code if it can do it.
Assuming that You're asking about SharedPreferences. If so, then documentation is clear (by link above):
Note: currently this class does not support use across multiple
processes. This will be added later.
So, currently, if Your service is running in a separate process it's not possible. In that case I would suggest to store Your preferences not in a SharedPreferences, but in some base which could be accessible via specific ContentProvider.
P.S. Actually I tried access SharedPreferences from multiple processes and it has worked (at least in my case), but I've decided to use another way because of the documentation mentioned in the answer.
If you mean SharedPreferences then you can just call getSharedPreferences with the same name.
Ddms tells that, when I recall my class called in the past, it performs an onCreate() instead of onResume() that I expected...
I noticed that values that I stored in variables of my class in this case are lost and are null.
I presume that Android decide to do so to free memory resources (isn't it?).
I know that I could use Sharedpreferences to store data in a persistent way and then retrieve... But this is a really dirty way, in my opinion.
So, my question: how to have variables' values preserved also after an onDestroy() (I think?) that Android decided automatically?
Android will terminate your process at any time when you have no visible activities. For example, the user might go into Settings and terminate your app.
Static data members (my interpretation of your "variables of my class" description) are only meant to be caches, at best. They are no substitute for a persistent data model, whether you use a database, an XML file, a JSON file, or whatever.
So, if you want "variables' values preserved", save them someplace persistent.
You might find this page on data storage helpful. If your data is primitive, SharedPreferences are the recommended route. (Why do you think they are dirty?) If you need to store an object, you can use internal storage, as documented on that page.
http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)
If you don't like SharedPreferences, then you might want to look into Content Providers Even though Content Providers share data across applications, they also provide functionality for you to store persistent data in SQLlite and files that are available only to your app. In this case data stored in this fashion will be available even after closing and restarting your app.
You can save dynamic state by passing name:value pairs or serializable objects using the Android Architecture and the methods onSaveInstanceState and onRetainNonConfigurationState. You can persist state as explained in the other answers by writing to prefs and doing database writes.
I've been using custom Application class to store data over application life line.
How to declare global variables in Android?