How to drive reused containers?

[M-Schiller]

I'm currently working on my second ever TouchGFX project and keep stumbling upon the same issues as in my first one.

I have a battery indicator that I would like to show on (almost) every screen. For this reason I created a container that I can easily drop on every screen and implemented a few relevant methods on this container. This battery indicator is obviously driven by hardware (a FreeRTOS message is sent from the HW task to the TGFX task, if that makes any difference). Now the Model receives these messages and notifies the ModelListener via a virtual method like `virtual void notifyBatteryVoltage(uint8_t);` or similar.

Here is where it gets interesting to me:

• The base ModelListener cannot implement anything UI-related as it doesn't know anything about the View it will be attached to.
• It probably should not call anything on the base Presenter as this will couple the two aspects (ModelListener, Presenter) too tightly.
• Even if I implemented the previous point, the base Presenter doesn't have a reference to its related view.
• As far as I can tell, the base View is not meant to be extended as it is buried within the framework folder and replaced on e.g. version changes in TGFX.

So far, I have always overridden the `notifyBatteryVoltage` method on (almost) all screens' ModelListeners (i.e. Presenters), and implemented another layer of `notifyBatteryVoltage` on the Views that contain the battery indicator. These Views, in turn, will notify the reused container, i.e. call `setBatteryVoltage` on it.

In this way, I wrote the same code over and over again for about ten different Views and ten related Presenters.

I feel like I am missing something fundamental here. Is there any better way to achieve something like this?

[Martin KJELDSEN]

Yeah, whatever works, works!

[wired]

I also have a 'status bar' container at the top of my screen, which contains a number of icons that need to change based on device status (charging, battery level, etc.). I change the icons' visibility, switch icons based on battery level, and also do fade in/outs. I maintain the status of the icons (alpha values, visibility, etc) in a static structure so that when the container is initialized each time a screen changes, the initialize() method will update everything to the current status.

I also have a handleTickEvent() for the container to perform the realtime screen updates while on any given screen, e.g. performing alpha operations (while also updating the static structure, and setting visibilities, and displaying the correct icons). I do have to have an external declaration of a structure where all of the status data is acquired and updated in a different task, but it's a small price to pay to get my status bar functionality encapsulated in a single file, StatusBar.cpp.

I also use the SIMULATOR definition to declare variables locally rather than externally, so that my status bar can somewhat function in the simulator.

I know I'm breaking some MVP rules, but you gotta do what you gotta do...