1

I'm new to Java and Android and I'm coming from a Qt/C++ background. In Qt there is this QCoreApplication object that represents the whole application and when this object is destroyed, the application dies. In Qt there is this signal on QCoreApplication which is QCoreApplication::aboutToQuit which gets emitted when the application is in an imminent process of being closed. This is very handy when you want, e.g. save settings data to disk just before the application is closed.

My question: Is there a similar aboutToQuit-like mechanism with which you could get notified when an Android application is imminently closing?

EDIT:

I would like to make some additions to my question after nPn answer. We cannot rely on the Android Activity Life Cycle as we need this information in a library/SDK we are developing. So we want to get notified when an application that is using our library/SDK is closing.

We are developing an SDK for some clients to use in Android apps. Like this would not be enough, this SDK also uses a native C++ SDK in the background with which is linked with through a JNI interface.

The end goal is to get notified in C++ that the application is being destroyed in Android. Having an event/signal in Android would be enough as we could forward the information to C++.

So as a resume the layers are: Android App -> Custom Android SDK -> Native C++ SDK

If there is something unclear, I will edit the question further

Jacob Krieg
  • 2,834
  • 15
  • 68
  • 140
  • Can't you expect the App developer to take care of that (signal)? Do you need to be informed when the application is destroyed or when a activity or background service on the App side is destroyed? – Peppermint Paddy Nov 11 '17 at 13:22

2 Answers2

2

Take a look at the Android Activity Life Cycle here

The the way Android works is rather than receiving a signal you implement/override one or more of the lifecycle methods, which gets called at various phases. For setting you might want to use onPause()

There are also Application level callbacks, and the ability to register your own callbacks, but these are all tied to the lifecycle.

If your issue is that you just don't want the app developer to have to add code to a lifecycle method, you always have the choice of subclassing and adding your own code before / after calling the super class method.

nPn
  • 16,254
  • 9
  • 35
  • 58
  • Thank you very much for the answer. I cannot rely on the `Android Activity Life Cycle`, please check the question edits to see why. – Jacob Krieg Nov 11 '17 at 12:48
  • I am not sure you are going to "signal", at least not in the public java/kotlin api. I think you can still make this work thru the life cycle methods. – nPn Nov 11 '17 at 14:06
1

I was just reading up on some of the latest developments (I have not been doing too much Android programing lately and wanted to learn more about the new recommended Architecture).

When I read the following, I thought about this question from a few days ago.

Lifecycle-aware components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain.

A common pattern is to implement the actions of the dependent components in the lifecycle methods of activities and fragments. However, this pattern leads to a poor organization of the code and to the proliferation of errors. By using lifecycle-aware components, you can move the code of dependent components out of the lifecycle methods and into the components themselves.

I think if some component in your library can implement the LifeCycleObserver interface, you would not need to rely on the callbacks in the Activities, Fragments, etc, rather you could observe the changes in your own objects and react accordingly.

For example if you create a class that implements the LifecycleObserver , such as this.

class LifeCycleMonitor(private val lifeCycleOwner: LifecycleOwner) : LifecycleObserver {

    init {
        lifeCycleOwner.lifecycle.addObserver(this)
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroyEvent() {
        println("activity was destroyed")
    }
}

and then instantiate the class in an object that is a LifecycleOwner (such as an Activity) the method annotated with the corresponding event will be called.

class MainActivity : AppCompatActivity() {

    private val lifeCycleMonitor = LifeCycleMonitor(this)

}

Note there is also a ProcessLifecycleOwner which might be even closer to what you are looking for, as it covers the entire App, not just a given Activity or Fragment.

nPn
  • 16,254
  • 9
  • 35
  • 58