Naming on variables/methods in Presenter class

[rwinograd]

We decided that for switching modes in our application (For example: Signed in / Not signed in), we wanted to have a blueprint for each mode. We put this state into a Presenter class and actually bound an activity to it, rather than a view (i.e. we have something extend Presenter and override the MortarScope method to pull scope directly from the bound activity). Now when someone signs-in, we call into the presenter which calls into the activity where we call setContentView directly to change the mode. The entire thing is very similar to the showScreen example on the main Mortar page.

Everything works quite well, but the methods on the base Presenter class are named in a way that makes it unclear if this is recommended/supported/okay. Essentially we are binding our activity to the presenter in activity#onCreate with takeView(activity), unbinding in activity#onDestroy with dropView(activity) and within the Presenter class we call getView to get the activity reference and call into it accordingly. Looking at the Presenter base class there doesn't seem to be anything there other than naming that necessitates a view being passed in, and the presence of a specific ViewPresenter seems to imply that the Presenter base class is intended to be flexible (Generics are named V, but don't need to extend View).

Really the only issue appears to be that the names cause our intentions to be less than clear. I was hoping people would be open to renaming some variables/methods/generic types within the presenter class hierarchy. Alternatively, we could leave the naming as is in the ViewPresenter, but creating a corresponding ActivityPresenter and change the Presenter base class to be concrete final helper that's less tied to views.

I'm happy to submit a pull request if it would be welcome.

[loganj]

Speaking for myself, not for @rjrjr: The names we have come from MVP, so they still seem reasonable to me despite the namespace clash with Android's View. More often than not, a Mortar view is an Android View.

That's my best argument for the names we have, but my best argument against adopting other terminology is just that I haven't heard anything better. I could be convinced by a decent proposal for specific terminology that's accurate and not horribly contrived..

[rjrjr]

Remember that view is a very generic term, much older than Android. (And older than MVP, for that matter. Model View Controller from Smalltalk 80). Mortar is agnostic as to whether a view class extends View, Activity, Fragment, or whatever else. That's why the ViewPresenter convenience class is separate from the base Presenter.

We have a decent handful of Presenters hanging off of our main activity. We try to minimize how much we do that, preferring that only code with actual depenencies on Activity itself lives in such a presenter. But it's definitely a supported use case.

I'm not crazy about the idea of changning any of the names, but improved Javadoc is always welcome.