Case for onPopped/onDestroy

[bangarharshit]

onShow and onHide are the only screen events. onHide is also called when a view comes in front. onPopped will be called when the screen is popped from the queue and can't be used in future.
This also means that if the developer store the fields in an instance variable and add it back to the queue it should throw an error.

Cases for it:

1. Leak analysis.
2. Allow for network requests which have the lifecycle of a screen.

onCreate/onPushed is not that important since we already have a constructor and with correct Rx multicasting, we can work around the limitations.

public class SomeScreen {
    private PublishSubject<NetworkResponse> responseSubject; // It can be non-reactive and just a state.
    private Observable<NetworkRequest> request;
    private Disposable hideDispoable;
    private Disposable poppedDisposable;

   void onPushed() {
      request.subscribe(responseSubject); //dispose it onPopped() - only 1 network call for a screen;
   }
   
   void onShow() {
      hideDisposable = responseSubject.subscribe(_ -> { // Do your stuff }) // dispose it in onHide().
   } 

   void onHide() {
      hideDisposable.clear();
    }

    void onPopped() {
        poppedDisposable.dispose();
        // Leak analysis unless a developer wants to cache or magellan should throw an error.
    }   
}

[fabiendevos]

I think there is a case for onPushed() as well actually. Will definitely consider it. Any other idea for the names? Not completely sold on onPushed/onPopped, and onCreate/onDestroy would be confusing with the activity one.