Presenter#activate called after screen's #setupScreen?

[farble1670]

I can see from logging that my Presenter's #activate is called after the screen's #setupScreen. 

This seems wrong. The screen depends on the presenter. There should be an opportunity for the presenter to initialize itself before the screen uses it.

Am I misunderstanding something?

Thanks.

 

[Mohammad MORADI ESFAHANIASL]

Hello @farble1670,

That's a fair and good question.
If you look at the generated code for your ScreenPresenter.hpp, you will see that the constructor takes a reference to the corresponding screen as an argument. Hence, it means the presenter depends on the screen.

 

#ifndef SCREEN1PRESENTER_HPP
#define SCREEN1PRESENTER_HPP

#include <gui/model/ModelListener.hpp>
#include <mvp/Presenter.hpp>

using namespace touchgfx;

class Screen1View;

class Screen1Presenter : public touchgfx::Presenter, public ModelListener
{
public:
 Screen1Presenter(Screen1View& v);

 /**
 * The activate function is called automatically when this screen is "switched in"
 * (ie. made active). Initialization logic can be placed here.
 */
 virtual void activate();

 /**
 * The deactivate function is called automatically when this screen is "switched out"
 * (ie. made inactive). Teardown functionality can be placed here.
 */
 virtual void deactivate();

 virtual ~Screen1Presenter() {}

private:
 Screen1Presenter();

 Screen1View& view;
};

#endif // SCREEN1PRESENTER_HPP

 

You can read more about the Model-View architecture used in TouchGFX here. .

I hope this answers your question. Don't hesitate to ask more!

[farble1670]

---

@Mohammad MORADI ESFAHANIASL wrote:

If you look at the generated code for your ScreenPresenter.hpp, you will see that the constructor takes a reference to the corresponding screen as an argument. Hence, it means the presenter depends on the screen.

Let's get back to the root problem. If the view can't rely on the presenter being "activated" before it's used, what's the point of having an activate method? Here's your generated code:

 

 /**
 * The activate function is called automatically when this screen is "switched in"
 * (ie. made active). Initialization logic can be placed here.
 */
 virtual void activate();

 

It says it right there: "Initialization logic can be placed here".

I guess we could debate what's meant by "screen is switched in" but it certainly implies before the system starts calling methods in the (view) object.

 

[Mohammad MORADI ESFAHANIASL]

The activate() function is used to start using the screen's presenter and screen's view because TouchGFX shows only one screen at a time. When the presenter is set to be active, then the activate() function is called. By "Initialization logic" we mean the steps that are required for showing the screen.

For instance, imagine that you have a screen that shows a Wi-Fi icon (it is shown in an image widget) when the Wi-Fi is accessible, and hides it if it is not available. When this screen is going to be shown, in other words, it is switched in, TouchGFX knows that this screen is made out of a number of widgets plus our Wi-Fi icon image. These widgets are part of the view. Now that we know the elements, we activate the presenter, and from the presenter we can ask the state of the Wi-Fi from the model. Therefore, we can call a method of the view to either show the Wi-Fi icon or not from the presenter based on the status received from the model. Hence, the presenter needs to know what functions or widgets are available in the view, and that's why the setupScreen() is called first.

I hope this clears out the obfuscation. 

You can check out more documentation about the concept of screen here, and there is an example called Understanding Application Structure available in TouchGFX that can showcase the connection between Model-View-Presenter:

Understanding Application Structure example