Что нужно для разработки мобильного приложения компьютер сервер

Обновлено: 02.07.2024

В данной статье я, от лица нашей команды и студии разработки мобильных приложений It Lab, кратко опишу этапы разработки мобильных приложений так, как это заведено в нашей компании.

Почему только кратко? Все просто, если каждый этап расписывать очень подробно, то получится большая, большая, очень большая статья, поэтому я просто по мере добавления описания каждого этапа в отдельности, буду ставить ссылки на статьи, в которых описывается каждый этап.

Я не буду утверждать, что это эталон и только так оно должно и быть, поскольку сколько компаний-студий по разработке, столько и мнений как должно быть правильно, но а выбирать уже Вам.

В нашей команде приняты следующие этапы разработки мобильного приложения:

Аналитика.
Проектирование архитектур клиентской и серверной части мобильного приложения.
Разработка технического задания мобильного приложения.
Проектирование UX интерфейсов мобильного приложения и web части, если проект подразумевает под собой web интерфейсы.
Создание UI дизайна для экранов мобильного приложения и web интерфейсов.
Прототипирование и создание карты экранов проекта.
Разработка клиентской части проекта.
Разработка серверной части проекта и API.
Интеграция со сторонними сервисами.
Тестирование и отладка (фикс багов).
Подготовка проекта к публикации и публикация самого проекта.
Поддержка, сопровождение и развитие проекта.

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

Мы передаем все исключительные права на разработанный продукт, а также все материалы произведенные в результате разработки проекта. Все исходные коды, все варианты дизайн макетов - это априори, по умолчанию.

Давайте перейдем к каждому этапу разработки более подробнее.

Этап 1. Аналитика при разработке мобильного приложения.

Каждый наш клиент приходит к нам со своей идей будущего приложения. Кто-то говорит: "нужен аналог такого-то приложения", кто-то "нужен аналог, но не совсем 100%, с доработками и моим видением", а кто-то приходит с идеей мобильного приложения, которого еще нет на рынке в России, мире.

Вне зависимости от того, есть приложение на рынке, с которым к нам пришел клиент или его нет, но с каждым нашим клиентом мы заключаем NDA (договор о не разглашении), в котором наша ответственность выражена в сумме 5 000 000 рублей, а срок действия такого договора составляет 5 лет.

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

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

Что в результате: референсы по функциональности и дизайну, требование к технической части проекта (нагрузки, безопасность, стек разработки).

Кто участвует: PM (project menager), Аналитик.

Срок реализации этапа: средний срок реализации данного этапа, в нашей компании составляет 40 часов, что эквивалентно 1 рабочей неделе.

Этап 2. Проектирование архитектур клиентской и серверной мобильного приложения.

Большинство проектов, казалось бы не очень сложных, именно вот так и выглядят "под капотом" Большинство проектов, казалось бы не очень сложных, именно вот так и выглядят "под капотом"

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

По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов в проекте переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения.

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

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

В результате проектирования архитектуры "подкапотной" части проекта мы получаем решение где и каким образом будет распределен функциональный объем между клиентской и серверной частями, а также окончательно согласован стек применяемых технологий для back-end (серверная часть) и front-end (в данном контексте клиентская часть - мобильное приложение).

Кто участвует: PM (project menager), Аналитик, back-end разработчик, iOS, Android, DevOps разработчики.

Срок реализации этапа: средние временные затраты реализации данного этапа в нашей компании составляют примерно 40-80 часов, в зависимости от сложности проекта, что эквивалентно 1-2 рабочим неделям.

Наша студия (ИТ Лаб) занимается разработкой мобильных приложений iOS и Android любой сложности, для бизнеса и стартап проектов.

Разрабатываем приложения нативно (iOS - swift, Android - Kotlin)- 90% и кроссплатформенно (React Native)-10%.

Мы единственные кто на рынке предоставляет не банковскую рассрочку 0% на все услуги оказываемые нашей компанией до 12, а в индивидуальных случаях до 18 месяцев.

Этап 3. Техническое задание для мобильного приложения. Разработка.

Техническое задание на разработку мобильного приложения, пример из коммерческого предложения нашей компании. Техническое задание на разработку мобильного приложения, пример из коммерческого предложения нашей компании.

