Стек технологий android разработчика

Топовый стек: Backend и Frontend для мобильного приложения

Мини-обзор без референсов

Ingredients

Directions

Node.js (бэк) + React Native (фронт)

Одна из наиболее сильных связок в качестве стека для разработки приложения. React Native — это кроссплатформенный фреймворк, который можно отнести к флагману мобильного девелопмента. С его помощью были написаны или переписаны на React. Между прочим, инста — это настоящий хайлоад : за один месяц приложение посещает 1 миллиард активных пользователей, более 500 миллионов используют его ежедневно. Даже Tesla использует этот фреймворк для мобильного приложения по управлению автомобилем

Мобильное приложение React с API-интерфейсом Node.js работает через Java Scrtipt как на веб-интерфейсе, так и на бэкенде. Это позволяет писать действительно нативные приложения — React переводит весь написанный JavaScript-код на «родной» язык конкретного устройства, например Java на Android или Objective-C на iOS, а для стилизации можно использовать даже CSS-код

Python (бэк) + Kotlin (фронт)

Довольно интересная связка, где в качестве бэка используется Python (работа с БД), и языком программирования Kotlin в качестве графической оболочки (GUI). В Pynhon есть бесплатные фреймворки для разработки мобильных приложений (Kivy или Beeware), но как «фронт» питон для программирования UI приложений не очень удобен (здесь как раз подойдет Kotlin), зато его можно задействовать в бэкенде, т.к язык располагает к жонглированию больших объёмов данных и применению машинного обучения (не зря же его используют в Data Sciense).

Один из самых известных фреймворков Django как раз написан на Python

Котлин же как раз очень удобен в плане разработки интерфейса, благодаря user-friendly синтаксису и получивший полную поддержку установочных пакетов Google и IDE, включая Android и SDK.

Laravel + Flutter

Флаттер — крутой инструмент разработчика UI для создания красивых и нативных приложений на всех платформах — десктоп, мобайл, веб. Среда Flutter используется как единая база кода, которая компилируется в собственный код для iOS и Android. Flutter довольно давно снискал популярность среди западных front-end разработчиков. У нас же в стране хоть и хвалят его за упрощенный процесс верстки, но пока не пользуется большим спросом.

Lavarel — фреймворк, работающий на бэке. С его помощью, используя API, можно писать «классические» серверные функции — учетные записи пользователей, управление заказами и т.д.(например, авторизация делается с помощью Laravel Passport). Он имеет открытый исходный код и имеет ряд функций для упрощения разработки и автоматизированными тестами.

Источник

Как мы обновляли мобильное приложение для официантов: выбор стека и тест трех версий. Кто победил?

Привет! Меня зовут Сергей Арсёнов, я руковожу мобильной разработкой в компании r_keeper. Хочу рассказать, как мы обновляли мобильное b2b-приложение для официантов и почему выбрали для него не совсем классический стек — Kotlin Multiplatform Mobile + UI на Flutter.

На чем писать?

Наше мобильное приложение используют официанты в ресторанах, где установлена система автоматизации r_keeper: оформляют через него заказы, добавляют и удаляют блюда, принимают оплату и т. д. Когда-то давно оно было написано на Java + Objective-C + WebView и заметно устарело: функциональность для iOS и Android полностью дублировалась, обе версии выглядели абсолютно одинаково, нативной верстки не было. Приложение с трудом поддавалось улучшениям, и в конце концов мы решили переписать его с нуля. Вопрос — на чем?

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

Нужна технология, которая позволит не писать одну и ту же логику несколько раз под разные платформы (тем более для b2b-приложения, где UI и функционал для всех ОС идентичен). Получается, чистый натив не оптимален — нужна кроссплатформа.

