dev blog #1
В этом выпуске обсудим разработку мобильных приложений, архитектурный паттерн MVVM и многое другое. Выпуск возможно получится несколько длиннее, чем я планировал, но об этом в конце.
Эта рубрика создана скорее не с целью научить чему то (хотя и это тоже), но с целью поделиться своим опытом разработки мобильных приложений под конкретную платформу (iOS).
Все вышесказанное не означает что это не будет полезно тем, кто не пишет на Swift. Напротив, логику можно адаптировать под любую нужную вам платформу.
Какие еще аппки, дядя?
Что вообще сподвигло меня на написание данной статьи? Телеграм меня утомил. Python я использую по работе и он превратился в рутину. Кроме того, мой мак простаивал, а Swift я хотел освоить еще long long time ago... Ну допустим убедил, но что там по цифрам? Мобильный рынок огромен. Большинство людей, только разлепив глаза ото сна, берут в руки телефон. Про разработчиков всяких китайских игр-фармилок я вообще молчу.
Точные цифры я не помню, да и ни к чему вам они. Но если вам мало слов, всегда можно проверить примерный заработок того или иного мобильного приложения в sensor tower (ни разу не реклама, если что). Таким образом, немного изучив конкурентов и рынок в целом, можно влезать в разработку.
Вообще говоря, мой выбор основывался лишь на моих личных предпочтениях и только (мне просто нравится Swift), но всегда приятно увидеть цифры и заранее положить несуществующие 1-2к $ себе в карман.
MVVM
Microsoft презентовала этот шаблон в 2006 году. По сути он является новейшим из всех MV(X) шаблонов, созданный с целью устранения некоторых проблем присущих MV(X). Цель этого шаблона – разделение бизнес логики приложения и его визуальной составляющей. Если слова "бизнес логика" вас не очень то вдохновляют, то забудьте об этом. Речь по сути идет о некоторой абстрактной модели, представляющей всю логику вашего будущего приложения.
Model
Модель – это абстрактное "нечто", чаще всего речь идет о дженериках (поскольку они позволяют полностью забить на конкретный тип данных в самой модели). К примеру, если мы хотим реализовать стек, без дженериков нам бы понадобилось сразу указывать тип данных, который мы будем хранить в этом стеке. Вот пример на языке Swift, без использования дженериков:
Здесь все просто: создаем массив интов, передаем элементы в функцию и тд. Строгая типизация не позволяет нам передать сюда Float или String.
А вот здесь мы передадим абстрактный <Element>:
Поэтому дженерики еще называются don't care type. Нам абсолютно не важно что передавать, логика остается одна и та же. На самом деле в моделях важны две вещи:
- Модель это абсолютно абстрактная вещь
- Модель не занимается получением данных и отправкой их в VM или View (о них поговорим чуть позднее), это задача View Model
По поводу последнего поясню еще раз. Казалось бы, совершенно банальная вещь, допустим нам необходимо получить данные с API или с некоторой БД, и далее передать их для визуализации, или в целях обработки. Получать данные в таком случае будем именно во View Model (VM). Модель не работает с данными напрямую. Мы можем получить данные в VM, а затем передать их внутрь модели с помощью функций, созданных непосредственно для того, чтобы настроить модель нужным образом.
Это очень тонкий момент. Поскольку модель абстрактна, мы не можем (или можем, но не хотим), работать с данными (в контексте вышесказанного) в ней. Приведу еще один пример. Допустим, мы работаем с библиотекой книг. Наша модель будет содержать некоторую структуру, содержащую название книги, автора, и уникальный ID, чтобы удобнее было итерироваться по коллекции. Это все. Далее, во View Model вы создаете массив книг, и получаете данные с внешней API или с внутренней БД.
View Model
View Model стыкует данные и их непосредственное визуальное представление во View, кроме того обновляет состояние модели. Допустим, пользователь поменял настройки в приложении, следовательно нам нужно:
- Уведомить модель об изменении настроек
- Дать понять View, что уже пора бы отрисовать новый экран
Главное не забывать о модификаторах доступа. Создавая модель внутри VM, необходимо позаботиться о том, чтобы View не мог непосредственно влиять на саму модель. Например, объявить модель private, а затем настроить функции внутри VM для того, чтобы View имел необходимый уровень доступа к модели. Подобная прослойка в виде VM между Model и View позволяет избежать некоторых неприятных моментов, когда приложение становится достаточно большим.
View
Что делает View?
- Рисует окна
- Создает и отрисовывает анимации
- Общается с VM
Здесь важно понимать, что MVVM подразумевает "реактивность" приложений. Это не MVC, где использовался императивный подход "отрисуй мне вот это ВОТ ЗДЕСЬ", это декларативный подход, где вы описываете какой именно результат вам нужен, а View уже сам как нибудь справляется с этим.
Реактивность подразумевает собой то, что наше приложение по сути является слушателем изменения состояний у отрисовываемых объектов. То есть, при любом изменении состояния отображаемой переменной (например текст, картинка), мы сразу же отображаем эти изменения. В Swift это называются ObservableObject, и он говорит View об изменении своего состояния, и в свою очередь View понимает что надо отобразить новое состояние.
Несколько советов
Если вы хотите влиться в разработку приложений, не столь важно android или iOS, для начала позаботьтесь о том, что вы освоили основы требуемого языка программирования, умеете работать с переменными, массивами, циклами, условными конструкциями и тд. Обеспечьте себе базис.
Смотрите лекции про разработку приложений на ютубе, параллельно занимаясь изучением языка. Никаких "я потом погуглю, когда дело дойдет". Это заведомо неправильный подход. Если что-то не получается, значит вы еще недостаточно опытны, и возвращаетесь к изучению основ. Не надо прыгать выше головы.
Залог успешного изучения подобных вещей состоит из нескольких шагов. Кратко я это назову условный "цикл разработки".
- Хорошие лекции по разработке непосредственно приложений (например, Стэнфордские, не знаю есть ли подобные для андроид, но наверняка есть)
- Как минимум одна книга (а лучше две), в которой описываются основы языка
- Вдумчивое чтение документации
- Практика, практика и еще раз практика
Как только с первыми двумя будет покончено, остается только 3 <--> 4. И так до бесконечности.
Если вы не знакомы с фичей, которую собираетесь реализовать, не надо копировать код со stackoverflow без понимания его работы. Лучше открыть отдельный проект и потратить лишние 4-6 часов на понимание работы данной конкретной фичи.
В достаточно сложном проекте, скорее всего, вам придется стыковать эту фичу с многими другими, и без понимания ее работы, скорее всего выйдет откровенно говоря не очень. А если придется менять что-то в дальнейшем? Вся разработка превратится в ад.
Тем, кто дочитал
Если есть желание, я могу постить больше материала отдельно про Swift. Если да, можете отписать коммент сюда, под статьей. В любом случае, я еще буду писать про создание приложений, моя тупая аппка на подходе и релизнется, надеюсь, в конце сентября - начале октября.
Это не означает, что я не буду писать про Python. Последний я использую по работе, для визуализации и анализа, и иногда появляется что то интересное. В плане анализа это замечательный язык, но писать на нем приложения глупо, не так ли?
Я бы так и тянул с этими статьями, но на днях мне написали из Cardsmobile. Оказывается, некоторые разработчики читают мой канал (отдельное спасибо им за это), и у них в планах делиться своим опытом разработки.
Вот их последняя статья на тему виджетов в iOS14.
Статья подготовлена и написана для канала Hello World 😉