Hi Roland and Andrew,
I’m sorry to dig this one up again after so long, but I just wanted to thank you both.
First, because Andrew brought up the question that I was wondering about this week:
“Is it OK to use the main queue when instantiating a Central Manager or is it a best practice not to use it?”
…and then for Roland’s answer, which I found very helpful:
The rule is "don’t block the main queue", not "don’t use the main queue”.
Therefore, it sounds to me like it’s OK to instantiate the Central Manager to use the main queue, _as long as it doesn’t get blocked_ -- so I guess a follow-up question would be to ask if there are concrete examples or circumstances in which the main queue could be blocked?
Obviously, it’s simpler if we keep it on the main thread, but I also want to keep the app responsive. So would one strategy be to test with the device in question using the main queue and see if one has problems — and if so, then move it to another queue?
Just curious about the use case here. Things are getting a bit more serious lately in my world as respects BLE and Core Bluetooth, so I’d like to know what best practice is in this scenario if one exists. :)
Thanks Again!
Evan K. Stone | Senior iOS Developer | Cloud City Development | San Francisco, CA
On Jul 21, 2015, at 1:44 AM, Roland King < email@hidden> wrote:
.. trimmed .. re-sent .. not sure how that became 24kB …
Well it all depends what you want to do really.
If your BTLE callbacks mostly end up with something being changed in the UI, and they are quick to execute, then running them on the main queue is fine, you’re going to have to bounce the UI updates to that queue anyway. The rule is "don’t block the main queue", not "don’t use the main queue".
The original code you posted is possibly a little odd, but it’s not entirely stupid. (that’s the code which sets up a queue targetting the main queue). The queue is named, which means you can track it easier in the debugger, if you decide later you want to use a background queue instead, you just switch the target. You can also suspend and resume that queue if for some reason you wanted to temporarily stop receiving BTLE callbacks.
I have no idea why it’s written like that - perhaps looking at the rest of the code might yield some places it does something specific with that queue, like suspend, resume or re-target it.
Hi Thirumalrao,
Thanks for you response but the code is exactly what I posted. Your code will also execute BLE actions off of the main thread - the merits/demerits of this was the essence of my question.
Kind regards,
Andrew Coad
|