архитектура и компоненты iOS

Довольно долго я рассматривал примеры objective c, смотрел лекции в Стэнфорде и играл с некоторым кодом, чтобы получить навык создания приложения iOS.

Однако есть несколько вещей, на которые я не могу найти хорошего ответа:

  1. Как правильно разделить слои? Я понимаю структуру MVC и видел несколько примеров создания категорий для моделей для реализации бизнес-логики. Это правильный путь, обогащая модели или я должен создавать выделенные классы (например, для аутентификации пользователей, извлечения моделей из json, групповых заказов)?

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

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

    • Как я могу повторно использовать ViewController order-view и View в других ViewControllers?
    • Если у меня есть 4 экрана с одинаковым внешним видом, должен ли я просто скопировать их в раскадровку? Это кажется болью для main, что делать, если я хочу изменить свой фон? Или добавить кнопку ко всем представлениям? Когда я создаю мастер настройки, я не хочу определять внешний вид каждого экрана отдельно.

Исходя из фона C#, я, вероятно, должен войти в установку objective-c:)
Любая помощь в этом была бы очень кстати.

2 2
ios objective-c architecture

2 ответа:

1) ObjC-категории легко исказят ваше понимание основной проблемы, с которой вы столкнулись. ObjC-категории совершенно не нужны . Вы всегда можете подойти к этим расширениям с помощью подклассов, композиции объектов, дополнительных методов в реальной модели или некоторой настройки в контроллере или представлении. Поэтому, если вам нужно отформатировать данные (например, которые присутствуют в модели) для отображения в виде-эта задача часто будет выполняться в контроллере. Что касается примеров, которые вы приводите: Вы можете выбрать модели в простых случаях - кроме того, любой из примеров может заслуживать выделенного класса, если он достаточно сложен или если это удержит вас от избыточной реализации. Обратите внимание, что это могут быть вспомогательные классы, которые просто производят модель, или они могут быть составными частями нескольких конкретных абстрактных классов. Не все должно приземляться прямо в определении M-или-V-или-C. Вы можете свободно использовать множество шаблонов проектирования с ObjC. Подумайте о MVC как о шаблонах, которые обычно использует какао -- вам нужно будет знать их, и вам нужно будет знать, как подклассировать и расширять эти типы, но эти шаблоны теряют доминирование по мере удаления реализаций от библиотек Cocoa (например, по мере увеличения сложности).

2) они могут быть умными. Однако в MVC вы хотите сосредоточить его реализацию на аспекте представления / представления. Представление, представляющее собой набор информации, на самом деле может выполнять некоторые задачи, которые обычно зарезервированы для контроллера - однако вы бы обычно уступают, что реализация была выделена MONContactView при этом. Если вы идете этим путем, вы обычно делаете это для удобства повторного использования или для достижения простого интерфейса. Отображение информации о Contact может быть очень сложным - в простых сценариях эти задачи часто обрабатываются контроллером. В частности, MONAwesomeContactView, вероятно, менее сложен (например, в SLOC), чем MONAwesomeContactViewController (Если у вас нет какого-то очень специального чертежа или макета для выполнения). Было бы более распространенным установить контроллер свяжитесь, и пусть контроллер передаст контактные данные в поля представлений. Опять же, в случае очень специализированного подкласса-представление может очень хорошо содержать свои собственные контроллеры в некоторых случаях.

3a) нет ничего плохого в создании нескольких экземпляров класса.

3B) нет необходимости копировать. Когда дублирование чувствуется, я толкаю реализацию к фактическому коду - программы могут применять внешний вид и чувствовать, что вы хотите, или добавлять или манипулировать подвидами, как вы хотите. Конечно, они не будет присутствовать в Редакторе перьев Xcode. Конечно, существуют альтернативные подходы, но эта репликация часто заставляет меня переносить реализацию в скомпилированный код. Достижение хорошего баланса обоих не так уж сложно (лично я делаю большую часть своих взглядов программно, а не с помощью NIBs).
5

  1. Это довольно абстрактный вопрос, и непонятно, что означает слово "слои". Да, вы должны создавать свои собственные классы, где это уместно, но категории также дают вам возможность добавлять функциональность к существующим классам. Если вы можете быть более конкретны в вопросе, вам будет легче дать лучший ответ.

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

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

1