Разработка мобильного приложения для дневника питания
Дневник питания — одно из тех приложений, где техническая сложность сосредоточена не в архитектуре, а в данных. База продуктов с корректными КБЖУ — это годы работы диетологов и инженеров. Барcode-сканер работает хорошо ровно до тех пор, пока пользователь не достаёт локальный йогурт без штрих-кода или продукт с несколькими порциями на упаковке.
Где концентрируется сложность
База продуктов. USDA FoodData Central, Open Food Facts, Edamam — три популярных источника. У каждого свои причуды: USDA не покрывает СНГ-продукты, Open Food Facts имеет краудсорсинговые данные с пропусками в нутриентах, Edamam отдаёт API-запросы с rate limit 400 в минуту на бесплатном плане. Строим гибридную систему: локальная база с кешем популярных продуктов (SQLite / Room / CoreData), fallback на API при промахе кеша, модуль пользовательских продуктов для кастомных позиций.
Сканер штрих-кодов. На iOS используем AVCaptureSession с AVMetadataObjectTypeEAN13Code и рядом других форматов. Проблема в том, что сессия должна стартовать быстро — пользователь уже держит телефон над упаковкой. Если инициализировать сессию лениво при открытии экрана, задержка 0.5–0.8 секунды бьёт по UX. Решение — preload сессии в момент авторизации на экране. На Android через CameraX с BarcodeScanning из ML Kit аналогичный подход: инициализировать ImageAnalysis.Analyzer заранее.
Нормы КБЖУ. Суточная норма калорий считается по формуле Миффлина-Сан Жеора с корректировкой на коэффициент активности. Пользователь вносит рост, вес, возраст, уровень активности — получает цель. Но цель меняется: при снижении веса надо пересчитывать норму каждые 2–4 недели. Это состояние нужно хранить с историей, чтобы ретроспективная аналитика была корректной.
Как строим
Flutter + Riverpod для кросс-платформы, либо нативно Swift/UIKit + CoreData + Combine для iOS-only проекта. Модель данных: FoodItem (нутриенты на 100г), MealEntry (timestamp, еда, порция в граммах, приём пищи — завтрак/обед/ужин/перекус), DailyLog (агрегат по дням). Агрегация по дням — кешируем: пересчитываем только при добавлении/удалении записей за этот день.
Рецепты — отдельная сущность Recipe с массивом RecipeIngredient. При добавлении рецепта в дневник разворачиваем ингредиенты с пересчётом порций. Важно хранить снимок КБЖУ в момент добавления, а не ссылку на живой рецепт — иначе редактирование рецепта ломает историческую аналитику.
Из практики: интеграция с HealthKit для записи калорий в Apple Health через HKQuantityType.dietaryEnergyConsumed. Пользователи с Apple Watch требуют этого — иначе приложение не считается в экосистеме. Аналогично на Android — Health Connect API (ExerciseSessionRecord, NutritionRecord).
Процесс работы
Определяем источники данных о продуктах, целевые рынки (от этого зависит база), нужна ли интеграция со здоровьем, модель монетизации (freemium, подписка). Проектируем схему БД, прототипируем ключевые экраны, разрабатываем MVP, тестируем на реальных устройствах с физическими штрих-кодами.
Ориентиры по срокам
MVP с ручным вводом, базовым поиском, дневником и суточной статистикой — 4–6 недель. Полный продукт со сканером, синком с HealthKit/Health Connect, рецептами, графиками за месяц и push-напоминаниями — 10–16 недель. Стоимость рассчитывается индивидуально.
На что обращаем внимание при тестировании
Сканирование с разным освещением (полумрак супермаркета — частый сценарий), корректность расчётов при нестандартных единицах порций, правильная обработка продуктов с нулевым содержанием отдельных нутриентов, поведение при offline (поиск в локальном кеше без обращения к API).