My apologies if the video is a big too long in terms of height. I’ve been working really hard to get my app out there, yet the more I move closer to my goals the more there is to do. I’m not sad about that though, if anything this has been one hell of a productive week.
I feel like I should start talking about the interactions between Qt Quick/QML types with your C++ backend. I must say that I’ve had the wrong idea since the beginning. Why? Well, if you must ask I will tell you a nightmare prone story where my entry CPP file began with searching
QObjects from the QML engine to establish a connection between my backend and the visual aspect(types) of my app.
At first sight it doesn’t sound bad, but it is. When you use QtQuick/QML (referred from here on as QML) the main idea is to provide a rich dynamic interface and have it all typed up with almost no effort. Yet, one of the questions you always ask yourself is “how to interact with the backend” and in the documentation it explicitly starts talking about finding children in the QML engine root object so you can connect them with your backend.
Depending on the type of your app there’s one huge problem: What if my app is too dynamic and the types/elements of it are always getting destroyed and recreated due to wanting to free memory?
The answer lies within either making the root object a hub of communication OR extending QML with new providers type. If you have read the documentation at some point you will come across an example that starts with creating a QML Type called
Message and that message will provide and contain said message through its usage. After you are done designing the properties and members of Message object in your CPP backend you can register it with
qmlRegisterType. A bit more info here, to those who are interested.
I have found that I have more control making my qml types have states or certain properties that hints the internals of my app of when to do certain things. States in QML helps a lot in that, while it’s commonly used in transition I can also see it as a semaphore to control the flow of how you want to direct the user.
As you saw in the video at the start of this post you can see I’m also using states.
Nothing is certain
Right now there’s just no right way to write your qml files. There’s no “best practices” excluding the memory management part in the documentation as it’s exclusively for memory management. How you lay out the visual objects and how you communicate and bridge it with your backend is up to you. I don’t really know if this is really good or bad, you just have to come up with an “efficient” way of not compromising the performance of your app.
All in all, it’s been a pretty nice experience. I just wish the documentation improved.