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 та критеріями приймання. Вкажіть пристрої, мови, офлайн-сценарії, платежі, сповіщення, бажані строки й хто відповідає за публікацію. Порівнюйте пропозиції за розумінням бізнес-процесу, якістю архітектури, планом тестування, складом переданих файлів і підтримкою після релізу.
