9

I have a BroadcastReceiver class. I have some static variables declared whose value is updated in side the onReceive() method. As per my knowledge static variable will keep it's value across the onReceive calls. Is there any possibility when I will loose those values(Like my class will be unloaded resetting the static variables)? These are basically some temporary variables I need to be available for multiple onReceive calls.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Sush
  • 6,839
  • 1
  • 18
  • 26

2 Answers2

6

From the documentation for BroadcastReceiver Lifecycle...

A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent). Once your code returns from this function, the system considers the object to be finished and no longer active.

This isn't going to make the use of static variables practical in the sense that things will be cleaned up quickly by the system. I'd try using SharedPreferences by calling...

context.getSharedPreferences("MyReceiver", MODE_PRIVATE)

...in the receiver's onReceive(...) method (replace "MyReceiver" with some name which makes sense to your app).

Squonk
  • 48,735
  • 19
  • 103
  • 135
  • 1
    But static variables are class level variable and should not be cleaned when the object destroys. Please correct me if I am wrong. I am aware of getSharedPreferences(), but just wanted to use static variables as after some times I need to clear those variable once my work is done with them and I don't want them to still present in SharedPreferences.Finally if it can be achieved through variables then I don't want to use SharedPreferences. If it can not be then definitely i will go for SharedPreferences. – Sush Jun 10 '11 at 05:27
  • @Sush: "But static variables are class level variable and should not be cleaned when the object destroys." - So 'where' do class variables 'exist' when the last instance of that class is destroyed? They don't just float around in cyberspace waiting for another instance of that class to appear. As explained in the quote from the docs, when `onReceive(...)` exits "the system considers the object to be finished". Basically you can't guarantee if/when the `BroadcastRecever` object will be GC'd. As for `SharedPreferences`, you can simply 'clear' them when no longer needed. – Squonk Jun 10 '11 at 15:31
  • 3
    @MisterSquonk: I agree SharedPreferences can do the job. But I strongly disagree that the static variables will be destroyed once the last instance of the class got destroyed. Static variables are initialized when the class is loaded in to memory,i.e. when the application starts and stay in the memory till the class is in memory. It does not depend on the Objects to live. – Sush Jun 10 '11 at 18:23
  • 3
    @Sush: OK, agreed WRT static variables not being destroyed once the last instance of the class is destroyed, I worded it badly. I'll reword things - once the BroadcastReceiver has exited onReceive() and is possibly GC'd, if it was the last active component of the app as a whole, there is an increased danger the Application itself may be the target for the Android OS to terminate if device resources are low. If that happens then you will lose current values as next time the receiver is 'fired' the app will be recreated/re-initialised. SharedPreferences persist however. – Squonk Jun 10 '11 at 21:00
  • @MisterSquonk: Thanks for being patient to make me understand. I understood the idea. Thanks again.. – Sush Jun 11 '11 at 21:51
  • @Squonk As I know, this quote is true only for statically declared in Manifest BroadcastReceiver. Context registered receivers won't be called after owning activity will be destroyed. – B-GangsteR Apr 16 '17 at 08:09
1

Or you could of course declare the static vars within your activity class.

Will Kru
  • 5,164
  • 3
  • 28
  • 41
  • Yes I can do. But is there a problem declaring the static variables inside the **BroadcastReceiver**? – Sush Jun 10 '11 at 05:39
  • 1
    It doesn't matter for a static variable to be declared in an Activity, BroadcastReceiver, or class. A static variable behaves the same. – jclova Dec 04 '14 at 16:08