Розробка мобільного додатка для садівників/городівників
Додаток для садівника — перетин кількох технічних доменів: розпізнавання рослин та хвороб через CV-моделі, локальні сповіщення за розкладом поливання, робота з геолокацією для погодних даних, офлайн-режим (на даче часто немає інтернету). Жоден із цих компонентів не складний сам по собі — складність у правильній інтеграції всього разом.
Розпізнавання рослин та хвороб
Центральна фіча, яку зазвичай хочуть усі. Тут два шляхи: власна CoreML/TFLite модель або API стороннього сервісу.
Plant.id API та PlantNet API — найзрілішіі варіанти. Plant.id видає не тільки назву, але й хвороби з confidence score та рекомендаціями з лікування. Інтеграція стандартна: фото кодується в base64, відправляється POST-запитом, відповідь містить suggestions з probability. Важливо: Plant.id вимагає добре освітленого знімка листка або квітки — фото загального плану дає низьку точність. Потрібно заздалегідь навчити користувача, що фотографувати.
struct PlantIdentificationRequest: Encodable {
let images: [String] // base64
let modifiers: [String] // ["crops_fast", "similar_images"]
let plant_language: String // "ru"
let plant_details: [String] // ["common_names", "url", "description", "treatment"]
}
On-device варіант через CoreML: моделі від iNaturalist (відкрита база) або навчені на датасеті PlantVillage (хвороби листків — 54 000 зображень, 38 класів). Точність нижча, ніж в хмарі, зато повністю офлайн.
Розклад поливання та сповіщення
Звучить просто — на практиці головна помилка: розробники ставлять UNUserNotificationCenter сповіщення з фіксованим часом та дивуються, чому користувачі скаржаться на пропущене поливання. Проблема — сповіщення не перераховуються при зміні опадів.
Правильна логіка: кожного ранку запитуємо прогноз погоди (OpenWeatherMap API або Apple WeatherKit), якщо прогнозується дощ > 5 мм — пропускаємо полив та скасовуємо сповіщення через UNUserNotificationCenter.removePendingNotificationRequests. Це вимагає BGAppRefreshTask (iOS) або WorkManager (Android) для ранкового фонового завдання.
На Android WorkManager з PeriodicWorkRequest та NetworkType.CONNECTED constraint — правильне рішення. Не AlarmManager напрямо — на Android 12+ потрібна дозвіл SCHEDULE_EXACT_ALARM, яку користувачи не дають.
Офлайн та база рослин
Локальна база рослин (назва, опис, правила догляду, календар посіву) зберігається в SQLite. Для 500–1000 записів — Room на Android, Core Data або GRDB на iOS. Зображення рослин — кешуються при першому перегляді з LRU-політикою (Kingfisher на iOS, Coil на Android).
Дача без інтернету — реальність. Усі базові функції (додавання рослини, перегляд порад, встановлення нагадування) повинні працювати без мережі. Синхронізація при відновленні з'єднання — через чергу відкладених операцій.
Погодна інтеграція
OpenWeatherMap — стандарт для таких додатків, tier Free покриває до 1000 запитів на день. WeatherKit на iOS (з iOS 16) — точніше та не вимагає власного ключа, але доступний тільки на Apple платформах.
Для городівного додатка важлива не лише температура, але й humidity, uvi (індекс УФ), rain (опади за 1 та 3 години) — ці поля доступні в current ендпоінті OWM.
Процес впровадження
Визначаємо набір фіч: які рослини (тільки город, чи сад + кімнатні), потрібна ліле соціальна складова (обмін порадами, спільнота), вимагається ліле офлайн-база хвороб. Це сильно впливає на обсяг.
Розробка: офлайн-база → додавання рослин → розклад поливання з сповіщеннями → погодна інтеграція → розпізнавання. Розпізнавання — останнім, тому що API-ключі та тарифікація потребують окремого узгодження.
Часові орієнтири
Додаток з базою рослин, розкладом поливання та погодою — 5–7 тижнів. З розпізнаванням рослин/хвороб та офлайн-режимом — 9–12 тижнів.