Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
C++/QML General Application Design
GGenny last edited by
sorry for my bad english. I'm developing a mobile application for several months. The size of the application are becoming "important," and it is necessary to review the design choices before continuing.
My current goals are:
QML (graphics) will manage only the graphical aspects and should not have any knowledge of the business logic. It must be possible to test QML without business logic.
C ++ (business logic) no knowledge of the graphic, it must be possible to test the business logic without QML.
For communication between the two sides I'm using simple signals and slots:
C ++ emit signal -> doAnimation
QML call signal -> doAnimationComplete
a third part connect C ++ and QML.
This type of design is very easy to test, everything is independent but ... I have to make a massive use of QEventLoop. An example:
The user needs to update the data:
QML call signal -> updateDataRequest
C ++ emit signal -> showWait
C ++ create a thread to read data ...
C ++ read data ...
C ++ emit signal -> updataData (data ..)
C ++ emit signal -> hideWait ();
C ++ thread end
Signals being organized under an arbitrary order, I could find the signal hideWait be completed before UpdateData.
I need to use QEventLoop in C++ thread to wait updateDataComplete.
This is a small example (which is easily solved by placing hideWait in updataDataComplete slot, which is, in any case, a bad solution since it constrains the response with an action), and in more complex examples the use of QEventLoop become verbose, especially if the graphics are very complex to update.
One solution would be to use a state machine to handle the request, the problem is that I avoid using QEventLoop but beginning to create sequences of threads to handle asynchronous operations.
Another solution is to avoid having n separate signals, but having only one signal for comunicate with QML, the type doUiEvent ("ShowWait"), so that the signals are executed in order, and put a fake event completion, the type doUiEvent ("notifyCompleted") to report graphical update.