Я думаю, что Вы не раз сталкивались с данной пословицей и понимаете, что без четкого технического задания будет ровный результат, если он конечно будет. Команда должна четко понимать, что ей делать и какой конечный ожидаемый результат или словами бизнеса - видеть точку "Б".

Техническое задание это документ, который указывает разработчикам, что им делать, какие задачи и в какой момент времени реализовывать в проекте.

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

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

Пример на нескольких User Story из технического задания мобильного приложения (реальный наш кейс), содержащий варианты развития событий и их решения, и даже маленькую "пасхалочку" для очень ~~упоротых~~ упорных пользователей.

К сожалению, возможность форматирования текста на данной площадке не позволяет передать все полностью, но в прикрепленном примере, вы сможете увидеть, как текст форматирован в самом техническом задании.

ЭПН. Экран подтверждения номера телефона через смс код

ЭПН-1. Пользователь видит на экране
ЭПН-2. Пользователь вводит проверочный код из смс
ЭПН-3. Пользователь запрашивает повторно проверочный код
ЭПН-4. Пользователь нажимает кнопку “Продолжить”
ЭПН-5. Пользователь нажимает навигационную кнопку “Вернуться назад”

ЭПН-1. Пользователь видит на экране

ЭПН-2. Пользователь вводит проверочный код из смс

ЭПН-3. Пользователь запрашивает повторно проверочный код

Возможные варианты события:

Пользователь вводит не правильно проверочный код 1 раз.
Пользователь вводит не правильно проверочный код 2 раз.
Пользователь вводит не правильно проверочный код более 3х раз или после 2х повторных отправок новых проверочных кодов.
Пользователь суммарно делет уже 7 “повторный запрос”, за одну сессию, проверочного кода.
При переходе на экран сценария и отправки запроса на генерацию проверочного кода, отсутствует соединение с сервером = отсутствует интернет у пользователя.
При переходе на экран сценария и отправки запроса на генерацию проверочного кода, отсутствует интернет у пользователя.

ЭПН-4. Пользователь нажимает кнопку “Продолжить”

Возможные варианты развития событий:

Возможные варианты развития событий, равно как и их решения описаны в сценарии ЭПН-3. Пользователь запрашивает повторно проверочный код

ЭПН-5. Пользователь нажимает навигационную кнопку “Вернуться назад”

Пользователь нажимает на кнопку “Вернуться назад”, согласно ос устройства.
Пользователь возвращается на ЭВНТ. Экран ввода номера телефона
Введенный код, если поле заполнено не сохраняется.

Особенности ос Android

При создании технического задания, мы на 80% создаем и тест кейсы для тестировщиков (QA).

Во время разработки и работы над продуктом, в созданное тех.задание добавляется информация от разработчиков, в итоге, по готовности проекта, техническое задание перестает в полноценную документацию проекта.

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

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

Здесь можно скачать пример (выдержку из реального тз) технического задания на разработку мобильного приложения, оформленный в виде КП.

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

Что в результате: полноценный документ для команды разработчиков. имеющий в себе прототипы в формате sketch основных экранов приложения и web интерфейсов для визуализации процессов. Архитектуру проектов, основные методы запросов. Описанную бизнес логику проекта.

Кто участвует: PM (project menager), Аналитик, Технический писатель.

Срок реализации этапа: средний срок реализации данного этапа, в нашей компании составляет 100-160 часов, что эквивалентно 2,5-4 рабочих недели.

Уффф, что-то я погорячился, видимо, решив описать все 12 этапов разработки мобильного приложения принятых в нашей компании. Что-то уже из первых трех пунктов получилась не маленькая статья. Поэтому, видимо придется делать цикл статей и публиковать их частями.

Часть 2. Этапы разработки мобильного приложения будет жить здесь (как будет опубликована, сразу поставлю ссылку).

Разработка мобильных приложений iOS и Android любой сложност. Для бизнеса и стартап проектов.

Разрабатываем приложения нативно (iOS - swift, Android - Kotlin)- 90% и кроссплатформенно (React Native)-10%.

Мы единственные кто на рынке предоставляет не банковскую рассрочку 0% на все услуги оказываемые нашей компанией до 12, в индивидуальных случаях до 18 месяцев.

Задавайте свои вопросы в комментариях или критикуйте, мы всегда открыты к диалогу и конструктивной критике :-)

