Re: Any better solutions to BLE caching?
Re: Any better solutions to BLE caching?
- Subject: Re: Any better solutions to BLE caching?
- From: Rick Mann <email@hidden>
- Date: Fri, 19 Apr 2013 14:07:22 -0700
On Apr 19, 2013, at 02:36 , Etan Kissling <email@hidden> wrote:
> Excerpt from https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
> The iOS device implements the GAP Service Changed characteristic, because the database contents can change at any time. The Bluetooth accessory should therefore support the Characteristic Value Indication of this characteristic and, upon receiving indications, invalidate its database cache accordingly. See the Bluetooth 4.0 specification, Volume 3, Part G, Section 7.1.
Hmm. That excerpt seems to say that the *accessory* needs to respond to the indication by invalidating its own caches, rather than saying iOS will do the same thing.
> Did not test this, but if it works, you should get a callback in the CBPeripheralDelegate (didInvalidateServices or something similar).
So, there's no such delegate method, but I think the thing to do is get the value change indication for that specific characteristic. I'll try to implement that, and hopefully the caching won't prevent that characteristic from showing up.
Actually, huh. I only change the service when I flash the BLE112, so I don't know how to properly send the update, without sending it every time the thing boots.
--
Rick
_______________________________________________
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