Change activity variables from another activity/Service

Question

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.

Answer 1

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.

Answer 2

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.