We need examples of how Lifecycles work with global objects that "live" in Application scope

Hi guys, I can’t find an example of how to handle a situation when a callback needs to be dispatched from a global object that lives in Application scope.

Given the potential multiplicity of Lifecycles involved, is this possible at all?

I would like to refactor this code to use Lifecycles:

public class MyActivity extends Activity implements UserStateManagerListener {
 
    private UserStateManager mUserStateManager;
 
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
        mUserStateManager = ((MyApplication)getApplication()).getUserStateManager();
    }
 
    @Override
    protected void onStart() {
        super.onStart();
        mUserStateManager.registerListener(this);
    }
 
    @Override
    protected void onStop() {
        super.onStop();
        mUserStateManager.unregisterListener(this);
    }
 
    @Override
    public boolean onUserStateChanged(UserState userState) {
        ...
    }
}

P.S. I also opened similar issue in googlecodelabs: https://github.com/googlecodelabs/android-lifecycles/issues/12

[yigit]

there was a good conversation on reddit when this was post there but I cannot find it.

tl;dr; you can use anything wrong, that does not make it bad or wrong. In fact, in this case, it is really hard to mis-use these because the receiver knows it is a Lifecycle.

The example mentions keeping a reference to a lifecycle knowing that it is a lifecycle. If developer wants to shoot themselves on the foot, we cannot stop that 😃 . This was always the case, Lifecycles just makes it harder to leak it (because instead of receiving a callback, you receive a callback with a lifecycle so you know what you are getting).

On top of this, we have classes like LiveData that totally abstracts this handling. In the GithubBrowser demo in this repo, you can see that the Repositories return LiveData’s. They don’t keep a reference to the LiveData objects but they could have and it would still not leak.

Unlike calling methods on onStop/onStart, LiveData handles unexpected calls as well, which is one of the major reasons for leaks. For instance, you might be observing a value on user click, and you would think that you are safe because in onStop, you are unsubscribing. You are actually not safe because onClick callback may arrive after onStop. We see lots of errors with that code. Because LiveData knows about the Lifecycle, it easily handles such subscriptions, even when they happen after onStop. So it is a lot more bullet proof then custom onStart / onStop implementation.

About the loss of encapsulation argument, I don’t agree with that either. The UI does not need to know when the PostManager should be stopped or when it should work. It only cares about a particular data and if data is there it reacts. On the argument of not knowing data is loading, it is as simple as fixing the object it is dispatching and make it a value object that includes status (the same way the Resource class works in the GithubBrowser app). With that, you’ve completely de-coupled the UI from the business, can easily mock that LiveData etc. Jake has nice talk on this topic: http://jakewharton.com/the-state-of-managing-state-with-rxjava/

Making global classes controlled by non-permanent UI Controllers seems like a very bad argument to me.

Btw, to be clear, LiveData does not solve every single use case. e.g. the one here, about responding to changes, is not easy to implement (unless you create your own LiveData). We will probably create more components like it but LiveData is the 80% of the use cases so we prefer to focus on that and see usage patterns before making more stuff on top of it.

[yigit]

If your application global class (UserStateManager) provides its data in form of a LiveData, the Activity can observe it with its lifecycle and you won’t need to cleanup manually.