Разработка iPhone и iPad - хорошая дизайнерская архитектура для максимального повторного использования

Question

У меня три вопроса, связанных с разработкой iPhone и iPad.Я пишу приложение для iPhone, которое должно появиться в будущем и для iPad.Используя шаблон MVC, я знаю, что сохраню свои модели, однако мне не ясно, нужно ли мне отказаться от контроллеров и / или представлений.Итак, мои вопросы:

1) Каковы лучшие практики для тех, кто разрабатывает одно и то же приложение для обеих платформ?Какие части обычно можно использовать повторно и какие части обычно отбрасывают для разработки обоих приложений с минимальными усилиями и правильным дизайном?

2) Кроме того, мне также необходимо иметь информацию о состоянии / глобальной информации в приложении.Как вы обрабатываете (с точки зрения дизайна) информацию о состоянии в приложении для iPhone / iPad?В настоящее время у меня есть информация о пользователе (имя пользователя и пароль), которую мне нужно использовать в приложении для выполнения нескольких запросов к серверу (закодировано в заголовке http).Для этого у меня есть пользовательская модель, хранящаяся в классе AppDelegate.Это нормально с точки зрения дизайна, или это должно быть сделано по-другому?

3) Наконец, у меня есть мои модели, разделенные на абстрактные классы (или классы, обрабатывающие общие вещи) и подклассы, специализирующиеся на различных задачах,Идея состоит в том, чтобы писать как можно меньше кода, чтобы избежать повторения кода (пример: отправка запросов является общей, а анализ ответов зависит от поставленной задачи).С точки зрения производительности, является ли проблемой разделение кода на несколько классов и наследование модели?

Заранее спасибо!

Answer 1

1) Хорошо продуманные модели, представления и контроллеры должны в основном использоваться на устройствах iOS. Степень различия в дизайне пользовательского интерфейса между платформами будет в значительной степени диктовать возможность многократного использования контроллеров представления. Например, при работе на iPad контроллеры представления могут быть представлены в виде разделенного представления или всплывающего окна вместо полноэкранного режима, а в листах действий, представленных из элементов панели кнопок, скорее всего, не будет кнопок отмены.

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

3) Слишком сложные иерархии классов могут снизить гибкость и усложнить понимание того, как все работает, но не стоит беспокоиться о производительности в отношении сложности иерархии классов. Вместо этого измеряйте производительность и тратьте время на оптимизацию, чтобы получить максимальную отдачу при минимальных усилиях. Это вряд ли будет поиск реализации метода суперкласса.