QML Property Bindings vs: States
-
Hi all
I have a software engineering question:
For the past few weeks I have been working on an app for my Nokia N9 in order to learn QML. At the heart of the app is a GPS element.
The GPS can be either on or off. Depending on this "state", at least 5 child / sibling elements change their appearance. e.g buttons and menu items change from active to inactive, labels change colour etc.
In my first implementation I achieved this via 2 states, which changed the element properties via PropertyChanges elements.
However today it has occurred to me that I could achieve the same effect by using property bindings in the child / sibling element properties - binding these to the GPS elements "gpsOn" property.
Both of these approaches work. The question is, which approach is better from an software engineering point-of-view, and why?
Do I give central control to a QML State, which then needs to know about a list of element properties, or should each element have control over its own properties by binding these to the GPS element as required?
In my example the state model is simple - only 2 states (on and off), and the elements that need to change their properties are by their very nature closely coupled to the GPS element.
Your thoughts are welcome.
Chris
-
Both approaches are fine but as complexity or number or dependent elements increases I would lean more towards states as this gives a nicer abstraction IMHO and allows you to see the logic in one place.
If the complexity increases further still I would take a look at using a state machine in C++ (QStateMachine and friends), exposing some facade object that exposes parts of the state machine's state to QML and using QML bindings or QML states to have the C++ state machine control your UI.
-
Hi Zap
Thanks for the answer - sorry it has taken a few days for me to get back, have been changing projects in my day job.
Basically you have confirmed my own thinking on this issue, but I did not want to preempt the discussion in any way.
I also liked the point that using states "puts all the logic in one place". In the case of my app the state is simple "on / off", so adding a state might be a little overkill (just a whiff of cargo cult programming ...), but were the number of states to increase, the case for using states rather than "bindings with logic" would become all the more compelling.
Grüsse
Chris