Unsolved Qt Qml Architecture best practice
-
Hello, I would like to ask what is best practice of creating Qt Qml application?
For example I want to create app which will have 2 pages (search bar, hotel list where you can press on it and read more about it). I will use some rest api to get data and display it (text, images, etc). (maybe google firebase if I found some plugin)Should I try to write code based on MVC principles? Or it's better to use FLUX?
Should I write all code i Qml or just UI and http calls, data model etc handle in the C++? That way I have to call qml from c++ and vice versa. (engine->rootObjects().at(0)->setProperty(), QMetaObject::invokeMethod(), Q_INVOKABLE, Q_PROPERTY etc)
I have written some Qml apps and I would like to find out the most decent way to do it, because I had issues when some data do not update, I need manualy rerender qml UI; or using global variables (declared in main.cpp) in the several qml files; or handling some 'code problems' in c++ code and some 'code problems' in javascrip (which I suppose is bad practice).
P.S. I know there is a framework called FELGO with focus more on mobile app development, but I would like to build app using only Qt because it's free.
P.S.S. I watched this FELGO course on Udemy and the teacher build Qml architecture inspired by Flux principles.
-
@Mantas-Kast said in Qt Qml Architecture best practice:
Qt because it's free.
It is not free on mobile platforms ;-) It's hard to satisfy LGPL requirements here, especially on iOS.
Should I try to write code based on MVC principles? Or it's better to use FLUX?
Should I write all code i Qml or just UI and http calls, data model etc handle in the C++? That way I have to call qml from c++ and vice versa. (engine->rootObjects().at(0)->setProperty(), QMetaObject::invokeMethod(), Q_INVOKABLE, Q_PROPERTY etc)
Usual recommendation is to use QML for UI only, and code all the logic in C++. There is no need to call QML directly like you show, you can add some "communication" objects to root context property of QML engine and then it is visible from both C++ and QML (where it can be interacted with directly or via Connections element).
-
@sierdzio said in Qt Qml Architecture best practice:
Usual recommendation is to use QML for UI only, and code all the logic in C++. There is no need to call QML directly like you show, you can add some "communication" objects to root context property of QML engine and then it is visible from both C++ and QML (where it can be interacted with directly or via Connections element).
Can you give an example?
-
-
@sierdzio Thanks. I know both examples. but when project goes bigger that "backend class" is going to be huge and I think you can't register several classes to qml (via qmlRegisterType).
-
@Mantas-Kast said in Qt Qml Architecture best practice:
you can't register several classes to qml (via qmlRegisterType)
Nope, there are only physical limits
-
You can register multiple classes, and you can add multiple context properties, too.
-
@Mantas-Kast It's kind of an old topic, but I am curious. Have you found a satisfactory answer to your topic by now?
Imo, FLUX/FELGO are the best practices for qml architecture. There should be a global "store" and global "actions". It allows you to change your UI quickly without any pain.
Calling qml from c++ should be done via Connection where target is your C++ object and your UI "action" is called.
Calling C++ from qml should be done via C++ object, defined in setProperty in qmlEngine.