[LVGL] Add a way to control when screen is created

[mvladic]

Currently, all the screens are created when ui_init() call is made. We should have an option Create at start for the page (enabled by default). It should be possible from both flow and code to:

• Create a screen object
• Delete a screen object
• Find out if screen object is created

[zalexzperez]

This is a promising idea! For clarity's sake let's call it the modular approach if you will.

But let me propose a different one here: the group approach. It would be similar to what we already have with widgets and the encoder/keypad groups for navigation.

With the group approach, the programmer wouldn't have to worry about managing which screen objects are already created and which ones require deleting. Upon adding new screens to the project in the future, the programmer would only have to assign the screen group to them. So it would escalate better. And to make it as flexible, a screen could belong to multiple groups.

So, when ui_init() call is made, the default group is loaded. Afterwards, the programmer would only use the Change screen group action widget/function.

What do you think?
Assuming what I said is right, I think it seems to be considerably harder to implement anyway, so it may not be worth it.

Edit:
How would all of this play with the Change Screen / Change to Previous Screen actions and the EEZ functions?
What if the screen we are requesting belongs to an inactive screen group?
I see we would need extra actions to retrieve information, defeating the initial idea.

[mvladic]

... the group approach ...
What do you think?

I think we should eventually address this in phase 2, because it is more complex to implement.

How would all of this play with the Change Screen / Change to Previous Screen actions and the EEZ functions?

Change Screen / Change to Previous Screen will automatically create screen if it is not currently created.

We can also automatically delete screen if it is not active anymore. But, this should be an option where you can choose to "Keep in memory" or "Remove from memory" when inactive.

What if the screen we are requesting belongs to an inactive screen group?

In that case we can switch to that group - I suppose switch means: release screens of current active group and create screens of the new group and make it active. But, I can think of the situation in the really complex application where you want multiple groups to be active at the same time.

---

I have on question for you. In your example where you can have normal execution of the app and OTA update execution (10 additional screens), does this means that either app is run in Normal mode or OTA Update mode, i.e. you are going from one mode to another only after reset?

[zalexzperez]

I have on question for you. In your example where you can have normal execution of the app and OTA update execution (10 additional screens), does this means that either app is run in Normal mode or OTA Update mode, i.e. you are going from one mode to another only after reset?

Yes, in my case the app only works in one mode at a time and the working mode is changed after a reset.

By doing this, I managed to reduce system heap usage and have a working OTA update mode at the expense of the normal mode, as the added screens for the updater part demand an increase in LV_MEM_SIZE. However, increasing that memory pool compromises the update mode again.

Edit:
This lazy loading feature would not just help with the update/normal modes matter, though.
For instance, I could as well avoid loading all my menu screens which aren't used unless user enters the menu, further reducing the required LV_MEM_SIZE.