Разработка приложений для Android

Подробно

Разработка приложений на Андроид в Кодовой студии идет полным циклом: аналитика, дизайн, код на Kotlin, серверная часть, тестирование и публикация. Делаем клиентские приложения для смартфонов и планшетов, рабочие инструменты для курьеров и кладовщиков на терминалах сбора данных (ТСД, защищенные Android-устройства со встроенным сканером штрихкодов), приложения для умных часов и Android TV.

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

Как заказать приложение для Google Play

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

1. Бриф. Вы описываете задачу, аудиторию и примеры приложений, которые нравятся. Мы задаем уточняющие вопросы и называем порядок бюджета.
2. Анализ. Аналитик разбирает бизнес-процессы, пользовательские сценарии и интеграции, вместе с вами фиксирует состав первой версии.
3. Прототип. Собираем кликабельную схему экранов: на ней договориться проще, чем на тексте.
4. Дизайн. Рисуем интерфейс по принципам Material Design с учетом вашего фирменного стиля.
5. Разработка. Пишем код спринтами и после каждого отдаем сборку, которую можно поставить на телефон.
6. Тестирование. Проверяем на эмуляторах и на устройствах Android разных производителей.
7. Публикация приложения. Готовим описание, скриншоты, политику конфиденциальности и проходим модерацию.

Аккаунт разработчика лучше регистрировать на компанию заказчика, тогда приложение с первого дня принадлежит вам. Регистрация в Google Play стоит 25 долл. один раз. Для российской аудитории параллельно выпускаем приложение в RuStore: там своя консоль, свои требования к описанию и отдельная модерация.

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

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

Создать приложение для Android: что подготовить до старта

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

• Цель первой версии: какое действие пользователь должен совершить в приложении и по какому показателю вы поймете, что оно работает.
• Портрет аудитории: кто эти люди, какими телефонами пользуются, где открывают приложение - дома, в дороге, на складе.
• Список систем, с которыми нужна связь: сайт, 1С, CRM, платежный сервис, служба доставки. Для каждой пригодится контакт человека, который знает ее устройство.
• Требования к данным: какие персональные данные собираете и где они должны храниться.
• Примеры приложений, которые нравятся или раздражают, с пояснением почему.
• Фирменный стиль: логотип, цвета, шрифты. Если стиля нет, дизайнер соберет его на этапе дизайна.

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

Компания-разработчик Android: команда, архитектура, поддержка

Когда ищут компанию-разработчика Android, обычно сравнивают портфолио и цену. Мы советуем смотреть еще на три вещи: кто в команде, как устроена архитектура и что будет после релиза.

Команда на Android-проекте у нас такая: аналитик, UX/UI-дизайнер, один или несколько Android-разработчиков, backend-разработчик, тестировщик и менеджер проекта. Если у продукта будет iOS-версия, добавляем iOS-разработчика или предлагаем кроссплатформенный вариант на Flutter или React Native. Выбор делаем вместе с заказчиком: считаем, сколько кода можно разделить между платформами и насколько приложению нужны специфичные функции устройства.

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

Безопасность закладываем с первого спринта. Токены авторизации храним в защищенном хранилище системы, локальную базу шифруем, если в ней лежат персональные данные, а релизную сборку обфусцируем через R8 (инструмент, который сжимает код и затрудняет его разбор). Для финтеха и медицины добавляем проверку целостности приложения и защиту от запуска на устройствах с root-доступом.

Отдельное направление - корпоративные приложения. Мы делаем Android-приложение, например, для выездных сотрудников, складской приемки или инвентаризации. Такие программы работают на ТСД, читают штрихкоды встроенным сканером, копят данные без сети и отправляют их в учетную систему, когда связь появляется. Здесь важна не красота экрана, а скорость: кладовщик в перчатках должен провести операцию в два нажатия.

После релиза остаемся на поддержке. Следим за падениями и отзывами, выпускаем обновления под новые версии Android, дорабатываем функции по аналитике. Поддержка обходится в 15-25 процентов от стоимости разработки в год, и этот бюджет стоит закладывать сразу. Подход можно оценить по демо-проектам Грядка и Трассер: это демонстрационные приложения, на которых мы показываем интерфейсы и архитектурные решения.

