Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Highlighted
Contributor
Posts: 30
Registered: ‎05-24-2012
My Device: Developer
My Carrier: Developer
Accepted Solution

Cascades doesn't take advantage of property bindings in all components

I believe that many of the components found in Cascades are incorrectly designed because they don't take advantage of QML's property bindings. The worst example is the ActivityIndicator component which doesn't have a running (or named something similar) property.

 

Let me demonstrate with an example, I'll begin with a snippet which lacks the running property:

 

ActivityIndicator {

    id: indicator

}

 

WebView {

    onLoadingChanged: {

        if (loading)

            indicator.start()

        } else {

            indicator.stop()

        }

    }

}

 

This is not declarative, this is imperative code. Now let's take a look at the following example which shows how it would look like if the ActivityIndicator have had a running property:

 

ActivityIndicator {

    running: webView.loading

}

 

WebView {

    id: webView

}

 

Much cleaner, easier to read and totally declarative. You also get the dependencies between the components right. In the first example, the WebView has a dependency to the ActivityIndicator which is totally wrong. In the last example you see that this time the ActivityIndicator has the dependency to the WebView, which is correct because the ActivityIndicator has a dependency to the WebView and not the other way around.


To make things even worse with the ActivityIndicator-case, is that there is a function called isRunning which returns a boolean if the indicator is running or not. Why isn't that a property?!

 

There's a couple of other components which have similarities with the ActivityIndicator, such as the Slider and TextField. Would be my pleasure to elaborate on them to if you're interested.


Retired
Posts: 2,559
Registered: ‎10-16-2009
My Device: BlackBerry Z10
My Carrier: Bell

Re: Cascades doesn't take advantage of property bindings in all components

Hi there and welcome to the forums!

 

I responded to you on Twitter yesterday, a large number of properties are exposed and can be bound in the manner you explain below. It seems that this case explained in your post does not function this way and I would recommend that you post a new feature request in Issue Tracker (linked in my signature).

 

In the case of Slider and TextField, which properties are you trying to bind which are not functioning as expected?

Garett
@garettBeuk
--
Goodbye everybody!
Contributor
Posts: 30
Registered: ‎05-24-2012
My Device: Developer
My Carrier: Developer

Re: Cascades doesn't take advantage of property bindings in all components

Thanks for following up, you guys do care Smiley Happy

 

I've to apologies if I were a bit unclear with what I wanted to say... I do know that you're using property bindings but I think you're using them a little bit incorrect (or not at all in ActivityIndicator case).

 

The Slider has a property named value. If you bind to this property you'll never get any updates until you have finished editing. If you want to track the Slider's value you have to do it inside the valueChanging signal handler. It works but I still think that the valueChanged should be emitted each time the value changes so you can track changes. If you only want to do something when the user lift his finger from the Slider then you should simply use the 'touchUp' event or introduce a new signal, for example, sliding which tells if the Slider is currently sliding or the user has lift his/her finger.

 

A quick example:

Slider {

    id: volumeSlider

}

 

MyCustomPlayer {

    id: player

    volume = volumeSlider.value

}

 

As it works right know, the code above will only change volume when I lift the finger from the slider, but that's not the expected behavior, at least not if you've been using QML previously with QtQuick. If I want to track changes I've to do following:

 

Slider {

    id: volumeSlider

    onValueChanging: player.volume = value

}

 

MyCustomPlayer {

    id: player

}

 

See, suddenly I don't have a property binding anymore. I can't even tell who's settings the volume on my player without browsing the code. I also need to initialize the player with a volume, for example:

 

MyCustomPlayer {

    id: player

    volume: volumeSlider.value

}

 

But this binding will only be valid until I drag the slider, then the binding will be broken.

 

Yes, it works to do the updates from signal handlers but I think it conceptually wrong in QML. I would like you to consider fixing this before doing the final release.

 

Please let me know what you think.

Retired
Posts: 2,559
Registered: ‎10-16-2009
My Device: BlackBerry Z10
My Carrier: Bell

Re: Cascades doesn't take advantage of property bindings in all components

Yep, we definitely care!

 

With the Slider there are 2 events, valueChanged and  valueChanging, which provide the 2 different functionalities, so it is not expected in this case for valueChanged to send a signal until after the Slider has stopped being changed as the value itself is not changed until the Slider has been positioned, valueChanging does provide this instant feedback. Introducing logic necessary to see if the user has lifted their finger, left the Slider area or otherwise stopped moving the Slider would surely complicate the matter.

 

The next point you bring up is very valid, but with the method used by Cascades, as described above, the value of the Slider is not set until after the Slider is moved and stopped. I would suggest logging anything you see as strange or unexpected behaviour in Issue Tracker as a bug. We can escalate for development to review, this will also let the developers know that the behaviour being used by Cascades may not be what is expected nor in line exactly with QtQuick QML.

 

Regards,

Garett
@garettBeuk
--
Goodbye everybody!
Contributor
Posts: 30
Registered: ‎05-24-2012
My Device: Developer
My Carrier: Developer

Re: Cascades doesn't take advantage of property bindings in all components

Again, thanks for taking your time to give a good answer.

 

Ok, I see. Technically the value property isn't changed while moving the Slider's handle thus no valueChanged signal is emitted. To be able to track value changes Cascades introduces, in this case, the valueChanging signal. For TextField it's the textChanging signal, etc

 

Well, it's a question of design philosophy. As long as this pattern is used for all components where applicable then I guess it's fine. I'll just have to change mindset when doing Cascades instead of QtQuick Smiley Happy

 

Still, adding a running property to the ActivityIndicator would make my declarative heart happy Smiley Happy

Retired
Posts: 2,559
Registered: ‎10-16-2009
My Device: BlackBerry Z10
My Carrier: Bell

Re: Cascades doesn't take advantage of property bindings in all components


marioboikov wrote:

Still, adding a running property to the ActivityIndicator would make my declarative heart happy Smiley Happy


100% agree, especially based on your use case. If you could toss the feature request into Issue Tracker and link back the URL I'll get it escalated right away.

Garett
@garettBeuk
--
Goodbye everybody!
Contributor
Posts: 30
Registered: ‎05-24-2012
My Device: Developer
My Carrier: Developer

Re: Cascades doesn't take advantage of property bindings in all components

Honestly, I've already filed a bug report on this: https://www.blackberry.com/jira/browse/BBTEN-4

 

Retired
Posts: 2,559
Registered: ‎10-16-2009
My Device: BlackBerry Z10
My Carrier: Bell

Re: Cascades doesn't take advantage of property bindings in all components

Thanks Smiley Happy. Looks like the right folks are already investigating it.

Garett
@garettBeuk
--
Goodbye everybody!