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

Posts: 82
Registered: ‎01-11-2013
My Device: DevAlphadevice
My Carrier: rim

How to use threads

Hi all,


Suggest me any sample for using threads in cascades app .

Posts: 1,524
Registered: ‎12-18-2012
My Device: Z30, Z10 LE, DevAlpha C, PlayBook

Re: How to use threads

[ Edited ]




p.s. Cascades forum section is better for this question.


Andrey Fidrya, @zmeyc on twitter
Posts: 47
Registered: ‎04-19-2013
My Device: I love them all!
My Carrier: Carriers rock!

Re: How to use threads

My general guidance to most teams is "don't".

However, if you really do feel you need to use multiple threads in your application, I would strongly encourage you to look at QtConcurrent::run() to offload your task and get notified when it completes through the returned QFuture with a QFutureWatcher.
Posts: 40
Registered: ‎05-14-2013
My Device: Z10
My Carrier: none

Re: How to use threads

I don't really understand why you would not suggest mult-threading. Using Qt this is much easier and much less of a pain than in most.


I suggest reading some docs on the Qt way of threading, which is fully supported in cascades.








Something mentioned in there that I want to stress is important; you should practically never inherit from QThread. You use threads, you don't want to inherit from them. See the first doc Smiley Happy


Posts: 47
Registered: ‎04-19-2013
My Device: I love them all!
My Carrier: Carriers rock!

Re: How to use threads

It's not that multi-threading is inherently wrong or anything, it's just that many people don't really appreciate just what can go wrong when using lots of threads.  If someone isn't very concerned about using threads I would argue they don't really understand the concepts well enough.


For the most part, people tend to just have some long-running method they want to offload from their event thread and QtConcurrent::run()/QFutureWatcher does the job very nicely.


Also, many people unnecessarily involve additonal threads because they don't really understand the options available to them. For example, I have seen many people spin up a thread to run a BPS event loop, despite this conflicting with the Qt event loop already pumping BPS, and the framework having AbstractBpsEventHandler built-in for their convenience.


If you are comfortable with QThread, QMutex, locking, etc, then go for it.  Just stop and really think about why you need/want to do this.  That's why I said that I generally tell teams "don't".