-2

While reading up on Android Lifecycles there is the following example code:

class MyActivity extends AppCompatActivity {
    private MyLocationListener myLocationListener;

    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, getLifecycle(), location -> {
            // update UI
        });
        Util.checkUserStatus(result -> {
            if (result) {
                myLocationListener.enable();
            }
        });
  }
}

class MyLocationListener implements LifecycleObserver {
    private boolean enabled = false;
    public MyLocationListener(Context context, Lifecycle lifecycle, Callback callback) {
       ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void start() {
        if (enabled) {
           // connect
        }
    }

    public void enable() {
        enabled = true;
        if (lifecycle.getCurrentState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void stop() {
        // disconnect if connected
    }
}

The constructor for MyLocationListener accepting both Context and Lifecycle got me wondering why these would be separate isolated classes. The Context class has so many similar global get functions already (e.g. getMainExecutor, getMainLooper, etc.), why wouldn't getLifecycle() fit right in? Or something like getMainLifecycle() to refer to the entry point activity's lifecycle?

Is there any published reasoning from Google regarding why the Lifecycle has been developed as a separate entity to the Context? Is there a case where it would be advantageous to have Context but no Lifecycle?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.