How is iOS's support for BLE write request?

[Mitch996]

A little background with this question

So, long story short:

To send data using notification, in android, you must first enable CCCD descriptor of matching attribute (which is usually a characteristic)

The proper way to do that is using some sort of "write request".

Problem: it is often confused with "write".

Now you are asking: then use "write request"? Here's the problem: official android API does not support write request, it only has "write".

Now again you are asking, then override some parent method/class and use "write request" afterwards? Here's another problem: you can, but you would be using a different android library/bluetooth framework, a non-official one which is prone to problems OR you will have to tap right into some lower level android properties, which may or may not be legal, and usually is very, very complicated.

So here I'm trying to ask, does iOS have the same problem? Does it distinguish "write" and "write request" per ble specs well?

[RK]

I'm pretty sure you are still barking up a very wrong tree. Android phones have been successfully subscribing to notifications since CCCDs existed and they've been doing it on stock android OS and with stock android code. If android phones en-masse weren't able to subscribe to notifications, someone would have noticed.

The only difference between write requests and write commands is the fact or not of a response. So any write effectively works as well as any other, it writes the characteristic. And doesn't android, vile little phone os that it is, have a setWriteType method to specify what kind of write it's going to do on that characteristic the next time you write it? iOS has two methods for writing, same effect, different approach.

I'm fairly sure the problem you've been struggling with for weeks has nothing to do with this.

[Mitch996]

@RK I'm not sure when you started approaching this issue but it seems that you either don't have any contextual background information on this problem, or you do but no complete.

I successfully sub-ed CCCD before, with a different softdevice (S110). Now I'm using S140, which according to Nordic staff, correctly corrected a non-BLE specification compliant behavior and as the result I'm now not able to subscribe to CCCD. And in both debug mode and sniffing, ample evidence points to the direction that A. both write types are ignored by the softdevice and B. no matter how I juggle the setWriteType method, the packets send over the air will be displayed as write no response, in my previous question, referred to in this question, screen caps were presented to demonstrate that.

And I'm almost certain the nRF Toolbox is using a different library than the official one, (continued)

[Mitch996]

Because there are (likely compiled) packages that doesn't appear to belong to official android API library, and I cannot access them in my IDE (android studio), while I can with official APIs (not the exact implementation and codes, but at least java's equivalent of C's declaration)

[run_ar]

@Mitch996, Did you see this question? Edit: Yes, you did. I'm sorry, looks like you have to wait for a new version of S140. I'm afraid I don't know the release schedule for that right now, but you can ask our RSM for details on future products.