Подтвердить что ты не робот

Неплохо ли использовать ваш AppDelegate в качестве вашего Singleton?

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

4b9b3361

Ответ 1

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

  • Делегат практически обязателен для приложений iPhone,
  • он там для жизни приложения;
  • и можно получить доступ к нему из любой точки программы (хотя не злоупотребляйте этим!).

Нужно оставаться бдительным, так что код, который необязательно должен быть там, не существует. Вы не хотите, чтобы ваш AppDelegate стал массовым и незаменимым.

Вопрос был поставлен перед StackOverflow:

Разработка приложений и AppDelegate

Ответы на это также помогут вам.

Ответ 2

AppDelegate должен обрабатывать поведение приложения в состояниях запуска, записи фона и т.д. Вы не должны делать его более сложным, так как это не хороший дизайн. Но вы всегда можете ссылаться на свой класс dataStore в AppDelegate и получать доступ к нему через AppDelegate. Таким образом, вы абстрактно сохраняете данные из своего AppDelegate, но вы все равно сможете легко добраться до него.

Ответ 3

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

Большим фрагментам данных необходим накопитель с памятью (Core Data, файловая система, SQLlite или что у вас есть).

У моего самого первого приложения был TON данных, разбросанных вокруг (текст в NSDictionaries, UIImages разных размеров и т.д.). Я построил singleton для управления данными, чтобы сохранить все это в одном месте и обрабатывать запросы сервера для обновлений. Все нормально. Если бы я знал тогда то, что знаю сейчас, я, вероятно, разработал бы стратегию синхронизации Core Data.

Ответ 4

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

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

Ответ 5

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

Он также может быть хорошим способом "singletonize" объектов контроллера, не сжигая ваши мосты, если вы хотите, чтобы у них было более одного из них.

На самом деле я нахожу метод класса в AppDelegate для доступа к нему, поэтому я могу делать такие вещи, как:

[[AppDelegate get].dataStore getRecordNumber:x] // or
[[AppDelegate get].server refreshData]

Но я уверен, что есть те, кто считает, что это плохой дизайн в настройках команды.