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
Developer
BBSJdev
Posts: 6,118
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Live QML coding

I know a lot of you read the blog but I thought it worth highlighting here as well for those that don't.

 

It's simple to do and depending on how much of your UI is in QML can be a real time saver.

 

http://devblog.blackberry.com/2014/01/live-qml-coding-is-finally-here/

 

No more rebuild and reload. :Rockon:


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Developer
greenmr
Posts: 919
Registered: ‎03-20-2013
My Device: Red LE Developer Z10

Re: Live QML coding

I was excited when I first saw this on the BlackBerry Developer Blog, but after trying it I was underwhelmed. It is a neat trick, but it has several issues that make it more of a novelty than a useful tool for anything but the most simple QML apps.

 

  1. Only works with 10.2 SDK or higher. This is a problem since most of us are still forced by the slow OS update rollouts to target 10.1, and possibly even 10.0. If you do decide to use it you have to wrap the whole thing in #ifdef blocks then do your development with a 10.2 SDK before switching to an earlier SDK before releasing. Doable, but definitely awkward.
  2. Although the DevelopmentSupport::assetsChanged() signal takes a QUrl parameter, this appears to be always set to "asset:///main.qml", which is a problem if your top-level QML file has a different name (like mine does). I'm not sure what the point is of a signal parameter that always has the same value. Of course, again there is a workaround, you can ignore the parameter in your slot and hard code the QmlDocument::create() call with the actual name of your main QML file.
  3. Now we get to some more serious issues. Every time you update any QML file, this technique reloads the scene graph, but it does so from the root (your top-level QML file) and jumps you back to your opening page. This makes it very frustrating if the QML you are tweaking is several levels deep in the heirarchy since every time you change its QML you will have to navigate back to the one you are interested in to see the effect.
  4. The biggest issue is that when the QML is recompiled and redisplayed, none of the app statup code is executed at the same time. If all your QML is static this is not a big deal, but if some of the elements on your pages are generated dynamically, populating DropDowns, for instance, your reloaded UI will have empty DropDowns. If navigating to the page you are tweaking requires any of these dynamically created elements to get to them, then you won't be able to see your changes anyway. In some cases you can put code in your assetsChanged() handler slot to repopulate everything, but often this will be difficult or impossible if major startup code needs to be invoked to do it.

This is a very interesting idea, and it will work well in simple projects, and even in the early stages of complex ones, but if you want to tweak a page deep in the heirarchy or that requires lots of dynamic configuration, this is probably more trouble than its worth.

 

Kind of like the singing dog that sounds terrible but is amazing because it sings at all.



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.
Developer
BBSJdev
Posts: 6,118
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Live QML coding

[ Edited ]

I'm going to disagree with you, I think you are being way too harsh.

 

Saying that it's more trouble than it's worth when it only takes two minutes to implement and then allows you to quickly make design changes on the fly removing the need to rebuild and reload everytime will save me and I bet plenty of others a load of time.

 

For those of us who care about the design of our app and not just display multiple ListViews :Devil2: (I jest) and spend hours tweaking every little control so it looks just right this will save a huge amount of time.

 


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Developer
BBSJdev
Posts: 6,118
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Live QML coding

I was going to go through your 4 points as well but I think you are clever enough to know that if these are issues for you you can write code that hooks off the signal to solve 3 out of 4 of them fairly easily.


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Developer
greenmr
Posts: 919
Registered: ‎03-20-2013
My Device: Red LE Developer Z10

Re: Live QML coding

I knew you would. :smileywink:

 

Yes, you are right, there are workarounds for many of the issues I raised, but I think the Dev Blog article blithely implies that implementation is trivial, whereas this in only true in the simplest of applications.

 

After my earlier post I realized there is another issue that complicates matters even further. When your QML changes and the scene is reloaded, only the UI and any ECMAscript code is changed. Most non-trivial apps will do things behind the scenes as you change screens, changing the "state" of the app. When this trick reloads the scene, only the UI is updated, the application "state" remains the same. If ALL your code is in QML then this probably won't matter since all your initialization code will run again, but if you only use QML for a few screen layouts, then you may find that the UI expects your app to be in a state which it is not. This means you are going to have to write code in your assetsChanged() handler to set the app state back to the way the main page expects it. Among other things this could involve freeing up worker objects you don't need, closing Internet connections, and settings global variables to reflect the current app state.

 

Here a simple example from my multiFEED app, which has context-sensitive help. As the user navigates around the application, a global variable is set the tells the help system which html help page to open if the user taps the help button. This is a trivial example just to show what I mean, and it is easy to remedy just by resetting the value in the assetsChanged() handler, but the point I am trying to make is that contrary to what is implied by the blog post, you probably aren't just going to be able to plug the sample code into your app and have it operate as you expect. You are going to have to completely reset your app to initial conditions in your assetsChanged() handler or your UI is going to be out of sync with the app itself. Depending on the structure of your application this may be more trouble than the benefit this technique provides.

 

As you said most of use don't spend hours tweaking page layouts ad-nauseaum, so I still stand by my original assertion that this trick is less useful for most developers than it promises to be.



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.
Developer
BBSJdev
Posts: 6,118
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Live QML coding

Okay, well perhaps we'll see TAT address some of the points you raised in later iterations.

Maybe you are right and I am in the minority of those developers who want to get the layout perfect and so spend a lot of time tweaking, personally for me I will find it useful and time-saving.

If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Developer
BBSJdev
Posts: 6,118
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Live QML coding

Thanks for your comments by the way, in all seriousness, I'm sure other developers will also benefit from your response on this.

If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Developer
greenmr
Posts: 919
Registered: ‎03-20-2013
My Device: Red LE Developer Z10

Re: Live QML coding

Actually I'm pretty fanatical about page layouts too... I've been known to obsess over a one-pixel difference in spacing between controls. I think the difference between us is probably just workflow, and perhaps the way I architect my applications. Although I work out page layouts early on in a design project, experience tells me I'm probably going to change it multiple times before I'm done, so I always wait to fine tune till one of the final tasks before a release. My own experience with this dynamic QML trick is that it is awkward to use with the way I write apps. For other devs my complaints may not be important.

 

Despite my harping, I actually think this is a pretty cool trick. I just wish it was a little better implemented than it is, and I wish BlackBerry hadn't promoted it as trivial to implement, since I really believe that is only true for trivial applications. I still don't see the point of a signal argument that always has the same value, but perhaps there are plans for a more powerful version of DevelopmentSupport in the future that will make better use of this argument.


BBSJdev wrote:
Okay, well perhaps we'll see TAT address some of the points you raised in later iterations.

Maybe you are right and I am in the minority of those developers who want to get the layout perfect and so spend a lot of time tweaking, personally for me I will find it useful and time-saving.





Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.
Developer
greenmr
Posts: 919
Registered: ‎03-20-2013
My Device: Red LE Developer Z10

Re: Live QML coding

Although it may have seemed otherwise, I wan't intending to dissuade others from using this technique, just pointing out that it isn't quite as simple as the devblog tried to make it seem, and that it may not be suitable for all applications or developers. I guess my expectations were unrealistically high. In the process of talking about it here I have had some ideas that will likely make it more useful to me. In particular I realized that the biggest issue is that you have to make sure that when you update your QML and the scene is reloaded in your signal handler, it is critical that your app be reinitialized to the same state as the UI component will be after the reload. Although the design on my app makes this difficult, it is not impossible. I'm going to play with the code in my signal handler and see if I can make it play nice.


BBSJdev wrote:
Thanks for your comments by the way, in all seriousness, I'm sure other developers will also benefit from your response on this.





Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.