Понравилась статья? Оцените ее, вам не сложно, а мне приятно и будет стимул писать еще :-)

Требования

Особенностью является то, что формируются требования и для серверного, и для клиентского приложения, которые в ряде случаев взаимосвязаны. Для начала опишу базовые требования в контексте механизма обмена данными:
• кроссплатформенность клиента: зачастую важно обеспечить поддержку разных платформ — Android, iOS, Windows Phone и пр. Редко заказчик довольствуется одним видом устройств.
• быстродействие: должна обеспечиваться достаточная для workflow скорость работы, комфортный отклик на графическом интерфейсе пользователя;
• простота: чем проще API протокола, тем меньше времени уходит на реализацию и поддержку кода, тем меньше может быть квалификация разработчика;
• эффективность: чем сложнее реализация протокола, тем больше потребляется ресурсов мобильного устройства, которые ограничены.

Команда

Состав проектной команды для разработки системы в идеале может быть следующим:
• менеджер проекта: управляет, контролирует проект, напрямую взаимодействует с заказчиком;
• разработчик серверного приложения: разрабатывает сервер бизнес логики, базу данных, сетевой протокол;
• разработчик приложения администратора: разрабатывает Web приложение, пользовательский интерфейс для настройки и управления серверным приложением;
• разработчик клиентского приложения для Android;
• разработчик клиентского приложения для iOS;
• разработчик клиентского приложения для …
• тестировщик: тестирует приложение администратора и клиентские приложения.

Внимательный читатель заметит, что в случае написания серверного приложения с графическим интерфейсом, например, на HTML5, можно сэкономить. В этом случае не требуется разработка клиентских приложений – интерфейс пользователя предоставляет браузер. Данная статья не рассматривает такой случай, идет речь о разработке ”родных” (native) приложений для мобильных устройств.

Мне доводилось работать в команде с полным составом, но будет реалистами – не всегда человеческие ресурсы и бюджет позволяет собрать такую команду. И иногда роли приходится совмещать: менеджер проекта + разработчик серверного приложения, разработчик клиентского приложения + тестировщик.

Технологии, инструменты, библиотеки

Для разработки сервера мобильных клиентов обычно использую следующий стек “свободных” технологий:
• Apache Tomcat – контейнер сервлетов;
• MySQL – СУБД;
• Subversion – система версионного контроля;
• Maven – фреймворк для автоматизации сборки проектов;
• JUnit – обеспечит эффективность автоматического тестирования приложений;
• Apache Log4j – библиотека логгирования;
• Jenkins – система непрерывной интеграции;
• Hibernate – ORM (настройки, конфигурация в properties, xml файлах и в аннотациях);
• hibernate-generic-dao – реализация DAO от Google, реализует основные методы для работы с данными базы данных, упрощает реализацию фильтрации и сортировки в методах;
• Spring – реализация аутентификации и авторизации (security), контейнер сервисов и бинов (конфигурация в xml файлах и в аннотациях), используем также при создании тестов.

В зависимости от специфики системы и требований к ней использую один из 2-ух вариантов реализации протокола обмена данными.
Когда требуются кроссплатформенность, быстродействие, простота, эффективность, масштабируемость, открытое API, то беру Jersey – реализацию Web-сервисов REST (RESTful Web services). Эта библиотека позволяет использовать сериализацию данных в формате JSON или(и) XML. Конфигурация REST ведется посредством аннотаций. Для обмена с мобильными устройствами взят формат JSON по причине того, что имеет более простую реализацию на стороне клиента (по этой причине не используем “классические” Web-сервисы), генерируется меньший объем трафика. Jersey позволяет настроиться на наиболее подходящий “вид” JSON.
В ином случае, если необходимы кроссплатформенность, высокое быстродействие, простота, эффективность, интерактивность, то беру
• Apache MINA – framework для создания сетевых приложений,
• Google protobuf – библиотека кодирования и декодирования структурированных данных. Структура данных определяется заголовочными файлами *.proto, компилятор генерирует из них Java классы (также есть возможность генерации для других языков программирования: C++, Objective-C и т. д., что обеспечивает свойство кроссплатформенности);
• java.util.concurrent – используем стандартный пакет.
Данный вариант может масшабироваться, но на это требуется закладываться на этапе проектирования на уровне архитектуры, учитывая бизнес логику.

