Я иногда использую Singleton (для хранения данных, которые используются несколькими различными классами) в моих проектах, и я думаю, почему бы не использовать мой AppDeletage, поскольку он уже является Singleton и легко доступен. Это плохая практика, и если да, то почему?
Неплохо ли использовать ваш AppDelegate в качестве вашего Singleton?
Ответ 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]
Но я уверен, что есть те, кто считает, что это плохой дизайн в настройках команды.