#iphone #objective-c #ipad #model-view-controller #design-patterns
#iPhone #objective-c #iPad #модель-вид-контроллер #шаблоны проектирования
Вопрос:
У меня есть три вопроса, связанных с разработкой для iPhone и iPad. Я пишу приложение для iPhone, которое в будущем должно быть доступно и для iPad. Используя шаблон MVC, я знаю, что сохраню свои модели, однако мне неясно, нужно ли мне будет отказаться от контроллеров и / или представлений. Итак, мои вопросы:
1) Каковы наилучшие практики для тех, кто разрабатывает одно и то же приложение для обеих платформ? Какие части обычно используются повторно, а какие обычно выбрасываются, чтобы разработать оба приложения с минимальными усилиями и правильным дизайном?
2) Кроме того, мне также нужно иметь информацию о состоянии / глобальную информацию в приложении. Как вы обрабатываете (с точки зрения дизайна) информацию о «состоянии» в приложении для iPhone / iPad? В настоящее время у меня есть информация о пользователе (имя пользователя и пароль), которую мне нужно использовать во всем приложении, чтобы выполнить несколько запросов к серверу (закодированных в заголовке http). Для достижения этого у меня есть модель пользователя, сохраненная в классе AppDelegate. Это нормально с точки зрения дизайна, или это должно быть сделано по-другому?
3) Наконец, мои модели разделены на абстрактные классы (или классы, обрабатывающие общий материал) и подклассы, специализирующиеся на разных задачах. Идея заключается в написании как можно меньшего количества кода, чтобы избежать повторения кода (пример: отправка запросов является общей, а анализ ответов зависит от решаемой задачи). С точки зрения производительности, является ли проблемой разделение кода на несколько классов и наследование модели?
Заранее спасибо!
Ответ №1:
1) Хорошо разработанные модели, представления и контроллеры должны в основном использоваться повторно на устройствах iOS. Степень различий в дизайне пользовательского интерфейса между платформами в значительной степени будет определять возможность повторного использования контроллеров просмотра. Например, при запуске на iPad контроллеры просмотра могут быть представлены в разделенном виде или во всплывающем окне вместо полноэкранного режима, а таблицы действий, представленные с помощью элементов bar button, скорее всего, не будут иметь кнопок отмены.
2) Не сохраняйте состояние в делегате приложения. Вместо этого сохраните его в классе модели. Имя пользователя и пароли, в частности, должны храниться в связке ключей.
3) Чрезмерно сложные иерархии классов могут снизить гибкость и затруднить понимание того, как все работает, но не беспокойтесь о производительности в отношении сложности иерархии классов. Вместо этого измерьте производительность и потратьте время на оптимизацию, где вы получите наибольшую отдачу с наименьшими усилиями. Вряд ли это поиск по реализации метода суперкласса.
Комментарии:
1. Спасибо за ваш ответ. Это отвечает на мои вопросы. У меня просто есть несколько замечаний: 1) Между версиями для iPhone и iPad будут различия. Версия для iPad, скорее всего, будет иметь больше функций, чем приложение для iPhone. Что я сделал, так это оставил контроллеры в виде простых классов клея и сохранил всю логику в моделях. У меня было слишком много информации, связанной с моделью, в контроллерах, и поскольку я боялся, что мне придется переписывать контроллеры для версии iPad, я сделал это таким образом. Надеюсь, я не пожалею об этом в будущем…
2. 2) Спасибо за совет. Я, честно говоря, забыл keychain API для этого!
3. 3) Причина, по которой я пытался создать некоторую иерархию моделей, заключалась в том, что я хотел создать приложение, простое для понимания, и потому что я обнаружил общие операции среди разных классов. Я беспокоился, что это приведет к снижению производительности, но, как вы сказали, это, вероятно, не повлияет на производительность. Не очень часто можно найти хорошие примеры моделей iOS и объектной ориентации, поскольку большинство приложений, которые я вижу в Интернете, используют контроллеры для хранения информации о модели. (пришлось разделить мой комментарий на 3 … извините за это)