As of iOS 6.0, services and characteristics are cached by the system whenever possible.
There is no need to keep them around between connections - it isn't explicitly supported, and you may be opening yourself to non-obvious issues like them being invalidated underneath you if the remote database changes. On Jun 3, 2013, at 6:01 AM, Steve Childerley < email@hidden> wrote:
Hi Andras, I would prefer not to have to perform this
kind of thing, as I don’t need the security I just want to side effect of
CBService and CBCharacteristics persisting between connections. It wouldn’t
be necessary if they weren’t dealloc’d on disconnect. The
alternative being to rediscover each time – costly and time consuming but
probably the route I will take in the short term. Perhaps persisting, between connections, (not
between instances of CBCentralManager) is functionality that might be added in
a future release? Thanks, Steve.
From:
András Kövi [mailto:allprog@gmail.com]
Sent: 03 June 2013 13:33
To: email@hidden
Cc: Etan Kissling; Rick Mann;
email@hidden Bluetooth
Subject: Re: Can I keep CBService
and CBCharacteristics around?
Hi Steve,
encryption requires paired devices. Pairing is done with the dialog you
mention and your app has no way to dismiss it programmatically. Theoretically
it has to be done only once.
I am, of course, not aware of all your requirements but I'd suggest you
to try to avoid this kind of caching. Leave it up to the system to do it for
you unless you have some performance issue that may be solved in this
way.
Side note: I feel like this is similar to when you want to cache images
but use [UIImage imageNamed:] to obtain them. It may seem to make sense but at
the same time UIImage aready does it for you, so it practically just makes
things more complex without much gain. I haven't done testing as to how much
caching CoreBluetooth does but I feel like this is something that is
necessarily an OS function. On the other hand, people on this list have been
complaining that it does actually cache quite aggressively, which hinders
testing in some cases. All in all, implementing additional caching will surely
make your code more complex (think of handling BT reset, crashes, hidden XPC
errors, etc.) without much practical gain (if any).
2013/6/3 Steve Childerley <email@hidden> Hi Etan,
I am trying to implement your recommendation to Rick earlier in the year.
The aim being simply to "keep CBService and CBCharacteristics around"
between connections.
I have, I believe, set my peripheral (BLE112 from BlueGiga) for encryption
only behaviour, however during the GATT interaction phase of my connection,
the iDevice requests permission to pair with the remote peripheral (via a
dialogue box).
This is something that I believe is not necessary if I simply wish to have
an encrypted link? If response to this dialogue is necessary to proceed, is
there anyway my App and respond to the dialogue - as I don't wish the use to
be aware of it?
Thanks, Steve.
-----Original Message-----
From: bluetooth-dev-bounces+steve=email@hidden
[mailto:bluetooth-dev-bounces+steve=email@hidden] On
Behalf
Of Etan Kissling
Sent: 12 March 2013 10:24
To: Rick Mann
Cc: email@hidden
Bluetooth
Subject: Re: Can I keep CBService and CBCharacteristics around?
Rick,
services and characteristics have to be re-discovered after every connect if
the link is not encrypted.
If encryption is active, you may find cached services / characteristics in
the peripheral's services and
their characteristics. Not sure about it, as I did not test that.
The peripheral object itself can only be reused if you still have the same
CBCentralManager instance.
If you create a new one, you can pass the UUID to retrievePeripherals in
order to get a new CBPeripheral
instance. Note that this does only work for devices that were previously
connected and, therefore, have
a UUID.
Etan
On 12.03.2013, at 07:49, Rick Mann <email@hidden>
wrote:
> If I've scanned for my peripherals, connected, enumerated the services and
characteristics, can I keep those objects around for later reads? What
happens if the peripheral disconnects and reconnects?
>
> --
> 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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
______________________________________________
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
_______________________________________________
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
This email has been scanned by Netintelligence
http://www.netintelligence.com/email
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
|