Стек технологий для 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). Он имеет открытый исходный код и имеет ряд функций для упрощения разработки и автоматизированными тестами.

Источник

Как заказчику выбрать Tech Stack мобильного приложения

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

Разработка нативных приложений

В разработке нативных приложений используются языки программирования, интегрированные среды и SDK, которые соответствуют конкретной платформе – iOS или Android. Зачастую инструментарий выпускается непосредственно производителем ОС.

Чтобы создать нативное приложение для 2 платформ, придется использовать разные технологии и нанимать 2 команды разработчиков (редко один и тот же человек специализируется и на iOS, и на Android). При таком подходе ценник возрастает.

Технологический стек для приложений iOS

Хотите разработать нативное приложение для iOS? Тогда вы будете выбирать из следующих технологий.

• Языки программирования: Objective-C или Swift. Objective-C — проверенный компилируемый объектно-ориентированный язык программирования. Однако будущее за Swift, так как он более функциональный. При написании кода на Swift возникает меньше багов. Также он содержит динамические библиотеки, которые загружаются непосредственно в память, сокращая первоначальный размер приложения и повышая производительность аппа. Да и в Apple делают ставку на Swift.
• IDE: Apple Xcode. Если вы отдадите предпочтение Swift, то без интегрированной среды разработки не обойтись. Apple Xcode позволяет создавать как мобильные, так и десктопные приложения. Xcode поддерживает репозитории Git, в нее встроен графический редактор для быстрого конструирования интерфейсов. Еще в IDE интегрирован автоотладчик.
• SDK: iOS SDK . Представляет собой интерфейс прикладного программирования (API), который служит связующим звеном между программными приложениями и платформой, на которой они работают. В комплект IPhone SDK входят наборы: Cocoa Touch (отвечает за тачпад, управление и камеру), Мультимедиа, Сервисное ядро и Ядро OS X.

Технологический стек для приложений Android

Решили разрабатывать нативное приложение для Android? Обратите внимание на следующие технологии:

• Языки программирования: Java или Kotlin. Java – проверенный, авторитетный язык с обширными инструментарием и множеством библиотек с открытым исходным кодом. Kotlin – более стабильный и согласованным вариант. Его синтаксис гораздо легче и чище. Если над созданием приложения будут работать несколько программистов, им будет проще доделывать таски друг друга.
• IDE: Android Studio и Android Developer Tools. Как и в случае со Swift, Kotlin работает в паре с IDE. С помощью Android Studio можно редактировать код, осуществлять отладку. В нем есть наборы инструментов для повышения производительности, обеспечивающие гибкую систему сборки и систему мгновенной сборки/развертывания (build/deploy). Использование Android Studio позволяет сосредоточиться на создании классных приложений вместо траты времени на монотонные процессы. Android Developer Tools облегчает кодирование. В нем предусмотрены: различные инструменты отладки, конструктор графического интерфейса, эмуляторы и поддержка автоматизированного тестирования.
• SDK — Android SDK . Чтобы писать программы с новейшими функциями, разработчики должны загрузить и установить версии SDK для каждой модели смартфона. Можно скачать отдельно официальные и сторонние компоненты Android SDK.

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

• идеальная интеграция в девайсы;
• комфортное использование с точки зрения юзера;
• высокая скорость работы приложения;
• высокая степень безопасности;
• высокая отзывчивость.

• приложение запускается только на одной платформе;
• высокая стоимость разработки;
• для создания требуется большая команда.

Разработка кроссплатформенных приложений

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

Технологический стек для кроссплатформенных приложений

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

1. React Native + JavaScript / TypeScript

React Native — это JavaScript-фреймворк, созданный для написания мобильных приложений. В нем есть основные блоки пользовательского интерфейса, характерные для iOS и Android. Программист комбинирует эти «кирпичики», используя JavaScript и React.

React Native — это новый, радикальный и высоко функциональный подход к созданию пользовательских интерфейсов. Логика приложения написана и выполняется на JavaScript, а пользовательский интерфейс полностью нативный. Отличными примерами приложений, написанных на React Native, являются Instagram и Skype.

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

2. Xamarin + C#

Xamarin — инструмент для кроссплатформенной разработки мобильных приложений, который позволяет использовать около 90% кода на основных платформах. В качестве основного языка в нем применяется C# (объектно-ориентированный язык программирования с поддержкой IDE). Приложения, написанные на C#, кросс-компилируются в нативные двоичные файлы Android и iOS. Можно даже запускать специфичные для устройства API и функции из кода C#.

3. Unity 3D + C#

Unity 3D чаще используется для разработки кроссплатформенных игр. Позволяет создать приложение, которое будет совместимо с более, чем 20 ОС. В Unity присутствует визуальная среда разработки, что существенно облегчает процесс работы. На базе Unity 3D можно получить сложный продукт с отличным качеством.

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

• обходится дешевле, чем нативная разработка;
• проще обновлять;
• приложение будет совместимо со всеми платформами;
• короче срок разработки.

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

Разработка гибридных приложений

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

Источник

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

Привет! Меня зовут Сергей Арсёнов, я руковожу мобильной разработкой в компании 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 уже не будет меняться с новыми релизами.

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

Источник