Рассмотрим гипотетическую задачу на примере выбора технологий для реального SaaS сервиса – “Аукцион услуг “Аукнем”, который позволяет людям сформировать заказ на выполнение требуемых услуг или работ, а организациям в свою очередь оставить для них свои предложения. Берем все базовые требования по умолчанию. Ввиду того, что регистрация в этой системе свободная и бесплатная, то однозначно к ним требуется добавить масштабируемость. А что на счет интерактивности? Было бы здорово сообщать подрядчикам (исполнителям) о создании новых заказов, а заказчиков информировать о поступивших предложениях в тот же миг в приложении, а не только по электронной почте. На основания этого возьмем для реализации Apache MINA, Google protobuf. Смотрим следующее свойство — открытое API. Сервис общедоступный, потому предположим, что внешние разработчики могут проявить интерес к интеграции с ним. Постойте! Не все так просто. Протокол на базе Apache MINA достаточно сильно зависит от реализации и интеграция без знания нюансов отнюдь не прозрачна. В такой ситуации придется взвесить, какой фактор важнее и сделать выбор.

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

Какими бывают мобильные приложения

Существует три подхода к созданию мобильных приложений:

Традиционный. Предполагают написание кода, создание макета, оптимизацию, команду и другие этапы.
Зерокодинг. Не требует знания языков программирования. Это похоже на использование Тильды (это тоже, кстати, инструмент зерокодеров) для создания сайтов: не надо знать CSS, HTML, JS — просто расставляешь блоки с контентом, настраиваешь анимацию и получаешь отлчиный сайт.
Low-code — это что-то среднее между зерокодингом и программированием: писать код все-таки приходится, но немного.

Инструменты зерокодинга уже могут покрыть большинство задач бизнеса. И вместо того, чтобы изобретать велосипед, можно за несколько дней запустить MVP или проверить гипотезу с минимальными затратами. А если в запасе хотя бы пара недель — то и запилить полноценное приложение. Решения на зерокодинге можно собирать в одиночку — вся инфраструктура предоставляется платформами и не надо дополнительно тратиться на хостинг, администрирование серверов и т.п.

При этом обычная разработка затянется на 3−6 месяцев и съест до миллиона рублей — если работать с фрилансером или скромной региональной студией.

На курсе «Зерокодер мобильных приложений» ты научишься создавать приложения под iOS и Android. Простые — за 1−2 дня, сложные — за 1−2 недели. Курс состоит из 5-и модулей, 30+ уроков, тренировочных задач и Q&A-сессий с лучшими экспертами в Glide и Adalo.

На чем собирают мобильные приложения без кода

Самые мощные и популярные инструменты мобильной разработки без кода — Adalo, Glide и Bubble. С их помощью можно создать и опубликовать мобильное приложение. Они бывают трех типов:

Мобильная версия сайта — сайт в интернете, адаптированный под экраны смартфонов. Это самый «бесправный» тип приложений: всегда нужен интернет, пуши можно включать только в браузере, постоянно на виду элементы навигации браузера.

PWA (Progressive Web Application) — когда мобильная версия сайта устанавливается на смартфон как приложение. Из плюсов — не надо поддерживать две кодовые базы, под iOS и Android, приложение всегда «обновлено» до последней версии, можно работать с некоторыми нативными функциями смартфонов. Например, отправлять пуши, устанавливать ярлык на экран, элементы навигации браузера не мешают (их просто нет). такие приложения умеют создавать и Bubble, и Adalo, и Glide.

Нативные — когда приложение публикуется в официальных сторах. В Adalo уже встроена такая функция, а приложения на Bubble можно обернуть в специальный контейнер и тоже опубликовать в Google Play и App Store. Нативные приложения позволяют работать со всеми функциями телефона: камерой, микрофоном, GPS, контактами, файлами, акселерометром, push-уведомлениями, памятью девайса, адаптивной версткой — всё, как в обычном коде, только без кода.

Glide

по макияжу по подписке. аренды жилья в Вене. фотошколы. наставников в Digital.

Glide — платформа для создания мобильных приложений без кода. Лучше всего функции сервиса описывает девиз «Создавайте приложения из Google Sheet за пять минут, бесплатно». Glide-приложения нельзя загрузить в сторы, но можно опубликовать в интернете как PWA. Платформа отлично подходит для создания простых приложений и MVP — много готовых симпатичных шаблонов, понятные интуитивные настройки.

