Comments (6)
Nothing is black or white in software development. So your packages are good, but you'll probably find issues in a big App. But you can refactor during the process, so I wouldn't worry too much about it.
The thing is that interactors can be easily reused, so you'll probably want to have them in a separate package (or even module).
The second question you ask is closely related to the first one. As those are components that will be reused (for instance) by many interactors, they are a separate entity, so should live in a separate package.
You could have something like this:
- interactors
- LoginInteractor.java
- model
- AmazonClient.java
- FirebaseClient.java
- ui
- login
- LoginView.java
- LoginActivity.java
- LoginPresenter.java
- home
- detail
- login
The experience has taught me since I wrote this code almost 4 years ago (and you'll probably feel the same at some point) that the interfaces for presenters and interactors are not of much use, so you can get rid of them.
This is one of the many possibilites, it's more a matter of taste that something written into stone. So try different things and extract your own conclusions.
from androidmvp.
In a large App, you would see that you create interfaces that are not used for anything else in this case. If you could have several presenters implementing the same interface, that would be useful. But normally not the case.
In any case, using them won't hurt either, and can have some benefits for testing purposes.
from androidmvp.
Yup, it's the other way round. You don't need a presenter interface, something like:
interface MainPresenter
class MainPresenterImpl : MainPresenter
Because you will usually only have one implementation of the presenter, so it's redundant. As there's no dependency inversion here (I'll talk about this in an article soon), it's extra work without much benefit.
from androidmvp.
What about if you have som cloud storage/networking for Amazon S3 and EC2 or Google App engine/FIrebase. Where should the classes for these operations be?
from androidmvp.
Thanks for grate work
Can you clarify what you mean by "interfaces for presenters and interactors are not of much use, so you can get rid of them."
As I understand in your androidmvp code, every view have a presenter that has a view interface to dispatch messages back to that view, and same for interactors that has the presenter interface to dispatch messages back up to presenter
from androidmvp.
Thanks I stil have much to learn thanks for the lessen.
I see in the MainActivity
the private MainPresenter presenter;
interface that you say is not needed, is used to hide implementation details in the MainPresenterImpl
.
I though that was a good thing!
Do you mean I should look at the MainPresenterImpl
like it was larger Singleton ok i understand maybe.
Must learn more on the dependency inversion SOLID
In your androidmvp code it looks really ok with the interfaces but it´s just a small small demo and the interfaces makes sense there, ok get it thanks for the lesson
from androidmvp.
Related Issues (18)
- Unit tests HOT 6
- Orientation Change HOT 2
- More advanced use cases HOT 6
- how make request for one api HOT 2
- Import this project HOT 2
- Scrren rotation HOT 2
- There is a loose coupling between View and Model in main package
- I'd like to create Mockito tests for the LoginPresenterImpl HOT 3
- Interactor what in MVP HOT 11
- Interactor being instantiated in the View HOT 4
- [Question] Which is better using contact? or dividing presenter between view interface? HOT 3
- Where to reach domain layer from MVP HOT 2
- DI with your MVP example HOT 2
- LoginInteractor中的一个小问题 HOT 2
- I have a problem in gradle build
- How about life cycles ? HOT 1
- Memory Leak in Activity? HOT 12
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 androidmvp.