09-19-2013 10:41 PM
As above I have 3 QFutures, how to I wait for all 3 to finish before continuing
Currently im using the above, is that correct?
09-20-2013 02:12 AM
09-20-2013 02:24 AM
I need all 3 methods to do thier own processing and the main thread to say something when all is finished, in the mean time, the ui most probably shows one or nothing at all , would slots and signals using futurewatcher be better then? By then again, one watch slots for each future, so how can i connect in a way that something is done when all 3 async futures complete?
09-20-2013 03:06 AM
Yes but you are holding up the main thread at that point if this is what you want to do then fine, I have no idea what your functions do so can't comment on the safety of doing this.
If they are calls to load data for a ListView for example then yes it's better to swap to a mechanism that signals so that the app doesn't stand idle and unresponsive while waiting to load.
09-20-2013 03:16 AM
My functions will do some background processing with no message passing to the ui other then the completion status, i think i will use signals and slots and find some way to connect in a way that something() is called when all 3 functions complete.
09-20-2013 03:27 AM
Again with not knowing what your functions do it's hard to advise.
However I'll try any way.
If these are just status checks then it's probably better to move them to signalling with a QML variable initially set as "undefined" then updated as the processes finish. However you want to display this to the user (e.g. toast, nice graphical image) can then be triggered by that variable changing.
Take a look at some of the BB10 sample apps for good examples on how this is a better approach as it fits in nicely with the methodology behind QML.
09-20-2013 03:36 AM
How would u suggest if my functions perform resource intensive file creation in the backend,. my app is going to be a headless app in the end with seperated ui and logic , now i am now coding out the features with no ui yet, was going to try making it headless after the features (backend functions are working). Didnt want to start a headless app from the start as the samples and docs didnt help much for a use case other then push notification triggered, as my app runs once on every boot, but i couldnt get a test project working so decided to get the features working first. Being new to BB development and coming from Android with simple background processing and intents and simple yet enriching docs, im still trying to cope in this new environment i guess
09-20-2013 04:02 AM
I would strongly advise you think about headless from the start as retro fitting to an app is apparently frought with problems...
Read this article...
Note that you get a limited memory footprint with long running headless of 3Mb and only 20 seconds of processing with trigger headless (which sounds like yours is) will your 3 processes definately finish within that time?