2

I asked this question Is onDestroy called only if you explicitly call finish() ?? or are there any exceptions? now in answer I got that

where are the cases where ondestroy() not get called up.

  1. If you crash with an unhandled exception

  2. If your process is terminated in an urgent fashion (e.g., the system needs RAM to process an incoming phone call)

  3. If the user clicks "Force Stop" on your app's screen in Settings

  4. On a few devices, if the user terminates your process using a manufacturer-supplied task manager

Now as for these cases as onDestroy() will not get called so I thought to try onStop()

But as for all above cases even if i will write code in onStop() to unregister the receiver then still it will not get called because of which my receiver will left registered.

So now my question is where can i write my code to unregister the receiver when any of the above four cases will happen.

Also if it is not possible then i guess as for both onStop() and onDestroy() for these four cases we cannot rely on them to unregister our receiver then why in Android docs it is written to not use onDestroy() even both are equally unreliable ??

Shouldn't they say that both functions should not be used for releasing resources(unregistering receivers).

Solution - According to commonsware answer

In all three of these cases, your process is gone, and therefore your BroadcastReceiver is also gone. There is nothing to unregister.

So as the broadcastreceiver is also gone, so there won't be any need to unregister the receiver, So i think there won't be any problem in all these three cases if i will use onDestroy() to unregister the receivers.

Only for the 1 Case i will try to implement my own top-level uncaught exception handler, as onDestroy() won't be called for that.

Sudhanshu Gaur
  • 7,486
  • 9
  • 47
  • 94
  • `onPause()`? `onDestroy()`? And there's no chance of it not being called, if it doesn't happen the event didn't happen – Zoe Oct 03 '17 at 19:05
  • @Zoe Sorry but I don't get what are you trying to say, can you please elaborate. – Sudhanshu Gaur Oct 03 '17 at 19:57
  • Ignore the lifecycle of an activity and focus on the lifecycle of the app itself. Create a class that extends Application and unregister the receiver when the onStop there is called. That is called separately from the activity lifecycle AFAIK – Zoe Oct 04 '17 at 05:54
  • @Zoe do you think four all above cases any event will trigger where I will unregister my receiver in my Application code ?? Because i don't think any event will happen. – Sudhanshu Gaur Oct 04 '17 at 09:30

1 Answers1

1

But as for all above cases even if i will write code in onStop() to unregister the receiver then still it will not get called

For three of the above cases, in the vast majority of cases, onStop() will be called:

  • If your process is terminated in an urgent fashion (e.g., the system needs RAM to process an incoming phone call)

  • If the user clicks "Force Stop" on your app's screen in Settings

  • On a few devices, if the user terminates your process using a manufacturer-supplied task manager

Android will not terminate a process that is in the foreground from a UI standpoint. In all of these cases, the vast majority of the time, your app will not be in the foreground, and therefore onStop() will have been called.

Moreover, in all three of these cases, your process is gone, and therefore your BroadcastReceiver is also gone. There is nothing to unregister. This is one of the reasons why tend not to worry too much about these scenarios. onDestroy() is for cleaning up things that might prevent your activity from being garbage-collected, and if your process is terminated, your activity and all other objects are all gone.

The one scenario from the four that remains is if your app crashes with an unhandled exception. In that case, your app is seriously messed up. If you have your own top-level uncaught exception handler, you might consider terminating your own process as part of cleanup.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Can you please see my updated post. I have some questions from you ?? And thanks a lot for helping me out of here man :) – Sudhanshu Gaur Oct 11 '17 at 16:44
  • @SudhanshuGaur: Android only ever kills the entire process. See [this blog post](https://commonsware.com/blog/2011/10/03/activities-not-destroyed-to-free-heap-space.html). – CommonsWare Oct 11 '17 at 17:49
  • what about unhandled exception ?? why there whole process don't get terminated ?? – Sudhanshu Gaur Oct 11 '17 at 17:56
  • @SudhanshuGaur: I did not write Android. I cannot tell you why Google engineers made the decisions that they did. – CommonsWare Oct 11 '17 at 18:27
  • Sorry i wanted to ask is the whole process get terminated there. by mistake I typed "why" sorry for that :( – Sudhanshu Gaur Oct 11 '17 at 18:36
  • 1
    @SudhanshuGaur: If you have an uncaught exception handler (e.g., ACRA, Crashlytics), then no. Many apps have one of these, to collect stack traces and send them to a server for analysis. – CommonsWare Oct 11 '17 at 18:38
  • Last question `Will there be any problem in using onDestroy() as according to you or not` ?? – Sudhanshu Gaur Oct 11 '17 at 18:50
  • @SudhanshuGaur: I have no way of answering that, sorry. – CommonsWare Oct 11 '17 at 19:00
  • But why ?? As according to you for all three cases it will work fine. – Sudhanshu Gaur Oct 11 '17 at 19:04
  • @SudhanshuGaur: I am not you. I have not seen your code. I know nothing about what is going on here, beyond what is in the question that you keep editing (confusing everybody else who sees this question, myself included). I can tell you about the behavior of Android. You have to apply that to your own situation yourself. And I cannot tell you if you will have problems or not. – CommonsWare Oct 11 '17 at 19:08
  • Yeah man it was my mistake to edit the question and put my questions over there(i didn't think it would be confusing). I have edited it again. Thanks finally for enlightening me about this topic. – Sudhanshu Gaur Oct 11 '17 at 19:27