Сколько должен делать AppDelegate? - PullRequest
2 голосов
/ 19 мая 2010

Я разрабатываю довольно большое приложение, и при запуске оно будет создавать сессии с несколькими различными серверами. Поскольку они создают сеанс, который используется во всех частях приложения, я подумал, что это будет лучше всего в App Delegate.

Но проблема в том, что мне нужно, чтобы прогресс сеанса отображался на экране. Я планирую иметь UIToolBar в нижней части главного меню, которое я не хочу покрывать индикатором выполнения, но покрываю UIView над ним. Так, как я его вижу, я мог бы сделать это несколькими различными способами.

1) Попросил ли делегат приложения установить сеансы и сообщить о ходе выполнения классу главного меню, чтобы он мог представить его на индикаторе выполнения (возникнут ли у меня какие-либо проблемы, если сеансы создаются в отдельном потоке?),

2) чтобы делегат приложения отображал главное меню (UIView с кучей кнопок и UIToolBar) и отслеживал и отображал прогресс (я никогда ничего не отображал в делегате приложения, но предположил, что вы можете это сделать, но это не так рекомендуется) или

3) пусть Делегат приложения просто откроет главное меню, а класс mainMenu создаст сеансы и отобразит индикатор выполнения.

4) Я думаю, что другой способ сделать это - создать сеансы в классе делегата и установить для делегата значение mainMenu, а не self (AppDelegate), хотя я никогда не использовал ничего, кроме self, поэтому не уверен, что это сработает, или если я смогу закрыть поток (возможно, с помощью вызова super?), так как он выполняется в AppDelegate, а не в делегате класса.

Как я уже сказал, до того, как сеансы создаются в классе в отдельном потоке, поэтому он не будет блокировать пользовательский интерфейс, и я думаю, что лучший способ - первый, но у меня будут проблемы с его запуском в отдельном поток, отчитываясь перед делегатом приложения и затем отправляя это сообщение в представление mainMenu?

Я надеюсь, что все это имеет смысл, дайте мне знать, если вам нужны дальнейшие разъяснения. Любая информация ценится

Приветствия

1 Ответ

1 голос
/ 19 мая 2010

Предположительно, состояние соединений будет влиять на функциональность вашего приложения.Я бы, вероятно, подумал об объекте диспетчера соединений, который может инициировать соединения, поддерживать их состояние и отвечать на запросы об их состоянии.Точно так же, как одноэлементный объект вернет существующий объект или создаст и вернет новый объект, которого не существует, диспетчеру соединений даже не нужен метод «make connection», просто «get handle» - если соединение неоткрыть его можно попытаться сделать так.

Вы также упоминаете, что статус должен отображаться на главном экране.Наличие объекта менеджера, способного выполнять задачи неопределенного времени (открытие соединения с хостом, который может быть готов, занят, удален или просто сломан) в фоновом режиме, а затем сообщать о ходе выполнения главному потоку, чтобы пользовательский интерфейс мог бытьобновленный (помните, нет доступа к UIKit во вторичных потоках), кажется идеальным, и он также поддерживает ваш View.

...