The Following User Says Thank You to rash.m2k For This Useful Post: | ||
|
2012-12-03
, 11:29
|
Posts: 85 |
Thanked: 38 times |
Joined on Sep 2010
@ Canada
|
#2
|
|
2012-12-03
, 11:36
|
Posts: 642 |
Thanked: 486 times |
Joined on Aug 2008
|
#3
|
I would also rather if the models used by QML views were all created and manipulated in Qt. I fetch the data and manipulate it on the Qt side and then pass them to QML as arguments of signals. I wish things were simpler and that QML was extracted away from all logic as you're suggesting.
The idea is of-course as I'm sure most of you are aware - is how do I design my application so that its:
1) Design is clear
2) Easy to understand (and picture in your mind)
3) Easy to extend
4) Flexible.
5) etc etc.
Ideally I'd like this thread to be the collective knowledge and experience of some of the dev's here about the routes they have taken and why, and what they liked/disliked about it. So here's what I propose, each reply must include the following:
1) What language/techonology you are using (mostly QML + Qt I would expect)
2) ONLY in terms of design/architecture/modelling what was easy/difficult/a pain in the ***.
3) A good design pattern (or something similar) that you think would be perfect for your app, or what you would have done differently.
I'll start with mine (meebay app):
1) Using Qt + QML
== Qt ==
Advantages:
Using Qt as the backend tech is great actually, it follows logically, since I call c++ code as well (generated from multiple WSDL files), it is quite nice as each peice of functionality on the screen is wrapped behind a single Qt wrapper class. Qt is fast and the QHash and other Qt classes are great.
Disadvantages:
Interacting between the different wrapper classes is tricky, but not an enourmous pain. Using custom list models is also a pain as the wrapper class has to interact with the model class.
Overall I like Qt - I don't get ****!ng random segfaults with Qt, I get a real message, C++ is just messed up ;-)
== QML ==
Advantages:
Easy to create GUI, animations, a natural MVC pattern, export directly from Photoshop to QML (have yet to try this), love the onXXX property binding.
Disadvantages:
The BIGGEST issue I have is controlling the loading of objects, EVERYthing gets loaded on startup unless it's put inside a loader object, which is a pain (how do I set a property on this newly created object?). Managing state is tricky, for example the user clicks on a list view item which opens a new page - so I put the page in a loader object (don't want each ListDelegate to create a new 'Page' do I!), BUT i need to tell the page what the item ID that the user clicked.
Connecting signals from QML to Qt is not possible - you need a wrapper method that actually emits the signal for you.
** Overall I find accessing properties/values from one page to another is problematic. **
What I would have done differently:
QML controls the application flow (QML opens/closes different pages, loads different elements), but also stores state (like the listview id the user clicked on). I think this needs to be switched so Qt controls which page to open/close and also store the state so it can be passed around.
So fire away people I'd love to hear how you architectured your application.
Checkout my new eBay app for the N9