Стек технологий android developer

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

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

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

Источник

What’s the Best Tech Stack for Mobile App Development?

To make your mobile application development project rewarding and successful, choosing the right mobile technology stack is vital. The technology stack not only gives your project life but also makes it maintainable, scalable, and committed to your functional requirements. An appropriate mobile stack may result in lower costs and less time for mobile app development. We review the most popular mobile app development approaches and the advanced tech stacks you can use to implement them.

Native app development

Native app development means using platform-specific programming languages, software development kits, development environments, and other tools provided by operating system vendors. As a result, building native apps for several platforms requires you to employ separate mobile app development technologies for each. Popular apps like Lyft and Pokemon GO take the native approach.

Technology stack for iOS apps in 2020

If you want to create a native application for iOS, you should consider the following mobile app technology stack:

Programming languages: Objective-C, Swift

For building an iOS app you can choose either Objective-C or Swift. Objective-C is a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime environment.

However, we recommend using Swift since it’s more functional, provides code that’s less error-prone because of its inline support for manipulating text strings and data, and contains dynamic libraries that are directly uploaded to memory, cutting down on the initial size of the app and ultimately increasing app performance. Our iOS developers use Swift, and have recently created their own watermark library for video and image overlays, called MediaWatermark. This library can be integrated and installed quickly and efficiently, letting you put watermarks on videos and images.

Toolkit: Apple Xcode

If you choose Swift for your iOS app, then you’ll need Apple Xcode as the toolkit for developing your native app. This full-featured development environment lets you create mobile apps as well as desktop applications. Xcode comes with integrated support for Git repositories, a graphical editor to build user interfaces, instrumentation and debugging tools, and integrated documentation.

SDK: iOS SDK

The iOS SDK includes an application programming interface (API) that serves as a link between software applications and the platform they run on. APIs can be built in many ways and include helpful programming libraries and other tools. The iPhone SDK provides tools for Apple’s touchscreen interface and for its proprietary iOS operating system, which is used to run Apple’s iPhones as well as Apple’s other mobile devices such as the iPad.

Android technology stack in 2020

If you decide to build a native application for Android, pay attention to the following mobile development technologies:

Programming languages: Java, Kotlin

For developing a native Android mobile app you can use Java or Kotlin. Java is a reputable programming language with vast open-source tools and libraries to help developers. However, Kotlin has become a more stable and congruous development option for Android Studio. There are definite limitations within Java that impede Android API design. Kotlin is inherently lightweight, clean, and far less verbose. In other words, Kotlin was specifically designed to improve existing Java models by offering solutions to API design deficiencies. That’s why our Android team prefered Kotlin for our mobile app Scrummer. As a result, we got a fully operational mobile app with smooth transitions between screens and animated micro-interactions.

Toolkit: Android Studio & Android Developer Tools

Android Studio provides code editing, debugging, performance tooling, a flexible build system, and an instant build/deploy system. It allows you to focus on building unique and high-quality apps.

With the help of Android Developer Tools (ADT), you gain full support for Android app development. Besides offering Android-specific coding support, ADT lets developers use various on-device debugging tools, a graphical UI builder, emulators, and fully scriptable test automation support.

SDK: Android SDK

To write programs with the latest features, developers must download and install each version SDK for a particular phone. The components of the Android SDK can be downloaded separately. Third-party add-ons are also available for download.

Both Apple and Google provide app developers with their own development tools, interface elements, and SDKs. Before choosing native app development, let’s look at the pros and cons of this approach.

Cross-platform app development

This approach means developing mobile apps that can be used on multiple mobile platforms. A cross-platform approach allows developers to use a single code base, so mobile apps are developed for different platforms simultaneously and are adapted to the majority of devices.

Technology stack for cross-platform apps

There are different frameworks for cross-platform app development. Let’s consider some of them:

React Native + JavaScript/TypeScript

React Native is a JavaScript framework for writing mobile applications that look and feel native on both iOS and Android. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React. React Native introduces a novel, radical, and highly functional approach to constructing user interfaces. With React Native, your application logic is written and runs in JavaScript, whereas your application UI is fully native. Great examples of such apps are Instagram and Skype.

You can also use the TypeScript language to build your cross-platform application. Typescript provides some nice features for quick and easy error detection when writing React components. Generic components are useful in the TypeScript toolbox. They can provide an extra level of safety when writing components, tightening the feedback loop and helping you find errors quickly.

Xamarin + C#

Xamarin is a tool for cross-platform mobile app development that allows engineers to share about 90 percent of code across major platforms. Xamarin uses C# as the main language for cross-platform development. C# is a statically typed language with mature tooling and IDE support. Apps written in C# are cross-compiled to native Android and iOS binaries. It’s even possible to use device-specific APIs and functionality from within C# code. For example, apps like Slack and Pinterest are built with Xamarin.

Now let’s look at the pros and cons of cross-platform app development.

Hybrid app development

Hybrid development makes use of standard web technologies and tools like HTML5, CSS, and JavaScript. The shared code is then wrapped in a native container, which can be done using various tools, and shipped as a regular app. Such apps function like websites, fundamentally, somewhere between an app and a page rendered in a browser. Untappd and McDonald’s Türkiye are examples of hybrid applications.

Technology stack for hybrid apps

Let’s consider the existing frameworks for hybrid app development and find out how they work.

Cordova/PhoneGap

Apache Cordova is an open-source framework to run HTML/JavaScript-based applications inside a special native container on a mobile device. Native device functionality is exposed via JavaScript APIs, and HTML-based applications can thus access device-specific functionality like sensors and cameras. Fortunately, developers don’t have to rely only on HTML and CSS to build the user interface, as PhoneGap supports numerous frameworks and libraries including jQuery, AngularJS, and Knockout.js.

Ionic

Ionic is an AngularJS-based framework, which is why it shares a whole set of advantages and a supporting community with the famous framework. The critical ability to make hybrid apps have a native look is also well implemented. For instance, Ionic reuses DOM elements to handle one of the reasons for poor mobile performance.

If you’re thinking of using a hybrid approach, first consider its pros and cons.

Factors to consider when choosing a technology stack

You have a rich choice of technology stacks for mobile applications, but which one is right for you to use in your app development project? It’s important to have a solid plan in mind when choosing a mobile app stack if you want to have not only professional, functional software but something more like maintainability, scalability, and security.

There are a lot of things to consider when trying to choose the right mobile application technology. These are the main considerations.

Type of project

This is the vital determinant when choosing a mobile development technology stack for your mobile application. For example, if you’re planning to create a complex mobile app with great performance and a completely custom, platform-specific UI implementation, then you should go native. In such cases, Kotlin or Swift are the commonly used programming languages.

Validating an idea

If you’re a startup and just want to validate your product idea, engage your potential users, and stay one step ahead of your competitors, choose a cross-platform approach. React Native will be a good choice, for example, since it’s cost-effective and allows you to reuse code on various platforms, which means wide platform coverage and fast app delivery.

Time to market

The speed at which companies can introduce products to the market is critical for sustaining a competitive advantage. If you want to speed up product development, consider a language or framework with an abundance of ready-made solutions for common development tasks,such as authentication and social media integrations.

Wrapping up

Mobile app development will continue to grow as more and more enterprises adopt mobile technologies. If you want to create a highly functional mobile app, choosing the right mobile app technology is the key ingredient.

Still hesitate which approach and tech stack to choose? Contact us to get expert advice today!

Источник