0

We have used the MVP methodology within our embedded system (using the LittlevGL library). With our current implementation its our Views which first get activated, these then in turn activate their Presenter. So far this has worked fine for our simple GUI's.

However we are now creating more complex GUI's in which Views are sometimes not shown based information from the Model. This presents a bit of a problem as the View and the Model obviously don't know about one another.

Therefore I am now thinking that it should have been our Presenters which are always activated first. They can then get data from the Model and then make the decision as to whether to activate its Presenter or not. Is this generally how MVP should be used anyway? It is OK for the Presenter to store a pointer (this is C code) to the View GUI object?

Any thoughts on this would be greatly appreciated.

TheGrovesy
  • 251
  • 4
  • 13
  • *"how can a View know if it is allowed to be displayed?"* - by asking it to the controller. – Marco Bonelli Oct 01 '19 at 10:14
  • Via the presenter you mean? I always thought that they View should be really dumb and not really make any calls to the presenter (other than activate in our case), and that it is the presenter that should be asking the controller then making a call to the view? – TheGrovesy Oct 01 '19 at 11:30
  • Ah, yes, you're right, I wrongly read MV**C** instead of MV**P**. The Presenter should act upon the view to modify it and only display what is allowed. – Marco Bonelli Oct 01 '19 at 11:31
  • So do you agree that we should probably be calling our presenters first, which will then get what they need from the model, then they instantiate the view if its allowed? Rather than our current implementation where we call our views first, who in turn call our presenters (which does feel the wrong way round to me)? – TheGrovesy Oct 01 '19 at 11:41
  • Yes, I agree :) – Marco Bonelli Oct 01 '19 at 11:44

0 Answers0