На бесплатном тарифе есть ограничение по объему данных, 10% комиссия со всех платежей и лого Glide, а платные стартуют от $12 в месяц.

Adalo

Индийский headhunter для педагогов

Adalo — nocode-платформа для создания веб- и мобильных приложений, которые можно публиковать в App Store, Google Play или в интернете как PWA. Новая версия раскатывается в сторы прямо из личного кабинета на платформе, публикуется тоже оттуда (но нужен аккаунт в AppStore и Google Play). Adalo позволяет создавать приложения в интуитивно-понятном интерфейсе методом drag’n’drop из готовых или кастомных дизайн-шаблонов. Эта платформа мощнее Glide и на ней можно собирать более сложные приложения.

На бесплатном тарифе нет ограничений по количеству приложений, а вот количество данных фиксировано — плюс придется «потерпеть» лого платформы. Платные тарифы стартуют от $50 в месяц и дают возможность публиковаться в сторах.

Bubble

для геймификации карьеры мобильных сайтов для рестораторов

Bubble — одна из самых продвинутых визуальных сред программирования для создания веб-приложений. На нем можно собирать настольные или адаптивные веб-приложения для любого размера экрана.

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

На бесплатном тарифе тоже есть лого платформы, нельзя привязать приложение к своему домену, количество объектов в базе данных ограничено 200 и закрыт доступ к API. Платные тарифы начинаются от $25 в месяц.

Экспресс-сравнение платформ

Мобильный зерокодинг и традиционная разработка: стоимость и сроки

Разработка приложения «под ключ» — сложный процесс, в котором участвует целая команда специалистов. Программисты пишут бэкенд и фронтенд, дизайнеры создают «человеческий» UX/UI и вкусную картинку, тестировщики ищут ошибки, проджекты управляют всем процессом, лиды — командами, эккаунты общаются с клиентами. И каждый не просто просиживает штаны, а действительно работает и нужен.

Сколько денег возьмет за разработку веб-студия и сколько времени потратит, зависит от сложности проекта и имиджа компании, но в среднем — от 500 тыс. до 5 млн рублей, а средний срок разработки — 4−6 месяцев (по сведениям с Хабра, DTF и Appinventive). Сложные приложения легко могут стоить дороже 10 млн рублей и пилиться больше года — особенно если поджимают сроки или подрядчик входит в какой-то рейтинг вроде Теглайна. И всё это без учёта поддержки, обновлений, продвижения и возможных проблем с масштабированием и доработками.

Nocode-разработка обходится дешевле. Например, Сергей Горелов в одиночку собрал полнофункциональное приложение для фитнес-клуба за пару недель — такое же приложение обычная студия будет разрабатывать около полугода и возьмёт за работу 700−800 тысяч рублей.

А Евгений Спорыхин из nocode Hero вместе с WeLovEnocode запилил карьерный трекер с геймификацией на Bubble. Вместе с детализацией техзадания, доработками, дополнительными функциями и пятью итерациями по дизайну (клиент не совсем понимал, какой он хочет видеть визуальную составляющую) это заняло три месяца и обошлось заказчику примерно в 700 тысяч рублей.

Аналогичная работа «в коде» длилась бы гораздо дольше, а заказчик отдал бы не меньше 4 млн рублей. При этом первую полнофункциональную версию запустили уже через 2 недели — всё остальное ушло на доработки дизайна и добавление новых идей клиента.

Да, у мобильных приложений на зерокодинге пока есть некоторые ограничения: например, чтобы сделать массовый сервис с трафиком в десятки миллионов человек, когда критичны скорость работы и премиальный дизайн, придется создавать свое решение, нанимать программистов или отдавать разработку на аутсорс. А вот первые версии такого продукта — особенно MVP — можно собирать и без кода. Приложения на несколько десятков или сотен тысяч пользователей nocode-платформы также выдержат без проблем.

Снижение стоимости мобильных приложений неизбежно привлечет массовую категорию новых клиентов — теперь приложение может себе позволить даже скромный ИП-шник или владелец пары овощных киосков.

Примеры мобильных приложений без кода на Glide

MAKE. Мобильная методичка по макияжу по подписке на Glide

Платформа: Glide
Время на разработку: 2 недели (большая часть — наполнение базы данных)
Затраты: 12$ (базовый тариф в Glide)

