We should do the same with the empty case and the error case view.

I am looking at this because I faced a similar problem in another project and would be good to help and at the same time to find a standard solution.

The first proposal of this issue was to add the LoadingPresenter with the ViewWithLoading interface, to implement the show/hide loading, given that is used in a lot of views. But then appear another situations that are also widely used like the ones that @pedrovgs suggest.

I think there are 3 solutions to this:

1.- Create a lot small Views with a lot Presenters implementing each:

• RosiePresenterWithLoading
• RosiePresenterWithEmptyCase
• RosiePresenterWithError
• RosiePresenterWithNoConnectionWarning
  etc...

The problem with this one is that we couldn't extend our presenter from more than once, we could implement more than one view on the view of our presenter, but then having the RosiePresenters won't have any utility.

So I think we can easily discard this one.

2.- Create a RosiePresenterWithSteroids
We put all the methods that we can think (show/hide loading, showError, showEmptyCase... ) in this PresenterWithSteroids, and its view.

The problem is to implement this class without wanting to use all its functionality, we may end with a lot of empty implementations in the View. We could solve this with default methods form Java 8 or a NullObjectPattern.

3.- We remove this extended classes, expand the sample with more BasePresenters to help the users to get code from there, and reduce the library classes.

What do you think?

I think the option number 3 is going to be the best one or at least the most flexible one. Thoughts @flipper83 @Serchinastico ?

Yup, I'd say option 3 is the way to go until we get mixins with Java 8.

option 3 is the good one for me too, because two is impossible for now. and we can use any kind of composition. I have an idea, that it's have small getViews interfaces and can do something similar to.

getView(LoadingView.class).hideLoading(); or have a map for enums. and if your view have this interface implemented it, invoke it. Have this sense?

I prefer simple solutions for this case. Add the method to the View interface just if need it. IMHO documentation here is more interesting than code.

I was talking with @pedrovgs about have a module with addons, and add here some kind of interfaces with method that you can add to your view interfaces. Do you like the idea?

I think that if you look for examples, the sample is self-explanatory enough. With the module of add-ons, which solution would you implement? The PresenterWithSteroids? or just three or four cases? Is it not better just to add a couple of examples on the sample?

Isn't this already done ? I was checking this RosiePresenterWithLoading class.

I think adding more custom view contracts like the one defined in RosiePresenterWithLoading to the sample code should be enough. It is a good way to teach users about how to define their own view behaviors IMO. You are doing more than enough providing them with all the lifecycle linking / null view objects for this layer

Yeap @JorgeCastilloPrz you are right. I'm closing this issue.