Делегаты iPhone - как правильно их использовать

Question

У меня есть 2 или 3 представления в моем приложении для iPhone, где у меня есть различные функциональные возможности, использующие делегатов. Во всех случаях делегаты назначаются на «себя», конкретно отвечая на действия этого представления и взаимодействуя с переменными экземпляра.

Однако, если я делаю что-то, что занимает немного времени с делегатом, и покидаю представление, очевидно, это приводит к сбою моего приложения, когда методы делегата вызывают для представления, которое я оставил.

Обычно в моих методах делегатов я выполняю такие вещи, как взаимодействие с IBOutlets, вызов других методов экземпляров, сохранение данных в Core Data и т. Д. *

Как мне лучше работать с делегатами? Это то, что я делаю типично, или нет?

Спасибо за любые советы!

Answer 1

Можете ли вы привести конкретный пример проблемы, с которой вы столкнулись?

Однажды я столкнулся с такой ситуацией, когда имел дело с MapKit (условия гонки, включающие обратные вызовы делегатов и освобождение делегатов). Тем не менее, в целом, я думаю, что это указывает на плохое проектное решение, когда ваш делегат становится недействительным из-за условий гонки, но я могу ошибаться.

Как правило, объекты, которые используют ваш делегат, должны существовать в контексте самого делегата. Так, например, тот же класс, который содержит различные IBOutlet s, которыми вы хотите управлять с помощью обратных вызовов делегата, также должен быть делегатом этих IBOutlet s. Таким образом, когда класс (то есть делегат) освобождается, IBOutlet (надеюсь) также освобождаются, поэтому они не будут делать обратные вызовы ни к чему.

Бапа прав. В более общем случае, если у вас потенциально длинный обратный вызов делегата, убедитесь, что 1) делегат является объектом, который не будет освобожден в течение жизненного цикла делегатора (например, UINavigationController, управляющий UIViewController s) или 2) во время освобождения делегата объект delegate делегата устанавливается в ноль.

... Это последнее предложение было полным ртом. :)

Answer 2

Ваши делегаты должны быть объявлены как

@property (nonatomic, assign) id <MyDelegateProtocol> delegate;

Это обеспечивает слабую ссылку, поэтому, когда вы освобождаете объект, имеющий delegate, он удаляет только ссылку, а НЕ соответствующий объект. использование (strong) вызовет сбой на dealloc.

При вызове вашего делегата вы можете проверить

if (self.delegate && [self.delegate respondsToSelector:@selector(MyDelegateProtocolCallbackMethodName:)] {
   [self.delegate MyDelegateProtocolCallbackMethodName:result];]
}

Обычно я использую делегаты для прокси-классов, которые извлекают данные с сервера или редактируют экраны, например, изменяют заголовок задачи в списке задач или редактируют модель в базе данных.

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

Answer 3

Зависит от варианта использования.Если, например, у вас есть UINavigationController, который управляет ViewController, использующим что-то, например, Location Services, когда вы вытаскиваете View Controller из стека, вы захотите установить делегат CLLocationManager равным nil.Вы можете сделать это в методе dealloc.