square/mortar — pull request #28 by pyricau (2014-01-26 21:25:51+00:00)
Title: Eager calls to takeView()

Views shouldn't wait for the onAttachToWindow() callback to call Presenter.takeView(). The presentation logic and the view hierarchy should all be loaded (based on saved instance state) when onCreate() is done.

This PR:

* moves the calls from onAttachToWindow() to either View.onFinishInflate() (in case of an inflated view group), or in the view constructor.
* Also removed `Mortar.inject(getContext(), this);` from `FlowOwnerView`. It's already done in its subclass `MainView`. I wasn't sure where to keep it, but `FlowOwnerView` doesn't have any injects so...
* FlowOwnerView doesn't need to keep `lastRestoredHierarchyState` around anymore. Yey!

**DO NOT MERGE**

As per `mortar.MortarActivityScope#register` documentation:

```
/**
* Registers the given to have its {@link Scoped#onDestroy()} method called. In addition,
* if it is an instance of {@link Bundler}:
*

*
{@link Bundler#onLoad} is called immediately

*
{@link Bundler#onLoad} is also called from {@link android.app.Activity#onResume()}
*
{@link Bundler#onSave} is called from {@link android.app.Activity#onSaveInstanceState}
*

* Note well that calls to onLoad and onSave are not symmetric: it is par for the course to
* receive redundant onLoad calls.
*/
@Override void register(Scoped s);
```

This leads to a double call to Bundle.onLoad() on presenters, which means we're doing unnecessary work. It wasn't a problem before because that onLoad call would happen when the views where not taken by the presenter yet. So the double call was "useful" in that case (kinda meh though).

Now, is there any other good reason for calling Bundler#onLoad from Activity#onResume?

If not, then I suggest we just remove that behavior. If yes, we'll need to prevent that double call. Loading a presenter from onResume() is wrong anyway.