Какова цель — accessorDidDisconnect: метода в EAAccessoryDelegate?

Я работаю над реализацией iOS, которая подключается к оборудованию, и поэтому мне приходится использовать инфраструктуру внешних аксессуаров. Чтобы взаимодействовать с устройствами, вам нужен класс, который обрабатывает связь с EAAccessory объектами. Для этого вы должны определить класс подключения вашего устройства с протоколом EAAccessoryDelegate.

Протокол EAAccessoryDelegate содержит один метод:

– accessoryDidDisconnect:(EAAccessory *)accessory.

В документации Apple говорится:

Протокол EAAccessoryDelegate определяет единый метод получения уведомлений, когда связанный объект EAAccessory отключен. Реализация этого метода необязательна.

Когда вы создаете экземпляр своего класса, вы можете зарегистрировать свои собственные методы в системе NSNotificationCenter. При наличии события подключения устройства или отключения устройства вы можете обрабатывать это событие по своему усмотрению. Когда происходит событие отключения устройства, цель - accessoryDidDisconnect: становится бессмысленной, поскольку она предоставляет точно такие же функции и данные для вашего класса.

Кроме того, все примеры работы с External Accessory Framework, которые я могу найти, содержат примеры обнаружения изменений подключения устройства с помощью механизма подписки NSNotificationCenter.

С учетом сказанного, в чем смысл метода – accessoryDidDisconnect:, если он никогда не используется? Да, это можно реализовать, но, как я уже упоминал, во всех формах документации рекомендуется управлять этими типами изменений подключения через файл NSNotificationCenter.

Я знаю, что это сложный вопрос, но мне очень любопытно.


ios objective-c external-accessory eaaccessory
person RLH    schedule 13.03.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это довольно распространенный паттерн проектирования Apple, обеспечивающий быстрый доступ к очень распространенным уведомлениям NSNotificationCenter. В OS X они делают это со многими уведомлениями NSWindow, передавая в этих случаях содержимое NSNotification.

По сути, это простой способ реализовать уведомление без необходимости добавлять и удалять своего наблюдателя.

В частности, это используется только после создания объекта EAAccessory (что происходит только после подключения аксессуара), и, таким образом, наличие метода подключения в настоящее время неприменимо.

person gaige    schedule 13.03.2012
comment
Я предполагал, что это так, однако, не странно ли, что нет аналогичного -accessoryDidConnect? По правде говоря, я бы предпочел использовать вызов определенного метода делегата, однако для согласованности я использую систему уведомлений. - person RLH; 13.03.2012
comment
Не совсем. Проблема в том, что объект EAAcessory существует только тогда, когда подключен аксессуар, поэтому в этом случае нечего быть делегатом. - person gaige; 13.03.2012