cancel
Showing results for 
Search instead for 
Did you mean: 

Using separate Model for screens

PBU
Associate III

Hi,

Is it possible to use multiple models in touchgfx. I have designed six screens for my application and all the screens are interacting with a single model. I would like to use separate model for each of the screens. Is it possible to do that. If yes, give me an idea to implement that.

1 ACCEPTED SOLUTION

Accepted Solutions
Martin KJELDSEN
Chief III

What's the main reason you want to have a separate model for each screen? Just simplicity? The Model is passed around to any Presenter that becomes inactive, and is also ticked by the HAL. You could create some interfaces for presenters that have a reference to the model and bundle the methods that are relevant to that presenter. Model.cpp can become large, given enough screens, so bundling relevant methods based on screen type can be a good idea.

So, have the generic send/receive methods in Model.cpp but have the concrete interface for sending Presenter-type messages in a concrete interface so that no screen specific logic is placed in Model.cpp. Also, if you're checking OS message queues you could also have those inside the Presenter specific interface and simply tick your presenter objects whenever Model::tick() is called (Maybe even only tick the interface for that presenter if its view is active) and only check the messages that are relevant to your presenter.

Does that make sense?

/Martin

View solution in original post

6 REPLIES 6
cameronf
Senior

I'm not sure how to go about this in the traditional sense of having a model for each view, but you could do it by making your 6 model classes and having an instance of each in the main model instance. You could then give each presenter a pointer to the corresponding instance in your model. It's purely organizational as each presenter technically still has access to the whole model.

If there are variables you need while a screen is active but that variable doesn't need to persist between screen changes and isn't used by the back-end logic you could also put it in the presenter for that screen instead of the model.

Martin KJELDSEN
Chief III

What's the main reason you want to have a separate model for each screen? Just simplicity? The Model is passed around to any Presenter that becomes inactive, and is also ticked by the HAL. You could create some interfaces for presenters that have a reference to the model and bundle the methods that are relevant to that presenter. Model.cpp can become large, given enough screens, so bundling relevant methods based on screen type can be a good idea.

So, have the generic send/receive methods in Model.cpp but have the concrete interface for sending Presenter-type messages in a concrete interface so that no screen specific logic is placed in Model.cpp. Also, if you're checking OS message queues you could also have those inside the Presenter specific interface and simply tick your presenter objects whenever Model::tick() is called (Maybe even only tick the interface for that presenter if its view is active) and only check the messages that are relevant to your presenter.

Does that make sense?

/Martin

Martin KJELDSEN
Chief III

Hi @PBU​ ,

Any progress on this?

/Martin

Hi @Martin KJELDSEN​ 

Thanks for the reply. Yeah for simplicity only i want to had separate model for each screens. As you said i have implemented the business logic of the screens in respective presenter class and using generic send/ receive methods in model.cpp.

Allright. Happy with it?

/Martin

PBU
Associate III

Yeah i'm happy with that 😊