Why Manage Lifecycle Through Application Class?

I was reviewing code from a chat demo application and I noticed that they created a class that extended Application, and inside the onCreate() was the following line registerActivi

Solution 1:

I don't know, but have just Googled. Check the source.

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/app/Application.java.

You can see that all this does is call your callback methods, there is no further processing. The comments also indicate that it's designed usage is for handling state persistence.

Therefore, you could achieve the same by creating an Activity base class which provides overrides of the activity callbacks then extend all of your activities from this.

publicclassBaseActivityextendsActivity{
    @overridepublicvoidonCreate(){
          super.onCreate(); // calls the framework method
    }
}

publicclassActivity1extendsBaseActivity{
    @overridepublicvoidonCreate(){
         super.onCreate(); // calls the base method which in turn calls the framework method
         ...
    }
}

publicclassActivity2extendsBaseActivity{
    @overridepublicvoidonCreate(){
         super.onCreate();
         ...
    }
}

These methods will be called for all activities, regardless of whether they extend a base class. So this class lifecycle will automatically make those callbacks without you having to do anything more. Note that it only extends Activity, not BaseActivity.

publicclassActivity3extendsActivity{
     @overridepublicvoidonCreate(){
          super.onCreate();
          ...
     }
 }

Since you cannot have multiple inheritance in Java,if an activity needed to extend something other than a base class for all activities, you would have to start chaining callbacks which could get messy quickly.

Finally, since ActivityLifecycleCallbacks is an interface, and since you can register multiple implemenations of that interface, you could have one set of callbacks to manage application state, another to manage user state, perhaps one to manage service or resource handling and so on without having to mix that code in a single call back method.