cancel
Showing results for 
Search instead for 
Did you mean: 

Update graphics when values changes in Model::tick or View?

JS??d
Associate

https://touchgfx.zendesk.com/hc/en-us/articles/205074561-Connecting-the-UI-to-your-system

The code in the article is checking if the temperature is changed in the Model::tick, if changed then notify.

I prefer to notify all values (changed or not) in Model::tick and then check if values changes in Views i.e. (oldvalue != newvalue), is that good idea or not?

1 ACCEPTED SOLUTION

Accepted Solutions
Martin KJELDSEN
Chief III

Hi @Johan Söderlind Åström​,

it's more clean to do this kind of check somewhere else than in the view, which is mostly tasked with just presenting values. If you review the MVP structure of a TouchGFX application you could say that each View/Presenter is a state in itself in a statemachine where the presenter determines what to display and when. You could also say that model.cpp would get really bloated with a lot of checking of different values.

If you don't want to do this kind of check in the model you could create some more "Models" that handle specific areas of the domain. The far easiest is just to signal active presenters that some huge struct of data has changed, but you _may_ be left with less transparent code in the end. It's difficult to say. On the other hand, your modelListener interface will be simpler and you know that you should look for processing of "temperature" data in the "TemperaturePresenter" - Maybe. You see my point? Depending on your project, things can be cleaner or more messy.

If you want to go your current route with a single signal for all data, you should probably do your checks in the presenter, at least.

View solution in original post

1 REPLY 1
Martin KJELDSEN
Chief III

Hi @Johan Söderlind Åström​,

it's more clean to do this kind of check somewhere else than in the view, which is mostly tasked with just presenting values. If you review the MVP structure of a TouchGFX application you could say that each View/Presenter is a state in itself in a statemachine where the presenter determines what to display and when. You could also say that model.cpp would get really bloated with a lot of checking of different values.

If you don't want to do this kind of check in the model you could create some more "Models" that handle specific areas of the domain. The far easiest is just to signal active presenters that some huge struct of data has changed, but you _may_ be left with less transparent code in the end. It's difficult to say. On the other hand, your modelListener interface will be simpler and you know that you should look for processing of "temperature" data in the "TemperaturePresenter" - Maybe. You see my point? Depending on your project, things can be cleaner or more messy.

If you want to go your current route with a single signal for all data, you should probably do your checks in the presenter, at least.