Hi Jason,
If you look up the archives, I think I was among the first ones (maybe the very first) who asked about it. I understood that it was pretty hard to get right but I got the feeling that it wasn't considered important enough, too.
Well, you had it right up to this point - I'm not sure who told you that :)
To be precise, the rest of the mail is also correct, only this sentence just shows that I'm sadly not part of the Apple CB team...
For background: I see that it is practically impossible to tell from a connecting client whether it is connecting to my service or to some other app's service until there is no interaction in this respect. The first interaction that is an indicator of the relation is the subscription or read/write request. Therefore, there is no point in making apps aware of connected clients that have nothing to do with its provided services. Disconnection is another story. Once the first interaction happened, the associated apps may be notified of the disconnection. This can be important if there is no subscription that would be automatically cancelled and the peripheral needs to keep a list of the connected centrals for some reason.
But as you suggested if someone has good use cases, then they can let you know about that in a bug report.
Regards, Andras András has got it pretty much right. You didn't mention what you're trying to do, but hopefully you can use the subscription and/or read/write events to drive it.
However, the developers later decided that this interaction is not important for most apps, thus, they have been removed from the final CB stack.
Well, you had it right up to this point - I'm not sure who told you that :)
Simply put, these APIs were pulled because we could not find a good way to fulfill the spirit of the contract that they represent. On a peripheral device with an abstracted GATT database being shared among multiple applications, the concept of providing useful "connection" notifications isn't as cut and dry as you might think.
Ultimately, we decided that the the majority of use-cases could still be achieved via the other CBPeripherlManagerDelegate methods, so we decided to not implement the connect/disconnect events. As always, if you have a use-case that isn't doable with the current API and/or policy, please let us know by filing a bug.
On Jun 10, 2013, at 3:14 AM, András Kövi < email@hidden> wrote: Hi Fred,
there used to be callbacks on the peripheral manager for this purpose, they are actually mentioned in the WWDC2012 presentations. However, the developers later decided that this interaction is not important for most apps, thus, they have been removed from the final CB stack.
You can register the clients in the subscribe and unsubscribe callbacks and this in for is also available if there is a write request or read for a dynamic attribute. This is all you have at the moment.
Andras
|