Это должна быть кроссплатформа, которая позволит сделать приложение для iOS, Android, а в перспективе и под web / desktop. К тому же нужно уметь поддерживать работу с платформой и железом, поскольку такие задачи могут возникнуть — PWA по этой причине выбыл. Выбыл и Xamarin — он не поддерживает web и вообще не очень быстр. Список сузился до нескольких вариантов: Flutter, React Native, KMM + UI на чем-нибудь (например, NativeUI) и Cordova.

У кроссплатформы должен быть низкий порог входа для Android-разработчиков — это тот ресурс, которым мы располагали. Javascript они не знают — из-за этого выбыли React Native и Cordova.

Какие плюсы и минусы?

В результате до финиша дошли варианты Flutter и KMM + NativeUI с какими-то комбинациями. Все — со своими достоинствами и недостатками.

Во Flutter используется незнакомый язык Dart (правда, сильно похожий по синтаксису на известный каждому Android-разработчику Java) и декларативная верстка. Для Android-платформы декларативный Jetpack Compose еще не стал нормой, так что был риск, что этот вариант построения интерфейса снизит темпы разработки (как минимум на первоначальном этапе). Не было уверенности, что неопытный в этой технологии разработчик сможет качественно выстроить архитектуру и написать бизнес-логику. Мы также опасались, что кроссплатформа не позволит полностью реализовать все специфические особенности каждой платформы, вроде работы с push-уведомлениями или железом. Были сомнения и в достаточной производительности Flutter на слабых устройствах (такие нередко встречаются у корпоративных клиентов). Притом мы понимали, что у технологии есть свои преимущества: относительная зрелость Flutter SDK, единый язык и код для всех платформ и вариантов. К тому же поддерживал энтузиазм разработчиков, которым хотелось «пощупать» новую технологию.

У варианта KMM + Native UI — много достоинств: это знакомый всем Kotlin, знакомый всем Android UI, плюс возможность вынести любой специфичный функционал в нативную часть. Минусом мы посчитали то, что UI пришлось бы писать на Swift и делать двойную работу по слою представления (а работать с Xcode не хотелось никому) — это грозило увеличением сроков разработки. Кроме того, технология KMM еще недостаточно зрелая — могли возникнуть проблемы.

Можно было попробовать гибрид Flutter + KMM, но тут тоже были потенциальные «грабли». Мы не знали, как смогут общаться KMM и Flutter и насколько сложно будет собрать проект из таких непохожих частей. Правда, такая связка позволила бы не писать сложную логику на Dart и вообще делать UI только один раз, а все сложные вещи привычно написать на Kotlin.

Три версии на тест

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

Версию № 1 написали на чистом нативном Android (Clean Architecture, Android Jetpack, MVVM, Coroutines, Koin), № 2 — на KMM + Native UI, № 3 — на KMM + Flutter. Делать отдельное приложение на чистом Flutter не стали, потому что версия № 3 позволяла оценить и этот вариант.

Время и сложность создания нативного приложения (версия № 1) мы взяли за эталон для сравнения. Трудностей с его разработкой не возникло, создание с нуля заняло примерно одну неделю. Приложение, в соответствии с концепцией чистой архитектуры, было разбито на три слоя: представления, бизнес-логики и слоя данных.

Для переписывания приложения на KMM (версия № 2) было необходимо следующее.

Перенести слои Data и Domain в кроссплатформенную часть
Для слоя Data пришлось переписать базу данных со стандартного Jetpack’овского Room на кроссплатформенный SQLDelight. Последний требует, чтобы таблицы и методы для общения с ними были описаны на варианте чистого SQL, путем создания .sq-файлов — при сборке именно по ним генерируются методы для обращения с базой данных. Готовых инструментов для миграции из Room в SQLDelight мы не нашли, так что пришлось вручную переносить сгенеренные таблицы из Room и писать SQL-запросы для методов — это заняло пару дней.

Еще мы переписали сетевую часть с Retrofit на Ktor (сериализацию делали через kotlinx.serialization). Тут особых сложностей не возникло: для логики интерфейс общения с бэкендом остался прежним, была изменена лишь имплементация. Вообще для большей гибкости на Ktor можно использовать не только кроссплатформенные, но и нативные движки, например, OkHttp, но для наших целей хватило дефолтного.

