Сколько стоит AppDelegate?

Question

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

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

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

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

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

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

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

Надеюсь, что все имеет смысл, дайте мне знать, если вам нужно какое-либо уточнение. Любая информация ценится

Приветствия,

Answer 1

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

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