2020-03-17 09:21 AM
I'm trying to use the MVP system in what is hopefully a correct manner. The way I understand it, the Presenter takes the data from the Model and assembles it in a way that the View can display.
However, in the present implementation of the MVP in TouchGFX, the view is being configured before the Presenter has a chance to configure this information.
For example, when trying to implement a scroll wheel, I'm supposed to override the ScrollWheelUpdateItem as below:
void Screen2View::scrollWheel1UpdateItem(ListItem& item, int16_t itemIndex)
{
touchgfx::TypedTextId id = presenter->getParameterOptionText(itemIndex);
std::cout << "Setting text index to:" << id << std::endl;
item.setText(id);
}
However, the call tree for switching to a different view is first initializing the view and *then* initializing the presenter. The following is from the TouchGFX library (MVPApplication.hpp):
static inline void finalizeTransition(Screen* newScreen, Presenter* newPresenter, Transition* newTransition)
{
newScreen->setupScreen();
newPresenter->activate();
newScreen->bindTransition(*newTransition);
newTransition->init();
Application::getInstance()->draw();
}
As you can see, "setupScreen" is called *before* the presenter has been activated. Why? When the "setupScreen" is called, it's calling functions that rely on the presenter, which doesn't have the information yet. To me, it would make much more sense that lines 3&4 are swapped. Am I missing something?
Thanks,
Jeremy
Solved! Go to Solution.
2024-08-07 06:27 AM
Hello @j o ,
In TouchGFX, the presenter acts as a bridge between the view and the model as mentioned here. Every screen contains a view (a collection of the widgets) and a presenter, while there is only one model throughout the application that communicates with the backend.
So, whenever a new screen is going to be shown, TouchGFX calls its corresponding view and presenter. We already know how the widgets should look, therefore, we call setupScreen() first. Then, we call activate() the presenter, which, if required, can read the relevant data from the model (like data from the previous screens or from hardware) and call functions available in the view to update the state of the widgets (for instance, hiding a Wi-Fi icon if there is no Wi-Fi signal received by the model). That's why setupScreen() is called first.
You can read more about the concept of screens in TouchGFX here.
I hope I have answered your question. Feel free to ask more questions if you have any!
2020-03-17 09:35 AM
I believe this order of execution.
TouchGFX Order of Execution
[MODEL ]:Constructor()
[ VIEW :Main ]:Constructor()
[MODEL_LISTENER]:Constructor()
[ PRESENTER :Main]:Constructor()
[ VIEW :Main ]-> setupScreen()
[ PRESENTER :Main]-> activate()
[ VIEW :Main ]-> tearDownScreen
[ PRESENTER :Main]-> deactivate()
[ VIEW :Main ]:Destructor()
[ PRESENTER :Main]:Destructor()
[MODEL_LISTENER]:Destructor()
2020-03-17 09:41 AM
I know that's the order of execution, but as I said in my email, why is the presenter being activated *after* the screen is being setup? It needs the data that isn't yet activated in the presenter. If "activate" isn't supposed to setup data, what is it supposed to do, and where to I setup my data?
2024-08-05 01:26 PM
@j o wrote:I know that's the order of execution, but as I said in my email, why is the presenter being activated *after* the screen is being setup? It needs the data that isn't yet activated in the presenter. If "activate" isn't supposed to setup data, what is it supposed to do, and where to I setup my data?
Yes, this ^^^. Did you every get an answer?
2024-08-07 06:27 AM
Hello @j o ,
In TouchGFX, the presenter acts as a bridge between the view and the model as mentioned here. Every screen contains a view (a collection of the widgets) and a presenter, while there is only one model throughout the application that communicates with the backend.
So, whenever a new screen is going to be shown, TouchGFX calls its corresponding view and presenter. We already know how the widgets should look, therefore, we call setupScreen() first. Then, we call activate() the presenter, which, if required, can read the relevant data from the model (like data from the previous screens or from hardware) and call functions available in the view to update the state of the widgets (for instance, hiding a Wi-Fi icon if there is no Wi-Fi signal received by the model). That's why setupScreen() is called first.
You can read more about the concept of screens in TouchGFX here.
I hope I have answered your question. Feel free to ask more questions if you have any!