Как разрабатывается мобильное приложение для стартапа?

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

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

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

В этой же статье разберем наш подход к мобильной разработке на Android и iOS, а в следующей статье, которая выйдет в эти выходные, - серверный API. Поделимся особенностями, которые возникают в связи с условиями стартапа и тематикой проекта, а также поговорим о принятых нами решениях при разработке.

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

Давайте с ними познакомимся:

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

Никита - Android разработчик. Пессимист, который практически никогда не пропускает дедлайны. Он, как и Сережа, тоже не имел огромного опыта за плечами в мобильной разработке, но освоился и выполняет даже крайне сложные задачи на ура.

Мобильное приложение - это ваш ключ к умному замку. Именно оно является одним из наших ключевых преимуществ в сравнении с аналогами. Мы ставим большой акцент на UX/UI и уже реализовали большое количество функций, способных раскрыть весь потенциал умного замка. О том, какой конкретно функционал мы реализуем и зачем он нужен, мы пишем в нашем ТГ канале по ходу его тестирования и доработки, а также зачастую советуемся с нашими читателями.

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

Но разработать мобильное приложение - непростая задача, к которой можно подойти по-разному:

1. Кроссплатформенная разработка. Flutter и React Native для бизнеса является самым простым способом разработать приложение сразу на обе платформы.

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

Обсуждать плюсы и минусы можно долго, вникая в каждый самый незначительный факт, но все всегда сводится к скорости и стоимости. И здесь понятное дело, что кроссплатформенная разработка выигрывает. Но почему у нас в таком случае все разрабатывается нативно?

На самом деле все до банального просто, а повлияло на это 2 фактора:

Далее Никита:

“ Я начал работу над проектом с построения xml-макетов, основанных на предоставленном дизайне в Figma. Этот этап стал для меня по сути новым опытом, поскольку до этого момента полноценно я не работал над созданием frontend для мобильных приложений, а специализировался backend-разработкой на Java. Работа с XML представила собой некоторый вызов, ведь сформировавшаяся привычка была к совершенно другим задачам.

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

Сейчас наше приложение написано на Java. До начала работы над этим проектом я имел серьезный опыт работы именно с Java. А с Kotlin опыта работы не было, из-за чего и был сделан изначальный выбор в сторону Java, так как проекту нужно было быстро начать разработку, чтобы MVP можно было показать экспертам на конкурсах и инвесторам.

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

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

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

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

Далее Сергей:

“ В iOS-разработку я попал достаточно спонтанно, поэтому пришлось учиться новому на ходу. Я еще не успел стать гуру Swift-приложений, поэтому пишу лишь о своём опыте, который накопился за это время, и о котором есть, что рассказать.

На данный момент существуют два основных framework’а для разработки пользовательских интерфейсов: UIKit и SwiftUI.

UIKit - проверен временем, хорошо изучен.

SwiftUI - напротив, новый и изучен далеко не так хорошо =D.

Существует и различие между подходами к разработке. Подробнее вы можете почитать, например, здесь.

Даже передовой Яндекс рекомендует для стажёров знание именно UIKit, а не SwiftUI. Это не значит, что SwiftUI плох, а скорее говорит о его распространенности в РФ. Но, например, в западных компаниях он уже применяется.

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

За первые дни разработки был почти полностью сделан рабочий UI первого приложения-прототипа. Если разбивать дизайн по слоям и искать в них соответствия по горизонтали или вертикали, то работа очень простая и быстрая. Что надо сделать горизонтально - пишем в VStack, что вертикально - в HStack. Иногда необходимо это комбинировать.

В SwiftUI огромное количество заранее предусмотренных шаблонов:

Swift крайне быстрый. ОЧЕНЬ приятно смотреть, как твое приложение абсолютно без тормозов и лагов буквально летает. Все менюшки открываются мгновенно, а плавные анимации переходов радуют глаз.

Но потом началось написание логики…

Постоянные вопросы к GPT с её часто случайными ответами, видео на ютубе и просмотр репозиториев состоявшихся программистов - это похоже на лотерею в моей ситуации. Иногда ты абсолютно сходу находишь нужный подход/инструменты, а иногда даже не знаешь, как сгенерировать запрос. Спросить, как будет лучше поступить в той или иной ситуации, мне опять же было не у кого, так как разработчиков на SwiftUI кот наплакал.

Иногда хочется быстро сделать какой-то прототип функционала, чтобы проверить, как он будет выглядеть и работать. Например, отображение информации о пользователе. Сначала на одном экране, потом на другом. Или проверить, что информация, изменившаяся на одном экране, поменяется на другом. Придя из мира С++, я думал, что здесь есть какой-то аналог глобальной переменной. Ну просто создадим себе что-то такое глобальное для теста, а потом уже сделаем что-то умнее :)

В SwiftUI нельзя просто так сделать себе глобальную переменную. Здесь есть понятие property-wrapper. Это модификатор переменной, который говорит, что у неё есть какое-то предназначение. Например, @State отслеживает любое изменение переменной. State-переменной описывается некоторое состояние экрана в моменте. Так вот, чтобы сделать аналог глобальной переменной для нескольких экранов, мы должны воспользоваться паттерном “наблюдатель”, но с “костылем”.

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

Очень ли это помогает? - Да.

Сколько нервных клеток ты потратишь, пока разберешься во всех тонкостях? - Много.

Оглядываясь назад, стал бы я сейчас учиться использовать SwiftUI, или всё-таки UIKit лучше? - Всё же встал бы на сторону SwiftUI.

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

А что Вы думаете про iOS-разработку в России и SwiftUI в частности? Очень жду интересной дискуссии в комментариях! ”

Пример того, почему наш подход позволил реализовать для сферы что-то новое:

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

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

При этом вы можете удобно и дистанционно управлять своими замками. В меню "Доступ" вы можете выбрать нужный замок и изменить настройки доступа к нему. Кроме того, здесь же можно будет посмотреть историю посещений.

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

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

На первый взгляд задача не кажется такой объемной, но чтобы ее реализовать, нужно было составить ТЗ по необходимому функционалу, продумать UX/UI, спроектировать базу данных серверной части для четкого контроля доступов с учетом иерархии ролей, и только после этого уже комплексно реализовать и протестировать весь оставшийся функционал.

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

Так что мобильная разработка в сфере IoT - это не шаблонные приложения, имеющие пару функций, а крайне интересная и напряженная работа со своими тонкостями. По крайней мере у нас.

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

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