Плохо ли использовать AppDelegate в качестве синглтона?

Question

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

Answer 1

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

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

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

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

Дизайн приложения и приложение Deelegate

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Это также может быть хорошим способом «однотонизации» объектов контроллера без прожига ваших мостов, если вы захотите позже иметь более одного из них.

Я на самом деле поместил метод класса в AppDelegate для доступа к нему, чтобы я мог делать такие вещи, как:

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

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

Answer 5

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

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