Слой Domain, естественно, перенесся в KMM без каких-либо изменений.

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

Изменить слой представления для Android-версии, поменяв способ общения с логикой
Потребовалось лишь переделать ViewModels для общения с логикой через изменившиеся интерфейсы

Написать UI-часть под iOS
KMM собирается как обычный Framework-пакет для iOS. Особых сложностей с этим не возникло — надо было лишь подключить эту библиотеку и написать стандартный UI на Swift, который вызывает из нее методы.

В целом переделка проекта заняла около двух недель (не считая написания iOS UI), в основном оно ушло на знакомство с новыми библиотеками. Подводных камней на этом этапе мы не увидели.

Третьей и самой интересной стала версия № 3 на Flutter + KMM. Часть KMM с логикой бизнес-и дата-слоев без каких-либо изменений была перенесена из версии № 2 — нам потребовалось лишь написать UI на Flutter.

Серьезные опасения насчет падения производительности при передаче больших массивов объектов между UI и KMM не оправдались — версия № 3 показала вполне приличную производительность и плавность даже на слабых устройствах с ARMv7 и старых iPhone. Никаких особых сложностей в освоении языка Dart у Android-разработчиков не возникло, а создать работоспособный UI для тестового приложения удалось за считанные дни.

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

Что мы поняли?

В итоге тестирования, освоения новых библиотек и работы с плагином KMM мы сделали вывод, что сложность версии № 2 примерно соответствует обычной классической платформенной (если не учитывать время, потраченное на освоение новых библиотек и написание UI-части для iOS). КММ помог четче разделить приложение по слоям и избежать их смешения.

Мы пришли к интересной мысли, что можно даже сразу делать нативные Android-приложения на КММ, если планируется версия под iOS. Это практически не удлиняет разработку под Android, но зато экономит немало усилий при создании и тестировании iOS-версии — достаточно лишь написать UI-часть.

В целом тестирование убедило, что самым эффективным и быстрым в реализации решением для нас станет разработка приложения на связке KMM + Flutter. А если что-то пойдет не так, мы всегда сможем вернуться к резервному варианту Native UI + KMM — переделка из схемы Flutter + KMM затронет лишь слой представления.

Пара слов о выбранных технологиях

Для тех, кто не знаком с выбранными нами технологиями, сделаю небольшое пояснение:

В качестве основы для слоя представления используется Flutter — SDK для создания приложений под iOS, Android и web (плюс desktop в планах). Это уже достаточно зрелая технология (релиз первой версии состоялся в 2015 году), с накопленной базой готовых решений и вопросами / ответами по ней. Впрочем, родная документация на сайте тоже очень подробная.

В качестве языка программирования для Flutter используется Dart. Он компилируется в бинарный код, что позволяет добиться высокой скорости выполнения операций, сравнимой с результатами Objective-C, Swift, Java или Kotlin. Dart не использует нативные компоненты платформ ни в каком виде: подобно игровым движкам он отрисовывает все графические элементы самостоятельно — с помощью собственного движка Google Skia. Все элементы этого интерфейса описываются декларативно, подобно новомодным Swift UI и Jetpack Compose.

В качестве основы для бизнес-логики и, что немаловажно, дата-слоя используется Kotlin Muliplatform Mobile (KMM). Это SDK, созданный для упрощенной разработки кроссплатформенных приложений. Он построен на Kotlin Multiplatform (KM) — технологии, которая позволяет запускать на множестве платформ (Android, iOS, Linux, Windows, MacOS, web и т. д.) один и тот же код, написанный на Kotlin. При добавлении к KM интеграции с мобильными платформами получается KMM. Есть удобный репозиторий, где собраны основные библиотеки для KMM. Большинство компонентов KMM (за исключением интеграции с IDE и плагина под Android Studio) находятся в статусе stable или beta, так что риск использования данной технологии минимален, а ее API уже не будет меняться с новыми релизами.