Игорь — профессиональный программист. Как-то раз ему понадобилось выполнить техническую задачу за пару дней — так он вошел в зерокодинг. Сначала автоматизировал на Integromat, потом перешел на Glide. А в пандемию он назерокодил приложение для обучения макияжу MAKE — помогал жене перевести бизнес в онлайн.

Игорь освоил Glide за три дня, еще 4 дня делал структуру приложения. Дольше всего вносил список из 400 продуктов — это заняло 2 недели😂 Приложение интегрировано с ЮKassой, Integromat и GetCourse, можно выбрать свой цветотип, форму лица и глаз, найти инструменты и средства для макияжа, а также получить советы — где их лучше купить, чтобы не попалась подделка.

Цепочка проверки оплаты в Integromat

Если пользователь оплатил подписку с помощью банковской карты, информация о ней сохраняется. За 3 дня до окончания подписки пользователя предупредят о предстоящем списании. После автооплаты система пришлет результат — успешно прошло списание или денег на карте не оказалось. Эта логика собрана на GetCourse.

Настройка автооплаты и цепочки уведомлений в GetCourse

WOM. Airbnb для аренды квартир в Вене

Платформа: Glide
Время на разработку: 70 часов
Затраты: 12$ (базовый тариф в Glide)

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

Когда Олег нашел способ арендовать жилье без посредников, к нему пришла идея мобильного приложения.

WOM — это площадка, которая помогает найти и забронировать жилье в центре Вены напрямую у владельца. Если уже пользовались Airbnb, то и в WOM разберетесь. У приложений даже схожие интерфейсы — чтобы пользователи не переучивались и заново не привыкали к новому меню.

Сервис разработан на Glide — платформе мобильной none-code разработки. Через веб-интерфейс разработчик редактирует визуал, а с данными работает в подключенной Google-таблице, которая выполняет роль базы данных. Создатели Glide говорят, что простейшие приложения можно собрать за 7(!) секунд.

Интерфейс Glide

WOM получился полноценной площадкой с каталогом квартир, картой, разделами «Вам может быть интересно» и «Сейчас просматривают». Олегу понадобилась ночь на изучение интерфейса Gilde и 2-3 дня на создание экранов и заполнение базы данных.

Экраны в WOM

WOM хоть и разрабатывалось любителем, но выглядит красиво и современно. Это еще одно достоинство none-code приложений: разработчик имеет дело только с готовыми шаблонами. Поэтому получается профессиональный дизайн без услуг художника. Сейчас актуальная версия на немецком тестируется в Вене.

Проекция. Онлайн-фотошкола с элементами соцсети и админкой

Платформа: Glide
Время на разработку: 3 недели
Затраты: 12$ по базовому тарифу

Еще один пример удачного приложения, собранного без кода — обучающая платформа «Проекция». Ее разработал Илья Ткач для сообщества фотографов «Фотодепартамента».

«Проекция» — приложение для учеников одноименной онлайн-фотошколы. В нем ученики делают домашние задания, получают оценки и общаются друг с другом в тематических чатах. Администраторы приложения размещают обучающие материалы и упражнения через панель управления. Можно оформить подписку и получить доступ к закрытым материалам и курсам.

Есть задания в виде тестов (чек-листы) и такие, к которым нужно приложить фото или написать развернутый ответ. Преподаватель видит результаты и выставляет оценки. Учеников, которые сделали задание лучше других, можно хвалить «знаком отличника».

Благодаря приложению и сообществу ученики сильнее погружаются в обучение, а преподавателям проще размещать материалы и общаться с учениками. Каталог учеников и чаты помогают фотографам нарабатывать профессиональные связи.

Примеры мобильных приложений без кода на Adalo

Kangoo Club Kaluga. Приложение для фитнес-клуба с расписанием, записью и бронированием униформы

Платформа: Adalo
Время на разработку: 2 недели
Затраты: 12$ по базовому тарифу

Сергей — владелец веб-студии и ни разу не писал код. Но в конце прошлого года с помощью Adalo за две недели назерокодил полноценное мобильное приложение для одного необычного фитнес-клуба и загрузил их в сторы.

Особенность клуба в том, что для тренировки нужно арендовать специальные ботинки Kangoo: их ограниченное количество, и может не достаться нужный размер. Поэтому нужно было создавать своё приложение.

