|
It’s not necessary to respond from inside the CBPeripheralManagerDelegate callback. You can also pass the request through some
dispatch queues and handle it later, but communication will be stalled. After 10 seconds or so, if no response is sent by the application,
the link is terminated and some arbitrary values that happened to be in memory are shown to the central as error code.
What you could do is to return a success error code to the first write request, and then after the write commands send a final request
with response to gather the response of the GATT server. This is an API change to work around iOS limitations, as your originally
described scenario is currently not possible to implement.
The Bluetooth spec also doesn’t provide any guarantees that your scenario might work, but it also does not prohibit your idea from working.
Etan
You use the CBCharacteristicWriteWithResponse flag. It blocks all communication until the server sends some response. This
is probably a consequence of the way the API is designed: all requests must be responded inside the appropriate callback on the peripheral manager side. There is no way to defer processing or send response later.
Actually, this is something that may require some adjustment on the API side as there are cases when the response is ignored by the framework which causes disconnection. Also, your use case is clearly
not supported currently.
Regards,
Andras
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|