Если есть вопросы, буду рад ответить. А о реальном внедрении расскажу в следующей статье.

Источник

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

Авторизуйтесь

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

фулстек-разработчик мобильных приложений в IT-компании Neti

Меня зовут Ленар Деллерт, я фулстек-разработчик мобильных приложений в IT-компании Neti. Разрабатывать и для веба, и для «мобилок» научился сам, какого-то специального «программистского» образования у меня нет. В статье объясню, какие специалисты требуются в мобильной разработке, расскажу, как освоил программирование с нуля, и поделюсь ресурсами, на которых можно учиться.

Бэкенд, фронтенд, фулстек: кто есть кто в мобильной разработке

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

Сделать бэк сложнее, чем фронт, потому что чаще всего именно на бэкенде закладывается бизнес-логика программы. Если бэкенд и API реализованы плохо, приложение будет тормозить, вылетать и раздражать пользователей. Серверную часть и API делают бэкенд-разработчики. В нашей компании бэкендеры кодят на PHP на фреймворках Laravel и Yii2.

Бывают простые приложения без бэка, но они «зациклены» на самих себе: через них нельзя, например, оплатить заказ в корзине, попереписываться с менеджером в чате, забронировать столик.

3–4 декабря, Онлайн, Беcплатно

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

При нативном подходе для операционных систем Android и iOS делают два отдельных приложения. Для этого требуются два специалиста: android-разработчик, который пишет на Java или Kotlin, и iOS-разработчик, который пишет на Objective-C или Swift.

При кроссплатформенной разработке нужен всего один программист. Он пишет код на фреймворках React Native, Flutter или Xamarin, а потом компилятор адаптирует этот код под Android и iOS. React Native разработчик должен знать JavaScript, Flutter-разработчик — язык Dart, чтобы писать на Xamarin, нужно владеть С#.

Еще есть фулстек-разработчики — это специалисты два в одном, которые могут сделать и бэкенд, и фронтенд. Я фулстек-разработчик мобильных приложений: бэкенд реализую на Yii2, фронтенд — на React Native. Нативные приложения не совсем мой профиль: я пробовал писать под iOS и Android в рамках коммерческой разработки, но считаю, что у меня недостаточно опыта, чтобы давать какие-то советы.

Теория

Если человек задумывается о карьере в IT, в первую очередь он должен понять, интересна ли ему эта сфера. Готов ли он целый день сидеть и писать код? Не захочет ли все бросить, если над задачей придется биться несколько часов? Идти в программирование из-за хороших зарплат не стоит, потому что деньги — недостаточная мотивация. Многие забывают, что зарабатывать люди начинают после того, как потратят несколько лет на обучение и приобретение опыта.

Я считаю, что человеку должно быть по-настоящему интересно то, что он делает. В этом секрет. Когда у меня появился высокоскоростной интернет, мне стало интересно, как работают сайты. Я полазил по разным ресурсам, форумам и узнал об HTML и CSS. Нашел по ним уроки, познакомился с базовыми понятиями и стал делал html-странички. Потом захотел придать им интерактивности, понял, что для этого нужен язык JavaScript, и начал изучать его.

Сайты, на которых я изучал HTML, CSS, JavaScript:

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

Ресурсы для изучения PHP:

• Руководство по PHP.
• Книга Мэтта Зандстра «PHP: объекты, шаблоны и методики программирования».

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

Моя страсть узнавать новое привела меня в мобильную разработку. Когда я уже работал PHP-программистом, мне было скучно использовать одни и те же инструменты, и я попросил тимлида, который писал под iOS и Android, научить меня разрабатывать под одну из этих ОС. Он показал, как делать приложения под Android. Это меня увлекло. Сначала я писал под Android, потом захотелось попробовать кроссплатформенные решения и я разобрался во фреймворке Xamarin.

