Philosophically, is it better to work with preferences throughout some code, getting and setting the values as the user interacts with the activity; or is it better to work with class fields, then later in some onDestroy() perhaps, set the preferences to the final values of the class fields than one wants to save.
//-- Is this better?
if (a==preferences.getInt(pref1,default){
preferenceEditor.putInt(pref2,someNumber);
}
//-- Or is this?
if (a==field1){
field2 = someNumber;
}
...
onDestroy(){
preferenceEditor.putInt(pref1,field1);
preferenceEditor.putInt(pref2,field2);
}
So, please don't "work with preferences".
What you're doing there (in your first sample) is interaction with a global variable. Never do this if you can help it. It's an anti-pattern. You don't want globals in your code. It makes the code harder to understand / harder to test. Instead, whenever you instantiate a class, read your global settings and add them to your class' fields (preferably in the constructor). The class itself must NOT know about your preferences storage.
Also, DO NOT USE onDestroy (WTF?). Here's a note from the reference:
Note: do not count on this method being called as a place for saving data!
Instead, place that logic in onPause().
for performance reasons fields should be preferred over preferences, but it also depends on how often the values change
Related
Looking through this tutorial: http://www.newthinktank.com/2013/04/android-user-interface/
The app assigns a string constant for each value to be saved. Then when the savedinstancestate is made, the values are assigned to the keys. And when the savedinstancestate is loaded, they are found using the keys. Why is it necessary to use the constants as the keys? What's wrong with just using s a string as the key like this?
protected void onSaveInstanceState(Bundle outState){
super.onSaveInstanceState(outState);
outState.putDouble("TOTAL_BILL", finalBill);
outState.putDouble("CURRENT_TIP", tipAmount);
outState.putDouble("BILL_WITHOUT_TIP", billBeforeTip);
}
You dont have to use constants if you dont want to, its just a convenience method to not make coding mistakes. Actually with time you will find that you are using a lot of bundles, sharedpreferences and other components requiring use of some string keys. In case of savedinstance handling in activities they are used in single class, but sharedpreferences or using bundles with startActivityForResult thats not the case, such string key constant is used by different classes, sometimes in different packages. Its good practice to manage such constants in some ordered manner. For shared preferences I use separate class called Consts, for startActivityForResult bundle arguments I try to keep keys in Activity beeing called (because it can be called by different activities).
also it makes it easier to prefix such constants with some well know word, ie.: KEY_ , in provided tutorial I would use rather names as KEY_TOTAL_BILL, KEY_CURRENT_TIP, ... This makes it easier to find them using code completion, especially when you have lots of other such fields in class.
If you mistype the key, it could be difficult to find where the error lies. It is much safer to use a constant.
Same goes for storing and retrieving data inside an Intent, you wouldn't want to go through every activity that handles that Intent looking for a mistyped key.
Is there any disadvantage in transferring values from Activity A to Activity B with static fields of a third class instead of the ExtraBundle?
In my application, sometimes I have like 15 - 20 values that I need to transfer between two Activitys. In my oppinion, it is more lucid solving this with static fields from a sort of TransferHandler.
At the moment, I have one disadvantage in mind: When a value is not put into the Extras before starting Activity B, I will get an Exception. Solving it with static fields, it it possible that I forget to assign a value, and if that value was assigned before from somewhere else, it might be that a wrong value is used in Activity B. Nonetheless, I think this is a "programmer problem" and not a "program problem". So are there any further minusses or am I free to choice a way? How's with the performance of the two variants?
First of all, if you plan to use static values, you should use your Application class to do this (because Android system assures you that it is a true singleton)
Thus, you can store your datas in attributes of your custom Application class, and use specific methods to store and get these values.
This will ensure you can't "forget" any values.
Also, with 15-20, I will strongly advice you to make a specialized POJO class to store all this...
I think the biggest disadvantage with using static classes for passing information in android is that static fields and objects can be cleared by the system at any time. That means that any static non final value can ALWAYS be null.
So it will probably work fine most of the time, but if you don't make sure to handle these null situations and your users start using your app they'll get a null pointer exception crash once in a while because the system decided it needed that memory stored in those static fields.
The best way for passing data between activities is by my opinion by using Intents, see here for a good example. Alternatively use a database or the the sharedpreferences.
Google also have a good read about pass data between Activities/Services here.
You cannot use a third class to transferring values form one activity to other. Here is the problem with it. You create one object in the activity-a then you store some values into it. Then after for using the values you need to create one more object in the activity-b then the object created in activity b will not be having the values you assigned in activity-a.
You can use SharedPreferences class to store valuo of variables:
SharedPreferences settings = getSharedPreferences("shared_pref", MODE_WORLD_READABLE);
SharedPreferences.Editor editor = settings.edit();
// With editor you put data
editor.putString(firstName, "John");
editor.putString(lastName, "Smith");
editor.commit();
You can access this data in all activities:
// With settings you access to data in different activities
SharedPreferences settings = getSharedPreferences("shared_pref", MODE_WORLD_READABLE);
String firstName = settings.getString(firstName, null);
String lastName = settings.getString(lastName, null);
My app has some UI elements that are based on some settings from the user and I am not sure how I should go about coding this for best performance and there doesn't seem to be a good way to Google this to try to find if this has been asked previously.
Basically I want to check for the App Version UI set in the settings and I currently do it via a function:
public String appVersion() {
appSettings = currentActivity.getSharedPreferences(APP_SETTINGS, 0);
String prefAppVersion = appSettings.getString("appVersion", "v2");
return prefAppVersion;
}
Then I will display certain UI elements via an if/else statement:
if (appVersion().equals("v2")) {
// do something here
}
else {
// do something else
}
Is this going to cause memory problems if I call the function 5-6 times within my app (getting a SharedPreference over & over again) or am I better somehow declaring a global variable that gets the SharedPreference once and then uses that for the tests? My only concern with that being if the Preference changes and the UI needs to be redrawn if the variable is not reset.
Your thoughts / input is greatly appreciated.
I don't think the appVersion function will cause any memory problem, but maybe make appSettings as a local variable would be a better practice.
I don't understand the second question, do you mean how to know the preference being changed? SharedPreferences.OnSharedPreferenceChangeListener may help you.
I have an application which has some static variables.
These variables are stored in an independent Class named DataContext.
These variables are initialized from raw files at the application start (a method named DataContext.initConstant() is called in the onCreate() of MyApplication which extends Application).
(EDIT : the initConstant method use an AsyncTask to load this data from files).
When my application comes to the background for a certain time or when my application used to much memory, these static variables become null.
How can it be prevented?
If not what should I do with my static variables?
I have other data which are stored in static variables to be used across different activities, but I clear them or pass them to null in the onLowMemory() of MyApplication.
What is the best way to keep some data accessible between activities if these data are too big to be serialized in an Intent, a database can't be used (for whatever reason), and can't be stored in files through serialization either?
You can't. Android needs to free up memory from time to time. Imagine if all applications had a ton of static data that is supposed to be resident forever - how would you fit that in memory? It's a mobile phone. It doesn't have virtual memory.
(and 3): Anything that is intended to be persistent needs to be stored, either via SharedPreferences, a Sqlite database, or a file.
Most likely the issue is that your application is being killed while it is in the background, and then recreated when you come back to it. Check out the Activity Lifecycle documentation on when this might occur for a single activity. You need to make sure that you move anything stored in memory to more permanent storage at the correct point in time to avoid losing that information if the app gets killed.
I'm not sure what exactly you are storing, but it sounds like using Shared Preferences might work well. This page on Data Storage explains a number of different ways of more permanently storing data, including Shared Preferences.
If you weren't using raw files, I'd advise initializing when the class is loaded.
For instance,
public static Map<?,?> myStaticMap = new HashMap<?,?>();
static { //fill myStaticMap }
You do have some bigger concerns to worry about if you are loading files that way. For instance, what about I/O errors, or latency issues? You will get warnings in gingerbread (if you enable them) for doing I/O in your main thread. Perhaps you should have an object to retrieve these values instead of a class with static fields. (perhaps with a static cache, although you should synchronize on it before checking/changing it)
I assume this is a data cache problem.
Storing data in static class is not guaranteed to work when user swap apps often. Android system will reclaim any background activity when memory is low. Static class is definitely among this category.
The proper way to do it is to use sharedPreference to persist cache data.
You can create your own getter and setter of the data you want and wrap it around sharedPreference object. When you access using getter, you should always check if the value is empty or expired. You can store an update_time when using setter.
For activity specific data, you can just use getPreference(permission), if you want to share data across activities and other applications components, you can use getSharedPreference(name, permission).
Normally, the permission will be MODE_PRIVATE such that the data can only be accessed within your application.
You should group data and store in difference sharedPreference object. This is good practice because when you want to invalidate that group of data, it is just a matter of one liner.
editor.clear(); editor.commit()
If you want to cache complex object, you should serialize it. I prefer JSON format. So you need some conversion mechanism in place. To do this, I will create my data object class extending JSONable class. JSONable class will have toJSON() method and readFromJSON(). This is convenient when restore and serialize data.
I store a User object and a Client object in my static scope. I have noticed from time to time the reference becomes null. So now in my getters I check to see if this value is null and if so I restart the app.
Intent i = context.getPackageManager().getLaunchIntentForPackage(context.getPackageName());
i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
context.startActivity(i);
I could have also chosen to reload the Client because I store the Access Token in prefs however I do so much initialization that I decided restarting the app would the best idea.
In your onResume() method you could query the static data to see if it is present and if not, load it back in again.
Instead of using the static variable u can use the shared preference for storing the value.
Note: for shared preference also you should not give heavy load.
I have solved this problem by having the super class with getter and setter function for storing and retrieving shared preference variable.
All class in my application extended the super class instead of activity.
Just a random question. I'm learning a bit of Android right now, and in most examples, it seems a lot of common items (such as buttons, editboxes etc) get requested within each function using (cast) findViewById().
Is it considered good or bad practice to store the result of that in an Activity's member values? Simple example:
public class MyActivity extends Activity {
private EditText myText;
public void onCreate(blah blah) {
// blah
this.myText = (EditText) findViewById(R.id.mytext);
}
}
and use the myText field from there on. I think it'd be good for performance (depending on findViewById's inner workings, I'm quite sure it's already very fast), but I haven't seen it be encouraged yet. Also, it wouldn't be the first time I encountered a situation where 'caching' something like this leads to problems (had a case where database connections weren't released properly because I remembered a ConnectionManager or something in that fashion).
Secondly, somewhat related, if you want to remember something across methods in your Activity (and later on too, when the Activity is restarted later), is it wiser to keep up both a class field and a value in SharedPreferences, or would calling SharedPreferences each time for setting / getting the value where it's needing be a better solution? (better being 'cleaner, without impacting performance significantly)
That is completely normal practice and is exactly what you SHOULD be doing. If you're worried about memory leaks, or holding references or whatever, don't be concerned about that when dealing with views.
However, you SHOULD be careful about holding references to other contexts because that COULD cause a memory leak. That doesn't mean you shouldn't do it, just be careful about when you're doing it.
is it wiser to keep up both a class field and a value in SharedPreferences, or would calling SharedPreferences each time for setting / getting the value where it's needing be a better solution?
You should do both. You should keep a member variable for when you only need to read the data, just be sure that when you WRITE to the member variable, you also change the shared preference.
Also, it wouldn't be the first time I encountered a situation where 'caching' something like this leads to problems (had a case where database connections weren't released properly because I remembered a ConnectionManager or something in that fashion).
This is what I was saying first. It all depends on what you're storing. Views are fine to store, contexts can be dangerous, and database connections and registered listeners can cause really weird bugs. It all depends on the specific case.