01-10-2014 10:04 AM
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.
No more rebuild and reload.
01-11-2014 12:36 PM
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.
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.
01-11-2014 12:53 PM - edited 01-11-2014 01:03 PM
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 (I jest) and spend hours tweaking every little control so it looks just right this will save a huge amount of time.
01-11-2014 12:57 PM
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.
01-11-2014 01:47 PM
I knew you would.
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.
01-11-2014 03:55 PM
01-11-2014 04:00 PM
01-11-2014 05:10 PM
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.
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.
01-11-2014 05:18 PM
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.
Thanks for your comments by the way, in all seriousness, I'm sure other developers will also benefit from your response on this.