Разработка мобильного приложения для садоводов/огородников
Приложение для садовода — пересечение нескольких технических доменов: распознавание растений и болезней через 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 permission, которое пользователи не дают.
Офлайн и база растений
Локальная база растений (название, описание, правила ухода, календарь посева) хранится в 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 недель.