Why does EAAccessoryDidConnectNotification occur twice?
Asked Answered
H

4

7

I have a class that manages messages coming from and going to an external accessory to an iPad. In the init I have the following code:

- (id) init
{
    self = [super init];
    if (!self) return;

    [[EAAccessoryManager sharedAccessoryManager] registerForLocalNotifications];    //we want to hear about accessories connecting and disconnecting
    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(accessoryDidConnect:)
                                                 name:EAAccessoryDidConnectNotification
                                               object:nil];

    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(accessoryDidDisconnect:)
                                                 name:EAAccessoryDidDisconnectNotification
                                               object:nil];
    ...
}

in dealloc I have

- (void) dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self name:EAAccessoryDidDisconnectNotification object:nil];
    [[NSNotificationCenter defaultCenter] removeObserver:self name:EAAccessoryDidConnectNotification object:nil];
    [[EAAccessoryManager sharedAccessoryManager] unregisterForLocalNotifications];    
}

For some reason, when I connect the external accessory to the iPad the accessoryDidConnect: fires followed by an accessoryDidDisconnect: followed by accessoryDidConnect:

I can't figure out why I would get an extra connect and disconnect. Any ideas?

Hedgehop answered 29/7, 2011 at 14:41 Comment(0)
N
5

the eaaccessory framework will always fire 2 connect and 2 disconnect notifications from some reason. The first connect disconnect pair will have no protocol strings, you can ignore these.

Naomanaomi answered 8/2, 2013 at 16:25 Comment(0)
U
4

Change to this sequence. First notification register then for manager

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(accessoryDidConnect:)
                                             name:EAAccessoryDidConnectNotification
                                           object:nil];


[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(accessoryDidDisconnect:)
                                             name:EAAccessoryDidDisconnectNotification
                                           object:nil];



[[EAAccessoryManager sharedAccessoryManager] registerForLocalNotifications];    //we want to hear about accessories connecting and disconnecting
Ultramarine answered 29/7, 2011 at 14:50 Comment(4)
Well, things appear to be working correctly now. I only get an accessoryDidConnect / accessoryDidDisconnect message once now, which is good. However, it appears to be unrelated to the order that registerForLocalNotifications is called. But, all documentation I have ever found does the register call in the order you have here. I seem to be doing it a little backwards. I think the real issue may have been in my reference counting of the EAAccessory object. There have been a lot of code changes lately to this area of code, but they weren't by me. I talked to the dev who did them, and ...Hedgehop
He isn't sure why those notifications are only coming in once now. As a side note, our reference counting was off because we didn't realize that threading increased the reference count of the target the thread runs on. Anyhow, I'll mark this as the answer even though I'm not 100% sure why this suddenly works right.Hedgehop
because EAAccessoryManager is wrapper object which will handle upto the previos registrations.so before wrapping all notification u should first specify i need to get those notificationUltramarine
this is not working for me, its never calling EAAccessoryDidConnectNotification method even device connectedArduous
V
2

Not an answer but I can't post a comment. I'm seeing this double notification too using the code provided in the answer above. I am also seeing it in the EADemo sample code provided by Apple.

Vita answered 7/9, 2011 at 17:44 Comment(5)
So changing the order of the NSNotificationCenter observers and registering for EAAcessoryNotification did not help? As I said above, I'm not sure why suddenly this began working properly. I'll double check that connect fires just once (working on a new app that also connects to a different accessory). I remember this problem drove me crazy before.Hedgehop
Right - changing the code order didn't make a difference. I also tried setting up notification in the app delegate rather than my rootviewController (just because it was something to try). Then I tried Apple's demo and got the same connect/disconnect/connect behavior. It's not the camera connector I have - I also have a midi mobilizer device and get the same result. The only thing left (that I can think of) is that my iPad connector is dodgey - or I have something dodgey going on with my libusb. I'm also doing work with the Kinect/OpenNI - and maybe I screwed something up systemwise.Vita
Did you ever this figured out? If not, maybe this question should be reopened.Hedgehop
No, haven't sorted it out + haven't upgraded to iOS 5 yet to test if it is still an issue. When I tried changing the order (per above) it didn't make any difference.Vita
iOS5 doesn't help the situation. There are still two notifications sent when connecting.Violinist
F
0

The answer is on the documentation of EAAccessoryDidConnectNotification

In some cases, the connection notification may be sent before authentication has completed, resulting in an empty protocolStrings array and a subsequent disconnection message. If this happens, another connection message is sent later, when authentication succeeds.

It's definitely not supposed to happen all the time, but if you receive this connected / disconnected / connected sequence, check the protocol strings. It's probably related to the authentication failing.

Finsen answered 2/10, 2017 at 11:45 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.