Написание программ для Android: язык программирования, среда разработки, Android SDK

Написание программ для Android сегодня почти всегда идет на Kotlin. Этот язык программирования платформа официально рекомендует, он короче и безопаснее Java, а старый Java-код в проекте с ним совместим. Интерфейс собираем на Jetpack Compose: экраны описываются кодом, без XML-разметки, и их проще переиспользовать между телефоном и планшетом на Android. Android Studio - основная среда разработки. В ней создают проект, пишут и отлаживают код, запускают эмулятор и смотрят, сколько памяти и батареи тратит приложение. Вместе со средой ставится Android SDK: набор библиотек и утилит для сборки под разные версии системы.

Если открыть любое приложение Android Studio изнутри, в нем есть несколько обязательных частей:

• файл AndroidManifest.xml, где записаны название приложения, иконка, экраны и разрешения, например на камеру или геолокацию;
• файл сборки build.gradle с настройками, в том числе с минимальной версией Android, ниже которой приложение не установится;
• исходный код на Kotlin, разбитый по модулям;
• ресурсы: строки, иконки, цвета, шрифты.

Учебное создание приложения выглядит просто: в Android Studio выбирают New Project, шаблон Empty Activity, задают название и минимальную версию, и вскоре на виртуальном устройстве открывается пустой экран. Дальше начинается настоящая разработка приложения. В коммерческом продукте нужны база данных (мы используем Room), работа с сетью, авторизация, push-уведомления, аналитика, обработка ошибок и офлайн-режим. Каждая из этих частей требует решений, которые потом сложно поменять.

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

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

Как сделать приложение-калькулятор на Android?

Калькулятор - классическое первое приложение, на котором учатся. Чтобы создать Android-калькулятор, достаточно одного экрана: сетка кнопок в Compose, поле с результатом и класс, который разбирает выражение и считает ответ. Логику лучше вынести во ViewModel, тогда результат не потеряется при повороте экрана. Такой проект собирается за вечер и хорошо показывает базовые принципы: состояние экрана, обработку нажатий, тесты на арифметику.

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

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

Web-приложения на Android

Web-приложения на Android работают в браузере, но пользователь может установить их на главный экран, и они открываются без адресной строки, как обычная программа. Технически это PWA (прогрессивное веб-приложение): сайт с файлом манифеста и сервис-воркером, который кэширует данные и дает работать без сети. На Android такие приложения получают push-уведомления и доступ к части функций устройства: камере, геолокации, а в некоторых браузерах и к Bluetooth.

Когда веб-версии хватает:

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

Натив нужен, когда есть сложная работа в фоне, трекинг геолокации, сканер штрихкодов на ТСД, связь с платежными терминалами или тяжелая графика. Веб-приложение удобно выпускать и обновлять без модерации, но в поиске магазина его нет, пока его не упаковать отдельно.

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

Есть и промежуточный вариант - React Native. Код пишут на JavaScript или TypeScript, а интерфейс собирается из нативных компонентов. Он подходит компаниям с веб-командой на React, которые хотят выйти в магазины без отдельного Kotlin-разработчика. Мы сравниваем эти пути на ваших сценариях и считаем, во что обойдется каждый через год развития.

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

Сделать приложение из сайта можно тремя способами, и они сильно различаются по цене и возможностям.

1. PWA. Дорабатываем сайт: добавляем манифест, сервис-воркер, офлайн-кэш и push-уведомления. Пользователь ставит приложение прямо со страницы, сайт остается один и обновляется вместе с приложением.
2. Оболочка. Упаковываем PWA в Android-приложение через Trusted Web Activity (механизм, который открывает сайт внутри приложения на весь экран) и публикуем в магазине. Так приложение попадает в поиск стора, но по сути остается сайтом, и модерация может отклонить его, если в нем нет ценности сверх сайта.
3. Нативное приложение на тех же данных. Сайт отдает данные через API, а приложение на Kotlin показывает их по-своему: быстрее, с офлайн-режимом, виджетами и фоновой работой. Путь дороже, зато пользовательский опыт не упирается в ограничения браузера.

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

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