Are QTquick apps on android multi-threaded?
-
Hm, in that case either rewrite the C code so that is fits into singals-slots paradigm of Qt, or run the C code in a separate thread. Both solutions should allow you to keep the UI responsive while getting your "wait for signal" functionality.
-
OK I used the QThread controller/worker example (http://doc.qt.io/qt-5/qthread.html) as a model. The worker provides the interface to my C-code and the controller receives the notification signal from my BLE service.
Since the worker can't handle incoming signals, I created a global data buffer (quint8 *) and a QMutex to pass data from controller to worker. It works like this:
- Worker locks the mutex
- Worker sends "write" signal to controller
- Controller receives response signal and copies response data into global data buffer
- Controller unlocks the mutex
- Worker sees unlocked mutex and reads data
Does this sound thread-safe? I ask because it works most of the time, but my worker occasionally gets stuck waiting for the mutex. I need to verify that it's not my controller dropping a BLE response notification.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
-
OK I used the QThread controller/worker example (http://doc.qt.io/qt-5/qthread.html) as a model. The worker provides the interface to my C-code and the controller receives the notification signal from my BLE service.
Since the worker can't handle incoming signals, I created a global data buffer (quint8 *) and a QMutex to pass data from controller to worker. It works like this:
- Worker locks the mutex
- Worker sends "write" signal to controller
- Controller receives response signal and copies response data into global data buffer
- Controller unlocks the mutex
- Worker sees unlocked mutex and reads data
Does this sound thread-safe? I ask because it works most of the time, but my worker occasionally gets stuck waiting for the mutex. I need to verify that it's not my controller dropping a BLE response notification.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
@kgregory said in Are QTquick apps on android multi-threaded?:
Since the worker can't handle incoming signals
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Does this sound thread-safe?
You can verify that with thread sanitizer. I don't want to claim anything here, threads are a sensitive topic, I can easily claim something that is not true.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
That's planform-dependent, but can be done, sure.
-
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember? This is the whole reason I had to spawn a separate thread.
That's planform-dependent, but can be done, sure.
awesome, thanks!
-
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember? This is the whole reason I had to spawn a separate thread.
That's planform-dependent, but can be done, sure.
awesome, thanks!
@kgregory said in Are QTquick apps on android multi-threaded?:
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember?
The signal will get into your thread's event loop queue and wait there until your C code finishes - then it will be processed. I think so, at least ;)
-
I have another question, is it possible that the QThread that I created in order to solve this problem may be recognized as a debugging feature by google play?
Google play isn't allowing me to upload my release build because it says it is "debuggable". See this thread for more detail: https://forum.qt.io/topic/84155/trouble-building-a-release-copy-for-android
-
I think you have not signed your .apk with the developer certificate, that might be the reason.
-
Hi,
Take a look at the Publish to GooglePlay chapter of Qt's documentation.
