• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Any better solutions to BLE caching?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any better solutions to BLE caching?


  • Subject: Re: Any better solutions to BLE caching?
  • From: Etan Kissling <email@hidden>
  • Date: Fri, 19 Apr 2013 21:27:37 +0000
  • Thread-topic: Any better solutions to BLE caching?

Rick,

just hit the send button too early.

As you mentioned, the excerpt describes the scenario in the other direction. 
However, I think that it may also work in the direction when the accessory
takes on the peripheral role.

Etan

On 19.04.2013, at 23:25, Etan Kissling <email@hidden>
 wrote:

Rick,

the accessory cannot respond to indications, but has to send them ;-)
iOS does the job on the remote side, so it receives the indication when
it is connected and your accessories emits the indication.

The callback is in CBPeripheralDelegate:
/*!
 *  @method peripheralDidInvalidateServices:
 *
 *  @param peripheral The peripheral providing this update.
 *
 *  @discussion This method is invoked when the @link services @/link of <i>peripheral</i> have been changed. At this point, 
 * all existing <code>CBService</code> objects are invalidated. Services can be re-discovered via @link discoverServices: @/link.
 */
- (void)peripheralDidInvalidateServices:(CBPeripheral *)peripheral NS_AVAILABLE(NA, 6_0);


On 19.04.2013, at 23:07, Rick Mann <email@hidden>
 wrote:


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

References: 
 >Any better solutions to BLE caching? (From: Rick Mann <email@hidden>)
 >Re: Any better solutions to BLE caching? (From: Gareth MacLeod <email@hidden>)
 >Re: Any better solutions to BLE caching? (From: Etan Kissling <email@hidden>)
 >Re: Any better solutions to BLE caching? (From: Rick Mann <email@hidden>)

  • Prev by Date: Re: Any better solutions to BLE caching?
  • Next by Date: Re: Any better solutions to BLE caching?
  • Previous by thread: Re: Any better solutions to BLE caching?
  • Next by thread: Re: Any better solutions to BLE caching?
  • Index(es):
    • Date
    • Thread