Support for permissions and pairing pop-ups

[ovenham]

When developing apps with pairing flows it's critical to be able to take into account the effect of these pop ups on the user experience. For example CB does not give any indication that a permission or pairing pop up is visible. For the pairing pop up specifically, it does not even tell you if the user rejected it, pairing simply fails with some obscure insufficient encryption error.

Being able to simulate this behaviour with the mocks will make it easier to develop the UX for these scenarios without a real device.

[philips77]

Hello,
Thank you for your feedback.
Regarding the first screen, there is CBCentralManager.authorization, which returns .denied or alwaysAllow. You'd also get the state of the manager changed to .unauthorized.
But with the bonding request, you're right. I forgot about that case. But that could mean, that some callbacks in CBMPeripheralSpecDelegate should be asynchronous, meaning should return the value with a callback, not as return, to allow arbitrarily long delays without blocking UI. And there's a question, should the lib display the popup or just emulate it's effect.

I'll think about it. But the next release of the lib isn't planned this year, i need to transition to other projects now.

[larsamannen]

The possibility to set encryption on read/writes or subscriptions on values changes would be a nice enhancement since many peripherals utilise that.

[philips77]

Hi @larsamannen,

I've just noticed your message. Encryption is transparent from the app perspective. Apps just send and receive values, which are or are not encrypted on lower layers. On iOS you don't know whether the device is bonded or not, there's no API.

And regarding subscriptions for value changes, it is already there. You may call setNotifyValue(true) to enable notifications and you may trigger them using CBMPeripheralSpec.simulateValueChange(...).

[larsamannen]

Thanks for the answer.

Then this is all a lower layer thing in CBM which can't be controlled by the mock.

Hi @larsamannen,

I've just noticed your message. Encryption is transparent from the app perspective. Apps just send and receive values, which are or are not encrypted on lower layers. On iOS you don't know whether the device is bonded or not, there's no API.

And regarding subscriptions for value changes, it is already there. You may call setNotifyValue(true) to enable notifications and you may trigger them using CBMPeripheralSpec.simulateValueChange(...).