I am converting my application to use the MVP pattern. There is some debate between the developers on the proper use of MVP especially in regards to the Android lifecycle and where the UI related logic goes. There is no debate that any hard logic should be done in the presenter, and that the network
In the case I need to do Anything for lifecycle functions, onresume, onPause, etc. Should I ...
- Call a mPresenter.onResumeEvent(); The presenter then does calls. IE contract.restoreState(); contract.connectToService() etc.
or
- Do all the logic I need here and not involve the controller. IE restoreState, start up loading spinners, etc.
I view it as onResume is an event. All events should be processed by the Presenter. The counter arguments is, we do not want to write code that "ping pongs," I.E. OnResume -> Presenter -> one line function that shows a spinner (or something close to that effect)
Now a bit more granule. Lets says I start my activity, and I need to show either an error or the data depending if the data is null.
I could either do..
(presenter)
contract.setupUi(data);
then
(view)
setupUi(Object data){
if(data != null){
//show data
}
else{
//show error
}
Which has the UI controlling the state evoked from the presenter.
Or I could do
(presenter)
if(data != null){
contract.showUI(data);
}
else{
contract.showError();
}
Which has the contract looking at all the states.
Is the over all goal to have the Presenter Completely control everything about the application and treat the view as completely Dumb. Or is it just dividing up the code purely for testing purposes. Or is it both?
Recap.
- How should I handle the lifecycle -- treat it as an event or let the view just do it.
- Where should the view related logic go? Let the Presenter figure out what is null and what UI to show. Or let the view take care of it?
- What should my over all focus be? Controlling the app with the presenter, unit testing, both?
Aucun commentaire:
Enregistrer un commentaire