Re: Multiple CBCentralManagers?
Re: Multiple CBCentralManagers?
- Subject: Re: Multiple CBCentralManagers?
- From: Andras Kovi <email@hidden>
- Date: Fri, 03 May 2013 00:25:51 +0200
Hi Rick,
you shouldn't do that. Callbacks can easily be messed up, additionally, CB doesn't tolerate well the regular/stressful creation/deletion of managers. There have been several discussions on this topic, you may look them up jn the list archives.
If I could suggest you, try to use some loosely coupled solution, e.g. notifications. The "peripheral retrieved" callback would simply have to publish a corresponding notification that your local code could listen to. This way you need to access only the manager but not change the delegate. But I think you know these kind of patterns better than I do.
I personally find ReactiveCocoa to be a really useful tool for these kind of situations. It's much easier for me to think in terms of signals than delegates and callbacks (usually messed up with switch and if-then statements).
Regards,
Andras
On 2013.05.03., at 0:02, Rick Mann <email@hidden> wrote:
> Is it okay to have multiple CBCentralManagers around? What happens if I instantiate a CM, use it to get a CBPeripheral, then deallocate that CM but keep the CBPeripheral around? What if I have one CM per peripheral?
>
> I have a situation where I'm storing a representation of my CBPeripheral in Core Data (it has a UUID property). When that representation is later fetched from Core Data, I need to get a new CBPeripheral instance for it. Unfortunately I don't have easy access to the "main" CM I'm using in my app for discovery, and even so, having a "dedicated" CM allows for straightforward retrieval of a CBPeripheral in -awakeFromFetch.
>
> --
> 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:
This email sent to email@hidden