MVP Design Pattern help

General discussion
1

Hi all,

We have been playing with LittlevGL for a while and now need to create a GUI for our product. To keep things in line with the rest of our system we want to use the MVP (Model-View-Presenter) design pattern so that we can TDD all logic. We understand the precipices of MVP however there are a few elements that are not clear to us and would like input from others who have experience in this.

  1. Is the ‘Model’ part of MVP really just ‘the rest of the system that does the work’ or is it its own layer that sites between the Presenter and the System?

  2. What is the scope of a View? Within out team we cannot agree if the View should be an individual screen or page, or if it should be more granular than that. For example should a screen be split into many separate Views each handling one or two LittlevGL objects which are related? I can see that separating things out could give better reuse, but it does add its own complexity and I am not sure how much we would really want to reuse.

Any thoughts on this would be greatly appreciated.

2

IMHO, and Coding (As the UI designer uses this):
Model - Data for page
View - The page
Presenter - LVGL

Sorry, for reviving a dead msg, but this may be something that others might find useful.

3

Thanks for reminding me to follow this up…

We actually ended up making our backend embedded system effectively the Model. The View is a related collection of lvgl widgets. And the presenter was the glue in the middle. Every component in our system use interfaces so this works perfectly with MVP.

This actually worked out brilliantly and was extremely flexible and versatile. As an example we might have a View which is an individual setting in a list of settings. We made this view very generic so can be reused, with interface for setting the description text, help text and the value of the property which could be edited.

The presenter periodically calls into the model (system) to get the current value, it then formats it appropriately before calling the views SetValue function. As well as setting the description and help text.

This mean that the view has almost no logic other than calling lvgl functions and all the formatting etc in the presenters can be easily TDD.

We also use the presenters to handle the callbacks from user buttons presses etc, again allowing us to TDD the logic.

Finally we have views/presenters which can be nested to allow the build up of larger views.

Would totally recommend this approach.