iPhone - смена делегата может вызвать сбой при асинхронных вызовах?

Question

У меня есть класс, который создает экземпляр другого класса и работает в качестве делегата для этого второго класса.Этот второй класс является «свободным» и не сохраняется первым.

Этот второй класс отправляет асинхронные HTTP-запросы и прослушивает их ответ.
Когда ответ получен, он анализируется, иРезультат переупаковывается и отправляется одному из методов делегата.Как только делегат вызван, экземпляр второго класса освобождает сам себя.Конец показа.

Чтобы быть уверенным в получении ответа сервера, когда первый класс входит в dealloc (по любой причине), он изменяет свойство делегата второго, чтобы направить ответ в делегат приложения.

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

Как бы вы конкретно справились с этой проблемой?

Вот схема процесса:

• AppDelegate создает A1, A2, A3.
• , каждый Ax создает Bобъект экземпляра (B1, B2, B3, который отправляет HTTP-запросы), и каждый Ax определен как делегат Bx
• , на этом этапе все экземпляры классов A и B могут иметь свою жизнь
• если экземпляр Ax умирает, класс Bx может отправить ответ в приложение applegate вместо экземпляра Ax

Answer 1

У вас есть проблема, если A является делегатом для B , но A не разрешено сохранять B .

* * 1010 B должен знать, что является делегатом ( A ) все еще рядом или установлен на nil при необходимости. A должен знать, что B все еще рядом, иначе он не может безопасно удалить себя в качестве делегата.

Поэтому снимите ограничение сохранения и дайте A правильно сохранить B .

Или перейдите к менее связанному решению с помощью уведомлений.

1. Пусть B определит уведомление и опубликует его.
2. Позвольте A зарегистрироваться в качестве прослушивателя для уведомления при создании и отменить регистрацию при освобождении.

Answer 2

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

Для меня это не похоже на разумную архитектуру.Жонглировать делегатами так, как вы, не нужно.Выделите код, который сообщается серверу с его собственным классом, который сохраняется столько времени, сколько вам нужно.Не распространяйте свой сетевой код по всему приложению на объекты, которые приходят и уходят постоянно, и не рассматривайте делегат приложения как ловушку, когда вам нужно что-то доступное более чем в одном месте.