Re: Save CBCharacteristic to NSUserDefaults
Re: Save CBCharacteristic to NSUserDefaults
- Subject: Re: Save CBCharacteristic to NSUserDefaults
- From: Etan Kissling <email@hidden>
- Date: Wed, 17 Apr 2013 18:53:30 +0000
- Thread-topic: Save CBCharacteristic to NSUserDefaults
William,
there's not much information about this from the official side. Therefore, I would assume
that the behavior you describe is intended.
I don't think that it is a bug that the error codes trigger different schemes ;-) both seem to
be tailored for their corresponding use case.
Note that CoreBluetooth isn't exactly standards conform at every edge, and this seems to
be such a case, as the Core Spec describes more security modes than just
"authenticated pairing" and "unauthenticated pairing". Normally, there is also a way to
initiate pairing from the central, and the automatic handling of the InsufficientAuthentication /
Authorization error codes is completely iOS specific.
Etan
On 17.04.2013, at 20:28, William Henderson <email@hidden> wrote:
> Got it. FWIW, insufficient authentication triggers just a Pair/Cancel dialog whereas insufficient authorization triggers the entire pairing ritual (type in a number, confirm, etc). However, either appears to be enough to get the caching behavior. Hence, if caching is all you want then using insufficient authentication is certainly less of a burden for your users. Can anyone weigh in on if this is intended behavior and/or something that is likely to change?
>
> Thanks,
>
> William
>
>
> On Wed, Apr 17, 2013 at 11:16 AM, Etan Kissling <email@hidden> wrote:
> William,
>
> On the BLE level, InsufficientAuthentication is the correct one to use.
>
> Authorization is handled on a per-application basis and is not defined strictly.
>
> On iOS, it may also indicate that pairing is requested. However, on a different platform, you
> may experience different results.
>
>
>
> See Bluetooth Core Spec V4.0 Vol 3 Part C Section 10.5:
>
> 10.5 AUTHORIZATION PROCEDURE
> A service may require authorization before allowing access. Authorization is a confirmation by the
> user to continue with the procedure. Authentication does not necessarily provide authorization.
> Authorization may be granted by user confirmation after successful authentication.
>
> Etan
>
>
>
> On 17.04.2013, at 20:08, William Henderson <email@hidden>
> wrote:
>
> > Interesting. In my testing they both trigger a pair, but maybe that's not intended?
> >
> > William
> >
> >
> > On Wed, Apr 17, 2013 at 10:59 AM, Arvydas Sidorenko <email@hidden> wrote:
> > > [peripheralManager respondToRequest:request withResult:CBATTErrorInsufficientAuthorization];
> > William, it is CBATTErrorInsufficientAuthentication which triggers
> > pairing on the central and not CBATTErrorInsufficientAuthorization.
> >
> > On Wed, Apr 17, 2013 at 6:44 PM, William Henderson
> > <email@hidden> wrote:
> > > I've tested the described caching behavior and can very that it works on iOS
> > > 6.1.3 but does not on Mac OS 10.8.3.
> > >
> > > As mentioned above, caching happens only for paired devices. To pair, you
> > > need to respond to a write request with an insufficient authorization error.
> > > For example, for an iOS peripheral you would write something like:
> > >
> > > - (void)peripheralManager:(CBPeripheralManager *)peripheralManager
> > > didReceiveWriteRequests:(NSArray *)requests {
> > > ...
> > >
> > > [peripheralManager respondToRequest:request
> > > withResult:CBATTErrorInsufficientAuthorization];
> > >
> > > ...
> > > }
> > >
> > > That will pop up a pairing dialog on the iOS peripheral, after which point
> > > you will be paired. Other than that you don't have to change your code –
> > > just call discoverServices etc as normal and they will respond more quickly
> > > (ie instantly).
> > >
> > > William
> > >
> > >
> > > On Wed, Apr 17, 2013 at 3:17 AM, Etan Kissling <email@hidden> wrote:
> > >>
> > >> John,
> > >>
> > >> nope, i haven't tested caching / encryption yet.
> > >>
> > >> Etan
> > >>
> > >> On 17.04.2013, at 09:48, John Earl <email@hidden> wrote:
> > >>
> > >> Etan,
> > >>
> > >> This discussion seems to imply that discovered services and
> > >> characteristics can be cached across disconnect/reconnect pairs if the
> > >> application runs continuously in the background, so long as CBCentralManager
> > >> does not power down.
> > >>
> > >> Have you tried this and/or do you use this functionality yourself?
> > >>
> > >> John
> > >>
> > >> On 17 Apr 2013, at 08:14, Etan Kissling wrote:
> > >>
> > >> Jack,
> > >>
> > >> In the mentioned session they explained that characteristics are only
> > >> cached when encryption is on. I haven't tested whether this is true, but may
> > >> be worth trying.
> > >>
> > >> To speed up characteristic discovery, consider lowering the connection
> > >> interval for the first 30 seconds or so from your peripheral. You can do
> > >> this by sending a connection parameter update request.
> > >>
> > >> Also ensure that all your services with 16-bit uuids are grouped at the
> > >> beginning of your peripheral gatt database. This allows to read up to four
> > >> 16-bit uuid services at a time with the default MTU of 23 bytes.
> > >>
> > >> Regarding serialization of cb* objects: it's not possible with public apis
> > >> and even if you could serialize them for nsuserdefaults storage, you would
> > >> still run into problems as the documentation clearly states that all
> > >> peripherals etc are invalidated when the cbcentralmanager state falls below
> > >> a certain level. When you create a new manager, state defaults to "unknown"
> > >> which is the lowest level ;-)
> > >>
> > >> Cheers
> > >> Etan
> > >>
> > >> On 17.04.2013, at 08:34, "Jack Phan" <email@hidden> wrote:
> > >>
> > >> Thank you very much for all your comments.
> > >>
> > >> Jack
> > >>
> > >> On Apr 16, 2013, at 11:28 PM, Andras Kovi <email@hidden> wrote:
> > >>
> > >> Well, if you retrieve or discover a peripheral, then its services will be
> > >> nil. Those are read only from our perspective so there is not even a
> > >> theoretical way to save and then restore the characteristics. Maybe they
> > >> come up with some caching this year (WWDC 2013 hasn't happened yet to my
> > >> best knowledge :) ) but I doubt that as that would introduce a whole bunch
> > >> of issues. Rediscovery is not a big deal, you just have to plan for it.
> > >>
> > >> Cheers,
> > >> Andras
> > >>
> > >> On 2013.04.17., at 8:09, Jack Phan <email@hidden> wrote:
> > >>
> > >>
> > >> I may be wrong but I remember that in Advanced Core Bluetooth session from
> > >> this years WWDC, they said we could catch the characteristics.
> > >>
> > >> Jack
> > >>
> > >>
> > >> On Apr 16, 2013, at 11:06 PM, Andras Kovi <email@hidden> wrote:
> > >>
> > >> Yes, Khaos is right. You cannot save neither the characteristics or the
> > >> services. They must be rediscovered every time.
> > >>
> > >> Andras
> > >>
> > >> On 2013.04.17., at 7:44, Khaos Tian <email@hidden> wrote:
> > >>
> > >> It seems you had to re-discover characteristics every time you established
> > >> a new connection.
> > >>
> > >> Here are threads that discussed this problem previously.
> > >>
> > >> http://prod.lists.apple.com/archives/bluetooth-dev/2013/Mar/msg00032.html
> > >>
> > >> Best Wishes,
> > >> Khaos Tian
> > >>
> > >> On Apr 17, 2013, at 1:25 PM, Jack Phan <email@hidden> wrote:
> > >>
> > >> The reason is that I don't want to scan again. I would like to reconnect
> > >> but don't want to discover characteristics again because it takes too long.
> > >> So when the user opens the app, I reconnect, no discover characteristics,
> > >> but send characteristic values that I had saved to Peripheral.
> > >>
> > >> Jack
> > >>
> > >> On Apr 16, 2013, at 10:14 PM, Khaos Tian <email@hidden> wrote:
> > >>
> > >> sorry for the typo.
> > >>
> > >> I mean why don't you perform a discover characteristics action and then
> > >> use that CBCharacteristic to perform action you want?
> > >>
> > >> Best Wishes,
> > >> Khaos Tian
> > >>
> > >> On Apr 17, 2013, at 1:06 PM, Jack Phan <email@hidden> wrote:
> > >>
> > >>
> > >> Hi Khaos,
> > >>
> > >> Yes. I would like to save CBCharacteristic *myChar into NSUserDefauts and
> > >> then load it when user open the app.
> > >> Thanks,
> > >>
> > >> Jack
> > >>
> > >>
> > >> On Apr 16, 2013, at 10:02 PM, Khaos Tian <email@hidden> wrote:
> > >>
> > >> May I ask why would you like to say CBCharacteristic into NSUserDefaults?
> > >>
> > >> Best Wishes,
> > >> Khaos Tian
> > >>
> > >> On Apr 17, 2013, at 12:56 PM, Jack Phan <email@hidden> wrote:
> > >>
> > >> Hi Group,
> > >>
> > >> I'm working on a project for iPhone (Central) with TI CC2541 (Peripheral)
> > >> and would like to save a CBCharacteristic *myChar to NSUserDefaults but I
> > >> don't know how.
> > >> Please give me a way to solve this. It's great if you could share your
> > >> code for it.
> > >>
> > >> Thanks a lot,
> > >>
> > >> Jack
> > >> _______________________________________________
> > >> 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:
> > >>
> > >> 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:
> > >>
> > >> 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:
> > >>
> > >>
> > >> 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:
> > >>
> > >>
> > >> This email sent to email@hidden
> > >>
> > >
> > >
> > >
> > > --
> > > William
> > > Sent from my iPhone
> > >
> > > _______________________________________________
> > > 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
> > >
> >
> >
> >
> > --
> > William
> > Sent from my iPhone
>
>
>
>
> --
> William
> Sent from my iPhone
_______________________________________________
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