how Model.cpp can know when a screen is changed on the UI..

[andrea venturi]

hi, i have a touchGFX app working smoothly with some business logic on other tasks; that's all good and well.

now some screens have to show frequent data from biz logic, and others not. so i'd like to make the biz logic controller aware of the screen currently on display.

i could easily put on every screen "setupScreen()" an action to push to Model and then to the "other task" the id of the screen currently on display..

BUT i really believe there should already be a "callback" for the Model object to be notified when a new Screen is being displayed (with some kind of ID.. i suppose there's an ENUM of all the Screen ID, right)..

so i'll ask here, to the more knowledgeable, if there's already this callbak on Model object.. this way, will do not reinvent the wheel..

Thanx

[Martin KJELDSEN]

There's no callback and no enum- It's a pretty application specific thing which is easy to implement just like you said. We try not to bloat the framework with too many things like that, especially since we very, very, very rarely hear about the need. If enough people want it, we'd probably do it.

Just do it yourself, but do it inside activate() of the presenter instead. Define an enum with all the screens, have the presenters activate function set the current screen in the model and do whatever you want with that information from here on.

/Martin

[andrea venturi]

thanx Martin for the fast and thorough reply..

it's more then a year, i'm developing on TouchGFX and let me tell you, it's a pleasure! you guys did an amazing work!

now that you are moving to more boards and more integration with STM32 IDE, that will be such a compelling integrated solution, not many competitors can show

anyway back on the topic, let me tell you, at the beginning me too was not so looking too much to "shave off" CPU cycles from my core logic. then recently i've been asked to provide "higher throughput" on some "service" screens and less on "standard operation" screens, and i would not send lot's of "wasted data" to the UI, when not needed.

i can understand, it would mess a bit with the "pure" approach of the virtual fn of the presenter/view, so can be seen a bit as a hack (but on a micro like a F429 you need to pay attention to these trade-off!)

speaking more generally, i found out that if you need to keep in sync he UI/Model state and the "business logic" state, you need to put in place some juggling between the two tasks. Don't know if you are aware of best practices giving some relief to the system. a "global struct" could be an "brute force" approach, with access controlled by a semaphore, but not very elegant as approch, i fear!

[Martin KJELDSEN]

Thanks for the kind words, Andrea! We try our best :)

What do you mean by "keep in sync" ? Do you mean that you want to avoid the UI sending information to some task, and vice versa? That they just check some global data storage?

[andrea venturi]

typically, when the UI gets to a screen, we need to update, in the setupScreen() ,the widgets from values from the Model, and the Model would need to "ask" the data to the business logic with a message on a queue, and waiting back the answer. but that is taking too much time (many vars to be on display).

so i started pushing all the values that "could" be on display in some screen, from the biz logic task to the UI/Model task (of course only when the value changes..)

and for each value , there's not only storing in the local "cached" var but also an invocation to the virtual fn that "could" push the value down presenter/view if the right screen is shown..

in the long run, and with the program growing in term of screens and data, this is beginning to "tax" a bit the SOC cpu.. (BTW i've seen the "instrumentation" to meter the "CPU" occupation, embedded into TouchGFX, but it always return 100% busy, maybe because i have some other tasks in polling mode, and not stuck on the incoming message queue, but that's another topic..).

so, i'm really trying to understand if there are better practices or if this way to go. i have to say that maybe i hitting the ceiling of a poor STM32F429, and maybe i should (have) switch(ed) to a different more juicy STM32.. (that is bringing me another issue about how to "shave off" some bits from the flash, but i think i'll file another post for that question..)