Внутри приложения есть онбординг новых пользователей, личный кабинет для оплаты кампаний на самых популярных площадках с бонусами, календарь тренировок и бронирование обуви, запись и отмена записи на занятия, социальные механики, push-уведомления, админка для сотрудников клуба, профиль клиента с информацией об абонементе.

Приложение Kaluga Kangoo можно скачать в App Store и Google Play.

Пример мобильного приложения без кода на Bubble

Ornum. Мобильное приложение для геймификации обучения и личного развития

Платформа: Bubble
Время на разработку: 3 недели
Затраты: бесплатный тариф Bubble

Еще год назад Евгений управлял SMM-агентством и не думал, что скоро будет собирать полноценные мобильные приложения. Вместе с WeLoveNoCode он сделал Ornum — приложение для управления карьерой.

Само приложение Евгений собрал в одиночку — 2−3 недели, после этого его упаковали в специальные контейнеры, чтобы загрузить в App Store и Google Play. На сегодняшний день это самое крутое мобильное приложение на Bubble от российских разработчиков, которое мы встречали.

В Ornum реализована сложная и интересная бизнес-логика: большая база данных с 49 скилами и связями между ними, настроена система управления краткосрочными и долгосрочными целями, есть механика ежедневных заданий, а также красивые дашборды и дорожные карты навыков — всё это генерируется автоматически и сделано без кода.

Настройки механик геймификации мобильного приложения в редакторе Bubble

Революция в мобильной разработке

Зерокодинг — отличный способ создать настоящее мобильное приложение, которое по визуалу и функциям не уступает традиционным решениям, но выигрывает в скорости и стоимости.

В мобильной разработке сейчас происходит то же, что и в создании сайтов в 2014−2015 годах. Технологии быстро развиваются и становятся доступными — это даёт хороший запас маржинальности в коммерческих и личных проектах. Gartner прогнозирует, что к 2024 году 65% разработки всех приложений перейдет на no- и low-code — так что прямо сейчас мы наблюдаем революцию в разработке.

Те, кто поверил в новые технологии, уже сейчас зарабатывают на мобильной разработке без кода от 300 тыс. руб. в месяц на 2−3 проектах. Это золотое время — и оно скоро может закончиться. Сейчас один человек может составить конкуренцию студиям мобильной разработки со штатом программистов и дизайнеров: nocode-разработка занимает меньше времени, а себестоимость проекта снижается до 50 раз.

Конечно, собирать серьезные приложения уровня Сбера или Яндекс Go на зерокодинге не стоит, а вот для создания приложений в малом и среднем бизнесе или MVP для стартапов и даже технологических гигантов это отличный подход.

Давид Григорян — эксперт в сфере разработки мобильных приложений на платформе iOS, главный инженер по разработке в Сбербанке. Он принимает активное участие в развитии сообщества, выступает на конференциях и публикует тематические материалы.

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

Востребована ли профессия мобильного разработчика? Легко ли найти работу в этой сфере?

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

Даже в докоронакризисные времена на рынке была нехватка в мобильных разработчиках. Сейчас ситуация стала намного острее.

Согласно исследованиям, в России число специалистов в области мобильной разработки оценивается в 25-30 тыс. человек. Для тех предложений, которые есть на рынке, этого мало. Разница в зарплатах в этой области может составлять от 100 до 200 тыс. руб. для одной и той же позиции.

Из всего вышесказанного выходит, что найти работу для начинающего специалиста, имеющего пару-тройку проектов портфолио, не составит труда. К тому же формат удалёнки становится неотъемлемой частью в IT, а программ стажировок от крупных компаний становится всё больше.

Какие направления существуют в мобильной разработке? Есть ли смысл осваивать кроссплатформенные решения?

Существуют три основных направления в мобильной разработке: Android, iOS и кроссплатформенные решения (Flutter, React Native, PhoneGap).

Старт 22 ноября, 4 месяца, Онлайн, От 35 000 до 100 000 ₽

Для Android-разработки используются языки Kotlin и Java, для iOS — Swift и Objective-C. Ещё несколько лет назад основными языками для Android и iOS были Java и Objective-C. Однако с появлением новых языков многие проекты, в том числе крупных IT-компаний, стали использовать современные решения. Сейчас начинающему специалисту достаточно владеть знаниями об основной платформе, на которой он разрабатывает (iOS или Android), а также одним из новых языков программирования (Swift или Kotlin).