В 2019 году мне предложили сделать мобильное приложение на React Native для логистической компании, и я согласился, хотя раньше не писал на этом фреймворке. Было интересно, как он работает. Чтобы освоить React Native, я читал документацию, лазил по GitHub и форумам. Как всегда, спасал сервис Stack Overflow: если не хватало информации, я находил там ответы на свои вопросы. Если я не знал, как решить задачу, я гуглил. Умение гуглить очень важно для любого разработчика. Кстати, лучше формулировать запросы на английском языке — так больше шансов найти ответ.

Практика

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

Изучая новый язык или фреймворк, я часто пишу что-то для себя. К примеру, чтобы понять, как работает Zend Framework, я разбирал его компоненты. Брал Query Builder, который используется для построения SQL-запросов, копался в нем и пытался написать свой «велосипед». Затем разбирался в следующем компоненте.

Чтобы освоить Swift и среду разработки Xcode, я написал для часов Apple Watch приложение, которое в реальном времени показывает погоду. Не скажу, что после этого стал крутым iOS-разработчиком, но теперь проверяя код для iOS других программистов, могу понять, что написано, и посоветовать, как сделать лучше.

Алгоритм для тех, кто хочет стать разработчиком, такой:

1. Прочитать руководства, сайты и форумы по интересующей технологии.
2. Практиковаться. Если учишь PHP, напиши простой сайт, если разбираешься с React Native, сделай несложное приложение. Необязательно придумывать программу с нуля, можно попробовать повторить то, что уже разработали до тебя. Если непонятно, как что-то сделать, или выскакивает ошибка, которую не получается исправить, погугли или найди ответ на Stack Overflow. Решение точно есть, его просто надо поискать.
3. Устроиться стажером или джуном и набивать руку на реальных задачах. Первое время придется работать за небольшие деньги. Зато на работе легче найти наставника и быстро прокачаться с его помощью.

Дальше расскажу, какие технологии должны знать начинающие React Native и бэкенд-разработчики, чтобы найти работу.

Что должен знать начинающий React Native разработчик

Чтобы устроиться младшим React Native разработчиком, нужно освоить на базовом уровне следующие технологии:

• Язык программирования JavaScript.
• Навыки верстки с применением HTML, CSS.
• Фреймворки ReactJS и React Native.
• Основы разработки под Android и iOS. Необходимые понятия: «жизненный цикл», «активность», «фрагмент». Уметь работать с файлами настроек: для Android это AndroidManifest.xml, для iOS — info.plist. Знать, как поднять версию приложения и выставить права для определенных сервисов (например, геолокации или доступ к фотогалереи).
• Основы работы с системой контроля версий Git.

Что должен знать начинающий бэкенд-разработчик мобильных приложений

Вот что должен знать джун-бэкендер, чтобы получить работу:

• Один из языков программирования, предназначенных для написания бэкенда, например, PHP.
• Один из популярных фреймворков в рамках выбранного языка. Например, для PHP это Laravel или Yii2.
• Понимание основ работы с базами данных и составления SQL-запросов.
• Понимание работы HTTP-серверов Nginx или Apache.

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

Soft Skills

Стоит добавить, что кроме hard skills джуниор-программисту пригодятся такие soft skills:

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

Нет универсального рецепта, по которому каждый человек освоил бы программирование. Я поделился своим видением. Возможно, кому-то больше понравится проходить курсы. Хорошие курсы помогут быстрее составить правильное представление о базовых вещах, чем формировать его самому. Но разбираться, как лучше решить практическую задачу заказчика, исходя из контекста ситуации, все равно придется самостоятельно, параллельно восполняя пробелы по документации, сайтам и форумам. Это и называется опыт. В любом случае главное — не бояться и делать. Если с первого раза не получилось — переделывать. Тогда точно получится.

Источник