I am new to android development (and also a java newbie) and I noticed that when I switch between views I noticed that any variables declared as static in the view class retains its value but the rest are gone. So I have the following questions if some one is kind enough to answer --
When to use static for variables if any?
If I want to retain the state of say my game between these switches (say to see the score or something), what is the way to do it? Is it by using static variables in the class to store everything? If so how do I reset the variables for a new game?
When to use static for variables if any?
Static variables should be use when multiple activities needs access on it. In other words, if you think your variable has global usage, then setting it as public static may help.
If I want to retain the state of say my game between these switches (say to see the score or something), what is the way to do it? Is it by using static variables in the class to store everything? If so how do I reset the variables for a new game?
You need to override onSaveInstanceState and onRestoreInstanceState to save and restore the values of your variables. A tutorial on how to use it can be found here: http://android-er.blogspot.com/2011/09/onsaveinstancestate-and.html .
Related
I have a NFC tag and I have to read from it a text, and save this text some where to use the parameters in it in many activities and fragments.
this parameters I should be able to delete or overwrite it when a user decide to exit the program or to read another tag.
I didn't like the idea to transfer this parameters over the activities since they are constant in the whole session for example the ID number of the tag and the manufacturer of it.
I thought also to creat a file in Assets and read it every time, but I thought there should be better way to solve this problem.
There are several ways to how you make the values accessible throughout the project.
Using Shared Preferences:
You can use shared preferences, where you can create variables for your fixed values such as TAG_ID and MANUFACTURER_ID. Every time you tap a new card you can update them, or anytime you expect them to be changed.
Using a Model Class:
You can also create a Model Class (May be Singleton as well) which holds the TAG_ID and MANUFACTURER_ID. Initialize the object of this model class every time there is new Tag tapped. You can also access/change them anytime using getters and setters.
Using Static variables:
You can define static variables to store your desired values and you can simply access them wherever and whenever you want to. This will workout only with less numbers of variables. Increased static variables could affect the performance.
I have two activities Activity_1 and Activity_2 respectively. Now I want to send data between these activities. I have two options :
1 - Using Intent.putExtra()
2 - Using static variable
So please, tell me what is the best approach to send data between these activities.
You can do as you wish. You could even store the data into a database, and have your second Activity read it, if you want.
But Android offers a intra-activity communication model which is standard for all applications. Why not use it?
So, Please tell me what is the better approach to send data between these activities.
You already know the answer for that.
You won't find a framework that advises to pass data between components via static variables.
As a personal note, I do not get why public static non-final fields are allowed in java.
EDIT
in my answer above I'm talking about dynamic data. If you are concerned with constants, then I don't see why you shouldn't use public static final fields.
I have a pretty extensive adventure game running on Android using flixel-gdx, and I would like to save the current game state when android switches to another application.
I know you can override the onFocus() and onFocusLost() methods on the FlxGame object, but I can't see a way of accessing the current game state from those methods. The only way I can see is to create a static object that holds a reference to the game state values, and refactor my entire game to reference the static object when it needs to manipulate those values.
Can anyone think of an alternative?
FlxG.getState();
returns you the current state that is running.
I need to pass a List of my objects between activities. I do not want to use parcelable or serialize the data each time. I also do not want to save it in a local file or database. That probably leaves me with using static objects.
Lets say I to use ListA between activities Activity1 to Activity2. I ca
Approach1: Create a static ListA in one of those activities and do all my stuff of that static ListA.
Approach2: Create a static list in another class which I use just for storing this List and doing all my stuff on this list. But this means that this stays as long as my process is running and I have to manually set it to null when I do not need it.
Approach3. I am extending the above class to implement it using a static HashMap.
I have two methods one to store the list in a static HashMap using a unique key and another method to retrieve the list and remove it each time data is retrieved so that the List is no longer present in the static HashMap. So we essentially have to pass only the random key generated to store data between activities which I can pass as an extra using Intents.
Will there be any issues when I use any of the above approaches and which will be the best approach.
I'd consider creating an Application object and using it like a singleton to access your data. I've described the approach here: http://chrisrisner.com/31-Days-of-Android--Day-7%E2%80%93Sharing-Data-Between-Activities. Some people don't seem to like using the Application object in this manner but it makes more sense to me than putting a static object on an Activity.
Uggg statics! Man I wish all developers understood global variables are bad and how they make your program more brittle and your life hell. We only been talking about how bad they are for 30+ years, but unfortunately no one figures this out until they've utterly hung themselves on them.
First I'll say serializing your data is fast. There are great tools out there that will serialize your objects quickly that you can use I prefer http://flexjson.sourceforge.net for this.
So if you are just outright opposed to this you can pass this object through the Application by subclassing it, declaring your implementation in your Android Manifest, and each activity has access to the Application instance:
public class MyActivity extends Activity {
public void onCreate( Bundle bundle ) {
MyApplication application = (MyApplication)getApplication();
Object anInstanceFromAnotherActivity = application.getSomeInput();
}
}
The downside to this is when your application is reclaimed if the user returns to your application the memory is gone, and you can't get that input you might need of your screen. Android framework is trying to make you serializing things in the bundles because if it decides to destroy your application you can always rebuild yourself from the bundle. Now there are short cuts you can take like redirecting people to start over if the Application has been reclaimed, but those depend upon your program and what its doing if they make sense.
That's where using serialization wins out over all other forms of persistence (parcelables, files, databases) because it can be done in one line of code.
When adding an object to a Bundle in order to save it in onSaveInstance does it save the state of all the static variables or will then be reset when I reload using onRestoreInstance?
As an extension of the question, is it possible to save a non-instantiated class. In other words just the statics?
I am using it for a card game and since I will only ever have one deck of cards it seems silly to have to instantiate it when I can use all statics.
From an OO perspective, it would make more sense to model your deck of cards on the Singleton pattern rather than making it static. Then you can save that object in the Bundle and restore it without having to worry about the static issue. If you care about such things, this method also makes for 'better' object oriented programming.