蓝牙4.0 For IOS/工作模式

发现

• 看起来有两种工作模式，事件后台和会话后台

见识

RE: How to make BLE app work on background of iPhone4S ^{沿途见识[1]}

There are two modes of backgrounding for Apps that use CoreBluetooth: Event and Session.

 

Event Backgrounding

Event backgrounding is probably what most Apps will use when interacting with Bluetooth Low Energy devices.  This mode does not allow for direct communications to the accessory when the App is in the background, but does provide for a notification from the accessory when it wants to communicate with the app.  iOS will stay connected to the BTLE accessory when your App is in the background and will continue to monitor for notifications.  When the connected BTLE accessory has a notification available, iOS will notify the user that the accessory would like to talk to your App, allowing the user to load your App and interact with the accessory.  As many devices need to conserve power, only providing information at deterministic times will greatly enhance the battery life of the accessory and the iPhone 4S.

 

- No info.plist entries are required for this mode.

 

Session Backgrounding

There are times where an App must interact with an accessory even if it is running in the background.  Consider a running app that needs to monitor heart rate real-time.  There is a clear START and STOP to this model.  The user STARTS their run in the App. While the run is active, the App reads heart rate information until the run is completed or STOPED.  Session backgrounding also allows for scanning and connection to BTLE accessories while the App is in the background.  A scanForPeripheralsWithServices or connectPeripheral call will continue, even when the App is in the background.  CoreBluetooth will continue to monitor for specific peripherals or peripherals that match the services your App is looking for and call your Apps delegate when found or connected.  Be mindful, that every time a BTLE peripheral or iPhone 4S uses its radio, it is depleting the respective devices available power.  App developers using session based backgrounding must be mindful of power usage.

 

- Session backgrounding requires a backgrounding mode entry to UIBackgroundModes, bluetooth-central, in your Apps info.plist.

Re: How to make the BTLE APP to auto connect with BTLE device when iPhone4S power on ^{沿途见识[2]}

When backgrounding, you can still scan and connect to a LE peripheral.  You can scan for peripherals using scanForPeripheralsWithSerives by stating what service you are looking for in a Peripheral.  You cannot do a general scan without stating at least one service in the passed dictionary.  If you have a CFUUIDRef from a previous connection, you can call retrievePeripherals with the CFUUIDRef.  Your delegate will receive a call to didRetrievePeripherals with a CBPeripheral.  With the CBPeripheral you can then connect using connectPeripheral.

Re: Default connection interval ^{沿途见识[3]}

I believe the iOS 5.0 default was 105ms - but if you send a change parameter request with min=20ms, max=40ms (the lowest range that conforms to the apple guidelines), then you get 37.5ms. Technically, if you violate the guidelines, you can get the phone to go as low as 18.75ms under iOS 5.

Under iOS 6 - the default connection interval is 30ms vs. 105ms. I do not believe this is ever changed after the fact as I print this value in my radio firmware, and have never seen anything over 30ms. The way we've written our firmware, we only request a connection parameter change if the interval goes above 40ms.

I have tried advertising packets that contain the preferred parameters, but I do not believe they make any difference.

Developer Forums: cancelPeripheralConnection doesn't really disconnect device in IOS 6 ^{沿途见识[4]}

Hi - this is a bug that is well reported in the dev forum as well as the bluetooth mailing list. The issue is that iOS 6 (not 5) keeps this connection around for 30-60 seconds in case some other app intends to connect to the peripheral.
 
Unfortunately, Apple does not think this is a bug - in fact, many people submitted this report and the official response has been that it was intended behavior.
 
What Apple failed to realize when making this design decision, is that many peripherals have a state machine that cannot simply be handed off to another application. The only thing I can venture is that this is some optimization to make connections and characteristic discovery quicker - and if two apps on a phone want to use the peripheral device then the second app shouldn't have to rediscover the peripheral, services, and characteristics that were recently discovered by the first app.
 
It's a nice thought that works for trivial peripherals like GPS or temperature sensors. But for any more complicated peripheral applications with non-trivial state machines, this makes no sense and is causing major problems - especially when you need to share peripherals quickly between different phones. Many folks (including myself) have tried to work around the problem by implementing a custom message to the peripheral to tell it to tear down the connection. This is the only way you can guarantee that the connection is torn down immediately.
 
In the short term, what Apple should do is add an API like "forceDisconnection", or add a bit to the "cancelPeripheralConnection" API that will force the connection to be torn down immediately. The default behavior might be to leave the connection open as they do in iOS 6, if they really want to speed up service discovery across apps, but give developers the option to request immediate disconnect if it makes sense for the peripheral.
 
Further, while I can see why such optimization might make sense for normal bluetooth, BTLE is signficantly different - and with the 30ms connection interval in iOS6 this probably saves a couple seconds on setup at best.
 
I think the best thing we can do as developers is to continue to open bugs on this issue and push Apple to add the fix I described above - because once the folks at Apple try to develop any non-trivial BTLE peripherals and applications, they will realize the current implementation really causes significant trouble.

Developer Forums: JustWorks, and passKey any core bluetooth API? ^{沿途见识[5]}

you musst just add IOCapabilities and set your charakteris as private. The iphone do then all automatic.
Ask you for a passkey and do pairing.
 
hope i can help.

Re: Rules of Pairing - MUST "forget this device" in iPod Touch5? ^{沿途见识[6]}

Regarding pairing rules on BLE:
Normally, pairing is initiated as soon as you try to access a characteristic that
requires bonding (and thus, returns an error that indicates insufficient security levels).

iPhone 4S and iPod touch 5 should react similar here.

引用信息

以下是[蓝牙4.0 For IOS/工作模式]所有用到的引用信息，向这些伟大的家伙致敬：

1. ^ http://lists.apple.com/archives/bluetooth-dev/2011/Dec/msg00012.html
2. ^ http://lists.apple.com/archives/bluetooth-dev/2011/Dec/msg00019.html
3. ^ http://lists.apple.com/archives/bluetooth-dev/2012/Dec/msg00023.html
4. ^ https://devforums.apple.com/thread/171284?tstart=50
5. ^ https://devforums.apple.com/thread/150353?tstart=150
6. ^ http://prod.lists.apple.com/archives/bluetooth-dev/2012/Dec/msg00011.html

转载自：http://see.sl088.com/wiki/%E8%93%9D%E7%89%994.0_For_IOS/%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F