Re: Use 2 central Manager
Re: Use 2 central Manager
- Subject: Re: Use 2 central Manager
- From: Etan Kissling <email@hidden>
- Date: Mon, 28 Jan 2013 10:34:17 +0000
- Thread-topic: Use 2 central Manager
Samuel,
as you noticed, CBPeripherals cannot be shared between CBCentralManager.
Therefore, an approach with multiple CBCentralManager cannot work at all in the case
where you want to connect to a new unknown peripheral, as for such peripherals, the
UUID is null. You cannot use this UUID for comparison purposes like you proposed in your
code comment.
For the CBPeripheralManager, the documentation actually tells that only one instance
should be used at any time:
/*!
* @class CBPeripheralManager
*
* @discussion Entry point to the peripheral role. Commands should only be issued when its state is <code>CBPeripheralManagerStatePoweredOn</code>.
* The use of more than one <code>CBPeripheralManager</code> at a time is not supported and may result in undefined behavior.
*
*/
NS_CLASS_AVAILABLE(NA, 6_0)
CB_EXTERN_CLASS @interface CBPeripheralManager : NSObject
{
@package
id<CBPeripheralManagerDelegate> _delegate;
CBPeripheralManagerState _state;
BOOL _advertising;
}
Conclusion:
- Multiple CBCentralManager instances cannot work in all cases. You also noticed that even standard
cases don't work well.
- Multiple CBPeripheralManager instances are documented to fail.
I assume that you want to plug multiple delegates in a single CBCentralManager instance (to split
logic for connecting and discovering).
- One solution is to send your CBCentralManager instance between your viewControllers, and change
the delegate on each view transition.
- Another solution is to use NSNotificationCenter to send local broadcasts of the CoreBluetooth events.
Just plug a new object in as the CBCentralManager's delegate that handles the forwarding, and listen
to these events in your observing viewControllers.
Etan
On 28.01.2013, at 10:51, Alpwise iOS Dev <email@hidden>
wrote:
> Hi,
>
> thanks for the reply. I fixed my code and used only one CM.
> As Apple permit to create multiple instance of CM, i was thinking that was possible. But like you say it's a disaster.
>
> Cheers,
> Samuel
>
> Le 25 janv. 2013 à 16:09, András Kövi a écrit :
>
>> When I tried that, the results were disastrous. Start a request on one manager and receive the callback on the other... It's possible that I messed up something but not very likely. However, the things you describe are easily handleable by one CM. Why would you use two?
>>
>> I suggest you try to optimize your use case for one CM.
>>
>> Note: The CBPeripheral is an internal object and it is connected to the CentralManager. You shouldn't suppose anything on the lifecycle of the CBPeriperal or its values. However, you start a connection to it, then you must keep the reference as long as the connection is alive, otherwise you'll get a warning that the peripheral is being deallocated while it is connected or the CM is trying to connect to it. This is an annoying behavior but we have to live with it.
>>
>> Cheers,
>> Andras
>>
>>
>> 2013/1/25 Alpwise iOS Dev <email@hidden>
>> Hi,
>>
>> I would use 2 central manager, one to manage the discovery and another to manage the connection.
>> So i need to pass a CBPeripheral discover from a CBCentralManager to another CBCentralManager.
>>
>> Has someone already try that?
>>
>> Here is my example.
>> ===============================
>> -(void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI
>> {
>> // central != _centralManager
>> _peripheralDiscovered = peripheral;
>> [_centralManager connectPeripheral:peripheral options:nil];
>> }
>>
>> -(void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral
>> {
>> // central == _centralManager
>> // peripheral != _peripheralDiscovered but [peripheral UUID] == [_peripheralDiscovered UUID]
>> }
>> ===============================
>> It seems that a new CBPeripheral is allocated when the central change. It is a normal behavior?
>>
>> Thanks,
>>
>> Samuel.
>>
>>
>>
>> _______________________________________________
>> 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