Following solutions are mostly suggested to do this:
using Intent like here
using Handler like here
using SharedPreferences like here
Question
What is the problem of defining a public method to set the variable like:
public class Activity1 {
private int var1;
public void setVar1(int val){
var1=val;
}
}
and in Activity2:
public class Activity2 {
Activity1.setVar1(4);
}
It seems that it is applicable for both static and non-static variables
EDIT1:
It is a simple case of my current project. In original case, the Activity2 connects to a bluetooth Hub and receives data of several sensors. If the values are changed, it should pass the changed values (and off course sensor ID's) to Activity1 which is responsible for updating UI. The number of sensors can be more than 100 and update period is in range of 100 msec, which means a runnable reads the incomming BT messages each 100 msec and checks changes.
EDIT2:
BroadcastReceiver is also solution. But the question is: Whats wrong with defining a set method to change/update a variable. Is this method inefficient in terms of memory? Does it makes the app slow? Is it an inappropriate code?
I just wanna know what kind of problems/inefficiencies I would face if I define set methods to change activity variables.
keep in mind that an Activity instance is itself a Context, and that these can be very heavy in terms of the amount of memory they occupy because they keep a reference to the Activity's view hierarchy and all its associated resources. retaining long-lived references to Activity instances is a common source of memory leaks.
keeping that in mind, in this particular setup:
public class Activity1 {
private int var1;
public void setVar1(int val){
var1=val;
}
}
...invoking activity1.setVar1(...) would imply that the running instance of Activity2 has a reference to an instance of Activity1, meaning the system hasn't been allowed to garbage collect it. this pattern could eventually lead to the application exhausting its heap and crashing.
you also inquired about the possibility of exposing these methods as static methods. while you'd avoid the aforementioned problem, one potential pitfall here is if a user switches to another application, and the system is running low on memory, your application process could be killed by the system. as static variables are tied to the running process instance, when the user returns to your application and the system restores its state, var1 would be reset to it's default value (zero). (you could probably mitigate this by hooking into the lifecycle methods to save values into a Bundle instance, etc).
those are some reasons i can think of to avoid writing getters/setters into your Activity's interface.
Having reference to another activity is not a good way to do it since each activity has it own life cycle. The activity that you are referring to probably get get destroyed or the system might already start a new instance of that activity whilst you still reference to the old one.
Alternatively, you can use event bus (Otto for example) to publish object/event to another activity.
I have created an Android application that uses a singleton to hold its state. The class is instantiated when the application starts.
The application does make extensive use of fragments but is not a single Activity application.
The problem occurs when an activity crashes for some (any) reason.
Normally, Android closes the activity bringing to the foreground the previous one that was active. Since the previous activity also used the singleton somehow, it needs data from it to resume (for example). The thing is that the singleton is no longer available while the previous activity is running in a new Application Context forcing the Singleton to re-instantiate itself with no data of course.
One way to surpass this problem seems to be storing the state (serialized or not) in a file or the database but that means too many read writes on pretty much every other user activity which should be avoided. Apart from UX, this solution might lead to inconsistent or erroneous data from faulty or untimely synchronisations.
I would like to hear your input on the matter.
Cheers!
Here is the Singleton instantiation method.
final public class Data {
private static Data INSTANCE = new Data();
private Data() {}
public static Data getInstance() {
return INSTANCE;
}
}
If you declare your singleton as static on a root activity it should be saved. We used static varaibles linked to a baseline activty from which every activity dereives.
Antoher solution might be to use sharedpreferences.
It is nice to worry about performance but if you have many fragments and few activities, it would be the fragment that will cause the lion share of teh workload
1) You can use an Application class. It's gonna be destroyed at the very last stage.
2) If your data is not structured - you can keep it in SharedPreferences (as a String mapped with JSON for example)
3) If your data is structured - you should store it in DB (or better ContentProvider)
I started to learn the android framework and my biggest problem is the hell around the activity life cycle. So when the user rotate the screen my application just crash. As I understand beside the normal activity life cycle Android hacked a force-instance-deleter-and-partially-recovery service for me which is not a bug but a feature.
So I just want my member variable keeps safe, so a I thought a start storing it in the Application class.
So I want to refactor my program in the following way:
I create an own Application
public class MainApp extends Application {
LoginActivityData loginActivityData; // create data "segment" for every activity
FirstActivityData firstActivityData;
...
public static MainApp getInstance(final Context context) {
if (context == null) return null;
final Context app = context.getApplicationContext();
return app instanceof MainApp ? (MainApp) app : null;
}
}
In activities and fragments I stop using member variables except the one from the MainApp class.
public class LoginActivity extends Activity {
LoginActivityData loginActivityData;
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
loginActivityData = MainApp.getInstance(this).loginActivityData;
}
Is there any drawback of this design?
Yes, there is a drawback. Your application object can and will be destroyed by the system when it needs to recover memory, and the application object does not have callback methods that can be used to save state. See here for a fuller explanation.
There are many ways to persist data/state, but if you use the following approach you generally won't go far wrong:
Use onPause() to save long-term data to a SQLite DB/SharedPreferences/cloud etc. Restore it wherever appropriate (onCreate(), onResume(), ...).
Use onSaveInstanceState() to save temporary data to a Bundle. Restore it in onCreate()/onRestoreInstanceState(). The bundle is automatically passed around to the appropriate methods by the system. Note that there is no guarantee that onSaveInstanceState() will be called, so don't use it for critical data.
An extended Application class can declare global variables. Are there other reasons?
Introduction:
If we consider an apk file in our mobile, it is comprised of
multiple useful blocks such as, Activitys, Services and
others.
These components do not communicate with each other regularly and
not forget they have their own life cycle. which indicate that
they may be active at one time and inactive the other moment.
Requirements:
Sometimes we may require a scenario where we need to access a
variable and its states across the entire Application regardless of
the Activity the user is using,
An example is that a user might need to access a variable that holds his
personnel information (e.g. name) that has to be accessed across the
Application,
We can use SQLite but creating a Cursor and closing it again and
again is not good on performance,
We could use Intents to pass the data but it's clumsy and activity
itself may not exist at a certain scenario depending on the memory-availability.
Uses of Application Class:
Access to variables across the Application,
You can use the Application to start certain things like analytics
etc. since the application class is started before Activitys or
Servicess are being run,
There is an overridden method called onConfigurationChanged() that is
triggered when the application configuration is changed (horizontal
to vertical & vice-versa),
There is also an event called onLowMemory() that is triggered when
the Android device is low on memory.
Application class is the object that has the full lifecycle of your application. It is your highest layer as an application. example possible usages:
You can add what you need when the application is started by overriding onCreate in the Application class.
store global variables that jump from Activity to Activity. Like Asynctask.
etc
Sometimes you want to store data, like global variables which need to be accessed from multiple Activities - sometimes everywhere within the application. In this case, the Application object will help you.
For example, if you want to get the basic authentication data for each http request, you can implement the methods for authentication data in the application object.
After this,you can get the username and password in any of the activities like this:
MyApplication mApplication = (MyApplication)getApplicationContext();
String username = mApplication.getUsername();
String password = mApplication.getPassword();
And finally, do remember to use the Application object as a singleton object:
public class MyApplication extends Application {
private static MyApplication singleton;
public MyApplication getInstance(){
return singleton;
}
#Override
public void onCreate() {
super.onCreate();
singleton = this;
}
}
For more information, please Click Application Class
Offhand, I can't think of a real scenario in which extending Application is either preferable to another approach or necessary to accomplish something. If you have an expensive, frequently used object you can initialize it in an IntentService when you detect that the object isn't currently present. Application itself runs on the UI thread, while IntentService runs on its own thread.
I prefer to pass data from Activity to Activity with explicit Intents, or use SharedPreferences. There are also ways to pass data from a Fragment to its parent Activity using interfaces.
The Application class is a singleton that you can access from any activity or anywhere else you have a Context object.
You also get a little bit of lifecycle.
You could use the Application's onCreate method to instantiate expensive, but frequently used objects like an analytics helper. Then you can access and use those objects everywhere.
Best use of application class.
Example: Suppose you need to restart your alarm manager on boot completed.
public class BaseJuiceApplication extends Application implements BootListener {
public static BaseJuiceApplication instance = null;
public static Context getInstance() {
if (null == instance) {
instance = new BaseJuiceApplication();
}
return instance;
}
#Override
public void onCreate() {
super.onCreate();
}
#Override
public void onBootCompleted(Context context, Intent intent) {
new PushService().scheduleService(getInstance());
//startToNotify(context);
}
Not an answer but an observation: keep in mind that the data in the extended application object should not be tied to an instance of an activity, as it is possible that you have two instances of the same activity running at the same time (one in the foreground and one not being visible).
For example, you start your activity normally through the launcher, then "minimize" it. You then start another app (ie Tasker) which starts another instance of your activitiy, for example in order to create a shortcut, because your app supports android.intent.action.CREATE_SHORTCUT. If the shortcut is then created and this shortcut-creating invocation of the activity modified the data the application object, then the activity running in the background will start to use this modified application object once it is brought back to the foreground.
I see that this question is missing an answer. I extend Application because I use Bill Pugh Singleton implementation (see reference) and some of my singletons need context. The Application class looks like this:
public class MyApplication extends Application {
private static final String TAG = MyApplication.class.getSimpleName();
private static MyApplication sInstance;
#Contract(pure = true)
#Nullable
public static Context getAppContext() {
return sInstance;
}
#Override
public void onCreate() {
super.onCreate();
Log.d(TAG, "onCreate() called");
sInstance = this;
}
}
And the singletons look like this:
public class DataManager {
private static final String TAG = DataManager.class.getSimpleName();
#Contract(pure = true)
public static DataManager getInstance() {
return InstanceHolder.INSTANCE;
}
private DataManager() {
doStuffRequiringContext(MyApplication.getAppContext());
}
private static final class InstanceHolder {
#SuppressLint("StaticFieldLeak")
private static final DataManager INSTANCE = new DataManager();
}
}
This way I don't need to have a context every time I'm using a singleton and get lazy synchronized initialization with minimal amount of code.
Tip: updating Android Studio singleton template saves a lot of time.
I think you can use the Application class for many things, but they are all tied to your need to do some stuff BEFORE any of your Activities or Services are started.
For instance, in my application I use custom fonts. Instead of calling
Typeface.createFromAsset()
from every Activity to get references for my fonts from the Assets folder (this is bad because it will result in memory leak as you are keeping a reference to assets every time you call that method), I do this from the onCreate() method in my Application class:
private App appInstance;
Typeface quickSandRegular;
...
public void onCreate() {
super.onCreate();
appInstance = this;
quicksandRegular = Typeface.createFromAsset(getApplicationContext().getAssets(),
"fonts/Quicksand-Regular.otf");
...
}
Now, I also have a method defined like this:
public static App getAppInstance() {
return appInstance;
}
and this:
public Typeface getQuickSandRegular() {
return quicksandRegular;
}
So, from anywhere in my application, all I have to do is:
App.getAppInstance().getQuickSandRegular()
Another use for the Application class for me is to check if the device is connected to the Internet BEFORE activities and services that require a connection actually start and take necessary action.
Source: https://github.com/codepath/android_guides/wiki/Understanding-the-Android-Application-Class
In many apps, there's no need to work with an application class directly. However, there are a few acceptable uses of a custom application class:
Specialized tasks that need to run before the creation of your first activity
Global initialization that needs to be shared across all components (crash reporting, persistence)
Static methods for easy access to static immutable data such as a shared network client object
You should never store mutable instance data inside the Application object because if you assume that your data will stay there, your application will inevitably crash at some point with a NullPointerException. The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.
To add onto the other answers that state that you might wish store variables in the application scope, for any long-running threads or other objects that need binding to your application where you are NOT using an activity (application is not an activity).. such as not being able to request a binded service.. then binding to the application instance is preferred. The only obvious warning with this approach is that the objects live for as long as the application is alive, so more implicit control over memory is required else you'll encounter memory-related problems like leaks.
Something else you may find useful is that in the order of operations, the application starts first before any activities. In this timeframe, you can prepare any necessary housekeeping that would occur before your first activity if you so desired.
2018-10-19 11:31:55.246 8643-8643/: application created
2018-10-19 11:31:55.630 8643-8643/: activity created
You can access variables to any class without creating objects, if its extended by Application. They can be called globally and their state is maintained till application is not killed.
The use of extending application just make your application sure for any kind of operation that you want throughout your application running period. Now it may be any kind of variables and suppose if you want to fetch some data from server then you can put your asynctask in application so it will fetch each time and continuously, so that you will get a updated data automatically.. Use this link for more knowledge....
http://www.intridea.com/blog/2011/5/24/how-to-use-application-object-of-android
well most of us familiar with this pattern:
public class MySingeltone {
public String mSomeReferenceTypeData;
public int mSomeValueTypeData;
private static MySingeltone mInstance;
private MySingeltone() {
}
public static MySingeltone getInstance() {
if (mInstance == null) {
mInstance = new MySingeltone();
}
return mInstance;
}
}
my problem is that I've found recently that the mInstance don't equal null after activity using him been destroyed, or when the whole application suppose to be clause, for example:
public class SomeActivity extends Activity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
MySingeltone mySingeltone = MySingeltone.getInstance();
mySingeltone.mSomeReferenceTypeData = "some value";
}
}
when launching "SomeActivity" next time after closing the whole applications running activities (say 10 seconds after..) the mInstance still holds the same reference, with the same values on his fields.
why does it happening?
what am I missing?
when android garbage collecting static members belongs to application?
Since "mInstance" is a static variable it will not get null when you close your application. Closing of application doesn't means that your application got destroyed.
Also there is no concept of Closing your Android app. If you get out of your app it will not get destroyed at the same time. Android OS handles it internally when to close the app when it is no more in use. In case of memory shortage when android decides to destroy the app then this static variable will also got null.
You can not control when exactly Java objects become garbage collected. An object becomes eligible for garbage collection when there are no more (non-circular) references to it.
With Android, further, you can not control when your Activity gets removed from memory.
why does it happening?
what am I missing?
when android garbage collecting static members belongs to application?
Ok first, as others said, there is no close application concept on Android as the android OS manages lifecycle of your application process on their own.
Second, you did the wrong test - if instead of closing all apps you would do the opposite - that is - fill up memory by starting more and more apps, then eventually your application's memory would be cleaned up to be used by other applications and this includes all static mebers as well as instance members! then, you will see that the static variable WILL BE NULL as you expected.
They just "lazily" clean up memory, if there's enough memory then you application might never get cleaned up.
Actually, there is no way around it, as far as i know, there is no way to grauntee an object would not be cleaned up at any point from the device memory. in somecases it leads to bad behaviour. such as if the singleton does heavy processing on its creation, calling getInstance might get your UI stuck, or even make your app crash due to irresponsibleness.