Android
Android-приложение позволяет перенести ключевой сервис, продажи, обслуживание клиентов или внутренний процесс на мобильное устройство. На DitWork можно сравнить разработчиков по опыту с платформой, архитектуре, качеству вопросов, тестированию, публикации и дальнейшей поддержке. Для точной оценки важно описать не только список экранов, но и роли пользователей, источник данных, обязательные интеграции, поддерживаемые устройства, работу без сети и измеримый результат первой версии.
Какие приложения можно заказать
В категории «Android» можно заказать MVP и коммерческие Android-приложения, личные кабинеты и приложения для сотрудников, магазины, каталоги и программы лояльности, приложения с камерой, картами, NFC и Bluetooth, интеграции с API, CRM и платежами и обновление, миграцию и исправление существующего Android-проекта. Сначала отделите обязательный MVP от функций будущих релизов. Для каждого сценария укажите, кто начинает действие, какие данные вводит, какой ответ ожидает, что происходит при ошибке и где хранится итог. Такая детализация помогает не превращать оценку проекта в приблизительное умножение количества экранов.
- MVP и коммерческие Android-приложения
- личные кабинеты и приложения для сотрудников
- магазины, каталоги и программы лояльности
- приложения с камерой, картами, NFC и Bluetooth
- интеграции с API, CRM и платежами
- обновление, миграцию и исправление существующего Android-проекта
Результат по этапам
| Этап | Результат | Что проверить |
|---|---|---|
| уточнение MVP и поддерживаемых устройств | репозиторий исходного кода | основные сценарии проходят на согласованной матрице устройств |
| прототипирование основных сценариев | Gradle-проект и зафиксированные версии зависимостей | интерфейс не ломается на маленьких экранах и при увеличенном шрифте |
| проектирование модулей и API-контрактов | описание build variants и окружений | разрешения запрашиваются только в понятном контексте |
Что указать в техническом задании
Для подготовки задания соберите цель продукта и роли пользователей, ключевые экраны и пользовательские сценарии, минимальную версию Android и типы устройств, макеты или требования к интерфейсу, описание API, авторизации и данных, платежи, push и фоновые процессы и критерии MVP и планы дальнейших релизов. Не публикуйте реальные пароли, ключи подписи, токены, клиентские базы и персональные сведения. Приложите обезличенные примеры и тестовые учетные записи. Если интерфейс еще не спроектирован, разумно отдельно заказать карту сценариев, wireframes и кликабельный прототип, а затем передавать разработчику согласованный объем.
- цель продукта и роли пользователей
- ключевые экраны и пользовательские сценарии
- минимальную версию Android и типы устройств
- макеты или требования к интерфейсу
- описание API, авторизации и данных
- платежи, push и фоновые процессы
- критерии MVP и планы дальнейших релизов
Что проверить до начала разработки
До начала работ полезно проверить готовность дизайна и backend API, существующие модули, SDK и лицензии, учетную запись Google Play и права команды, поддерживаемые размеры экранов и архитектуры устройств, разрешения и необходимость фоновой работы, объем локальных данных и синхронизацию и план переноса пользователей из старого приложения. Если серверная часть не готова, разработчик должен получить согласованный API-контракт, примеры ответов и тестовый стенд. Если приложение уже существует, аудит должен показать, воспроизводится ли сборка, кто владеет ключами, какие зависимости устарели, где находятся конфигурации и можно ли безопасно выпустить обновление.
- готовность дизайна и backend API
- существующие модули, SDK и лицензии
- учетную запись Google Play и права команды
- поддерживаемые размеры экранов и архитектуры устройств
- разрешения и необходимость фоновой работы
- объем локальных данных и синхронизацию
- план переноса пользователей из старого приложения
Как проходит разработка
Последовательная разработка включает уточнение MVP и поддерживаемых устройств, прототипирование основных сценариев, проектирование модулей и API-контрактов, разработка интерфейса и бизнес-логики, интеграция платежей, push и фоновых задач, тестирование на матрице устройств и тестовых каналах и подготовка App Bundle, публикации и поддержки. Этапы лучше принимать на тестовых сборках, а не ждать единственной демонстрации в конце. В начале подтверждают авторизацию, главный пользовательский путь и самый рискованный технический модуль. После этого добавляют остальные экраны, состояния загрузки, пустые результаты, ошибки, аналитику и правила восстановления.
- уточнение MVP и поддерживаемых устройств
- прототипирование основных сценариев
- проектирование модулей и API-контрактов
- разработка интерфейса и бизнес-логики
- интеграция платежей, push и фоновых задач
- тестирование на матрице устройств и тестовых каналах
- подготовка App Bundle, публикации и поддержки
Технические требования
В технических требованиях зафиксируйте Kotlin и согласованный подход Jetpack Compose или Views, понятную архитектуру и управление состоянием, безопасное хранение токенов, корректную работу разрешений и фоновых задач, адаптацию к разным экранам и плотности, доступность, локализацию и темную тему и журналирование, crash-аналитику и минимизацию персональных данных. Мобильный интерфейс должен учитывать системный размер текста, безопасные области, клавиатуру, поворот экрана, темную тему и сценарии медленной сети. Запрос разрешения нужно показывать в понятном контексте. Секреты нельзя хранить в репозитории, а журналы и crash-отчеты не должны раскрывать персональные данные.
- Kotlin и согласованный подход Jetpack Compose или Views
- понятную архитектуру и управление состоянием
- безопасное хранение токенов
- корректную работу разрешений и фоновых задач
- адаптацию к разным экранам и плотности
- доступность, локализацию и темную тему
- журналирование, crash-аналитику и минимизацию персональных данных
Что должен передать разработчик
После завершения запросите репозиторий исходного кода, Gradle-проект и зафиксированные версии зависимостей, описание build variants и окружений, инструкцию сборки и подписи, перечень переменных и секретов без значений, тестовые сценарии и матрицу устройств и документацию для передачи проекта другой команде. Заказчик должен иметь возможность собрать новую версию без прежнего исполнителя. Для этого нужны исходники, зависимости, инструкции, права на аккаунты, идентификаторы приложения и безопасно переданные ключи. Документация должна объяснять настройку окружений, выпуск тестовой и production-сборки, миграции и возврат к предыдущей версии.
- репозиторий исходного кода
- Gradle-проект и зафиксированные версии зависимостей
- описание build variants и окружений
- инструкцию сборки и подписи
- перечень переменных и секретов без значений
- тестовые сценарии и матрицу устройств
- документацию для передачи проекта другой команде
От чего зависит стоимость
Стоимость разработки «Android» зависит от таких факторов, как количество экранов и пользовательских ролей, готовность дизайна и серверной части, ширина поддерживаемой матрицы устройств, офлайн-режим, синхронизация и фоновые задачи, платежи, карты и аппаратные возможности, сложность миграции существующего приложения и тестирование, публикация и срок сопровождения. Сравнивайте предложения по одинаковому составу: дизайн, backend, административная панель, аналитика, публикация, тестирование и период исправления дефектов. Низкая оценка может не включать интерфейс ошибок, адаптацию устройств, сопровождение модерации или передачу исходников.
- количество экранов и пользовательских ролей
- готовность дизайна и серверной части
- ширина поддерживаемой матрицы устройств
- офлайн-режим, синхронизация и фоновые задачи
- платежи, карты и аппаратные возможности
- сложность миграции существующего приложения
- тестирование, публикация и срок сопровождения
Как выбрать разработчика
При выборе разработчика по направлению «Android» попросите показать релевантные приложения и объяснить личный вклад, архитектуру и процесс выпуска. Хороший специалист задает вопросы о пользователях, API, аналитике, доступности, безопасности, офлайн-режиме и владении учетными записями. Он не обещает прохождение модерации без проверки и заранее отделяет исправление дефектов от новых функций.
Как принять приложение
Перед приемкой проверьте основные сценарии проходят на согласованной матрице устройств, интерфейс не ломается на маленьких экранах и при увеличенном шрифте, разрешения запрашиваются только в понятном контексте, фоновые задачи соблюдают системные ограничения, потеря сети не приводит к дублированию операций, персональные данные не попадают в журналы и релизная сборка воспроизводится по инструкции. Используйте тестовые данные и реальные устройства, а не только эмулятор. Проверьте первый запуск, повторный вход, потерю сети, истечение сессии, двойное нажатие, возврат из фона, отказ в разрешении и обновление с предыдущей версии. Критические действия не должны дублироваться после повторного запроса.
- основные сценарии проходят на согласованной матрице устройств
- интерфейс не ломается на маленьких экранах и при увеличенном шрифте
- разрешения запрашиваются только в понятном контексте
- фоновые задачи соблюдают системные ограничения
- потеря сети не приводит к дублированию операций
- персональные данные не попадают в журналы
- релизная сборка воспроизводится по инструкции
Android-проект нужно проверять не только на одном флагманском телефоне. На результат влияют размеры и плотность экрана, объем памяти, версия системы, оболочка производителя, ограничения батареи и качество сети. Поэтому в задании полезно определить минимальную матрицу устройств и критические сценарии, а не обещать одинаковый тест на всех существующих моделях. Для публикации заказчик должен контролировать учетную запись, ключ подписи, package name, доступ к Google Play Console и резервное хранение необходимых материалов.
Доступы, данные и ответственность
В проекте «Android» заказчик отвечает за законность данных, тексты, товарные знаки, платежные условия, политики конфиденциальности и достоверность сведений для магазина. Разработчик отвечает за согласованный код, обработку ошибок, минимальные права, документирование и передачу результата. До начала нужно согласовать лицензии SDK, хранение аналитики, удаление учетной записи, резервные копии и срок поддержки.
Как разместить задание на DitWork
Чтобы заказать разработку «Android» на DitWork, создайте задание с кратким описанием продукта, ролями пользователей, обязательным MVP, ссылкой на макеты, API и критериями приемки. Укажите устройства, языки, офлайн-сценарии, платежи, уведомления, желаемые сроки и кто отвечает за публикацию. Сравнивайте предложения по пониманию бизнес-процесса, качеству архитектуры, плану тестирования, составу передаваемых файлов и поддержке после релиза.
