Как программист-любитель, работающий неполный рабочий день, я, вероятно, был целевым программистом Apple: увлеченный, полный энергии, но серьезно нуждающийся в помощи, если я действительно хочу чего-то добиться.

Не секрет, что Apple поддерживает вариант дизайна приложения Model-View-Controller, но, к счастью, они не продвигают его таким образом; они просто предоставляют вам все необходимые инструменты, шаблоны и автозаполнение, чтобы вы могли создать свое первое приложение в одном файле, а именно в UIViewController. Можно делать замечательные вещи, даже не выходя из этого файла, но если вы рискнете перейти к другой сцене, это нормально, просто поместите еще один UIViewController на StoryBoard, создайте переход и вперед.

Теперь у вас есть многофункциональное приложение со множеством дел и всего два файла, о которых нужно беспокоиться. Простота завораживает, и это означает, что любой может создать приложение и продать его в App Store.

Но потом я начал делать приложения с 4 представлениями, затем с 5, 6. Потом я захотел, чтобы это выглядело по-другому на iPad. А как же ориентация. О, и, конечно же, я хочу, чтобы все было подключено и текло. Я начал серьезно терять контроль и задаваться вопросом, что вообще означает MVC, поскольку у меня, казалось, было много ViewControllers, но, к счастью, подкаст пришел, чтобы помочь мне и показать мне другой маршрут.

Swiftcoders Гаррика Наапетяна: Эпизод 38 с Кшиштофом Заблоцким

Модели

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

А что я?

Мне нравится контроль, мне нравится, когда все аккуратно разложено, и мне нравится знать, что если я положу что-то там, оно прекрасно останется там.

Как насчет моего старого дизайна приложения?

В настоящее время я работаю над приложением для учителей, так что это пока самое сложное, мне нужно хранить данные о расписании, учениках и заданиях. Я потратил время на планирование структуры Core Data и потока приложений в Graphic, затем создал View Controllers в Storyboard, дал каждому VC собственный файл Swift и отправился в путешествие, которое быстро превратилось в лабиринт, джунгли, даже трясину. . На самом деле, не так быстро, как требовалось время для написания тысяч строк кода, но каждый VC содержал ряд переменных, функций, алертов, табличных представлений и т. д., и т. д., они давно потеряли структуру, и отладка была тяжелым испытанием. .

А сейчас?

Там больше кода, и мои венчурные капиталисты на удивление не намного короче, но есть структура. Для каждого «представления» у меня теперь есть 3-4 файла, поэтому для моего представления Student у меня есть: StudentVM, StudentVC, StudentVCLayout и, поскольку у него есть таблица, StudentVCCells. Давайте пройдемся по их ролям:

StudentVM: содержит все переменные и функции, которые потребуются представлению. У меня есть студенческий объект в основных данных, и эта ViewModel считывает его и извлекает все данные в полезные переменные и массивы, например, чтобы вернуть все данные о посещаемости, получить правильный размер фотографии и даже запросить объект назначений для соответствующих данных.

StudentVC: ViewController по-прежнему много делает, но ничего не вычисляет. Если хочет фото среднего размера, не получается размер или ресайз, ВК просто вызывает функцию в ВМ, которая возвращает правильное фото.

StudentVCLayout: чтобы действительно получить контроль, я определяю все представления и ограничения макета в отдельном файле, который на самом деле является расширением контроллера представления. Но когда каждое подпредставление имеет от 2 до 5 ограничений, оно становится длинным (здесь 1500 строк). Здесь же я добавляю действия к кнопкам и устанавливаю начальные значения для меток и т. д.

StudentVCCells: аналогичен файлу VCLayout, но определяет и размещает каждую из ячеек.

Для дальнейшего контроля в этих файлах (надеюсь) нет строковых литералов или им подобных, все задается с помощью перечислений и структур в отдельном файле, в котором хранятся мои настройки MyStyleColor, MyStyleFont и MyAutoLayout. Это позволяет мне вносить глобальные изменения в одном месте. Например, у меня есть значение в MyAutoLayout для verticalPadding, поэтому, когда я устанавливаю ограничение макета, я могу использовать его как константу, что дает мне полностью параметрический дизайн. Я также только что переключился на использование расширения UIImage для хранения всех моих изображений в перечислениях, поэтому в любом месте приложения можно запросить UIImage.Icons.Class.Small для получения изображения с правильным размером.

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

Что я получаю от этого?

Много кода. На самом деле, это ничуть не экономит набор текста.

Но для меня это чистый, элегантный код, которым я искренне горжусь.

Подведение итогов

Моя структура лучше всего описана как MCVMVC, я думаю:

  • Модель: База данных
  • Координатор: берет на себя общий контроль над потоком. Подготавливает модели представления и внедряет их при вызове контроллеров представления.
  • Модель представления: действует как канал между моделью и контроллером представления.
  • Контроллер представления: отображает информацию, предоставленную моделью представления. Я использую 2 или более файлов, чтобы отделить исходный макет от активной логики.

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

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

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

Ссылки:

Отличная статья о координаторах от Soroush Khanlou.

Энди Хоуп на одно использование перечислений.

Swiftcoders Гаррика Наапетяна: Эпизод 38 с Кшиштофом Заблоцким