Comments (10)
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
from rosie.
We should do the same with the empty case and the error case view.
from rosie.
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?
from rosie.
I think the option number 3 is going to be the best one or at least the most flexible one. Thoughts @flipper83 @Serchinastico ?
from rosie.
Yup, I'd say option 3 is the way to go until we get mixins with Java 8.
from rosie.
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?
from rosie.
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.
from rosie.
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?
from rosie.
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?
from rosie.
Yeap @JorgeCastilloPrz you are right. I'm closing this issue.
from rosie.
Related Issues (20)
- Improve ``PresenterLifeCycleLinker`` public API.
- Extending RosieApplication HOT 4
- RosieSupportFragment HOT 3
- How to connect a Activity to its Presenter without Injection? HOT 4
- Communication between presenters HOT 5
- Remove ButterKnife and Renderers library. HOT 1
- I have another question, How can I include third library in my arr like your rosie? HOT 5
- NoSuchMethodError. No ButterKnife.bind(Activity) method HOT 1
- Uses cases from sync service (question) HOT 1
- Extract caching logic from RosieRepository.java HOT 1
- OnErrorCallback null pointer exception with Marshmallow devices HOT 1
- Reflection Performance HOT 3
- Searching in repositories HOT 2
- Stabilize Travis-CI builds HOT 2
- provide a proguard rules HOT 1
- NullPointerException sometimes in RosieUseCase.notifyError() HOT 1
- Release 2.1.1 - ButterKnife changes HOT 2
- RuntimeException with 2 or more presenters HOT 1
- Error when running a signed APK HOT 17
- Rosie incompatible with android.arch.lifecycle ¿? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rosie.