Нужно исходить из требований того региона, в котором вы собираетесь искать работу. Например, если вы живёте и собираетесь работать во Владивостоке, где основные вакансии по iOS требуют знания Swift, то очевидно, что изучение Objective-C будет неоправданным.

Кроссплатформенные решения в России не так востребованы как нативные (родные). Но у них есть своя ниша. В основном это стартапы, которые требуют минимальных вложений для реализации задуманной идеи на обеих платформах.

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

Сравниваем подходы нативной и кроссплатформенной мобильной разработки в 2021 году

Какие основные роли и задачи мобильного разработчика?

Разработчик в целом — это не только тот, кто набирает код на клавиатуре. Это специалист, который понимает конкретную бизнесовую проблему, которую ему необходимо решить с помощью этого кода. Мобильный разработчик — не исключение. Единственное отличие — это понимание особенностей мобильных технологий в целом (таких как push-уведомления, ограничения скорости интернета, зарядки и памяти).

Очевидно, что мобильные приложения — это та же фронтенд-часть приложения. Соответственно, отсюда вытекают стандартные задачи и проблемы: поддержка вёрстки для большинства девайсов, необходимость учитывать версии операционных систем и т.д.

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

Мобильные приложения могут выступать как:

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

Как стать разработчиком мобильных приложений?

Если мы говорим про случай, когда у человека нет знаний и опыта в программировании, то стоит для начала изучить:

один из языков программирования (Kotlin или Swift),
саму платформу (Android или iOS),
объектно-ориентированное программирование,
алгоритмы и структуры данных (без фанатизма, только основные принципы).

Также нужно обязательно научиться гуглить. Кому-то этот совет может показаться оскорбительным, но это не так. Программисты всех уровней и мастей гуглят, без исключений. Умение правильно задать вопрос — навык, который потребуется и в дальнейшей работе с коллегами, если этот вопрос нужно будет адресовать им.

Стоит оговориться, что для начала разработки под iOS необходимы устройства от Apple. Как минимум нужно приобрести бюджетный Mac mini или MacBook на вторичном рынке. Для изучения одного из языков программирования и изучения самой платформы подойдут основные туториалы на сайте Apple или Android. В идеале — найти ментора, который поможет на первоначальном этапе и выстроит план обучения. Курсы тут тоже будут кстати, но не стоит надеяться, что после простого их прослушивания всё станет очевидным и понятным.

Достичь успеха получится, если заниматься самостоятельно, делая домашние задания и разрабатывая собственные мини-проекты, которые в дальнейшем станут отличным портфолио для поиска первой работы.

Какие ошибки чаще всего совершают новички?

Многие новички совершают ошибки при изучении новой области. Я не был исключением.

Насколько сложно войти в мобильную разработку в отличие от смежных направлений, например, веб-разработки?

Есть мнение, что вход в мобильную разработку сложнее, чем в тот же веб. Но я не согласен с этим аргументом. Для освоения веб-технологий как минимум потребуются знания о том, как работает интернет в целом, как действуют основные протоколы взаимодействий между клиентом и сервером. Добавьте сюда HTML/CSS/JavaScript, один из серверных языков (PHP/Python/Java/Go/Ruby), SQL и много чего ещё интересного. Это вовсе не значит, что мобильному разработчику не нужно понимать, как работает интернет, или иметь представление о смежных технологиях. Но это всё-таки не основной стек технологий, с которым специалисту нужно будет иметь дело изо дня в день.

Как известно, во фронтенд в целом легко входить, но сложнее поддерживать себя в форме. Обновления инструментов для разработчиков Apple и Android-платформ, выходят ежегодно, их нужно изучать и применять. Похожая ситуация и с JS-фреймворками для фронтенд-разработчиков.

Останется ли мобильная разработка востребованной в ближайшие годы?

Конечно, мобильная разработка останется востребованной. Несмотря на очевидную стагнацию в выпуске новых фич для смартфонов, ими всё равно продолжает пользоваться огромное число людей по всему миру. И большинство задач тоже будет решаться с помощью устройства, которое находится у вас в кармане. Как минимум в ближайшие 10-15 лет.

Читайте также: