Розроблення мобільного додатка для дневника харчування
Дневник харчування — одне з тих додатків, де технічна складність сконцентрована не в архітектурі, а в даних. База продуктів з коректними КБЖУ — це роки роботи дієтологів та інженерів. Сканер штрих-кодів працює добре рівно до тих пір, поки користувач не достає локальний йогурт без штрих-кода або продукт з кількома порціями на упаковці.
Де концентрується складність
База продуктів. USDA FoodData Central, Open Food Facts, Edamam — три популярних джерела. У кожного свої дивацтва: USDA не охоплює СНД-продукти, Open Food Facts має краудсорсингові дані з пропусками в нутрієнтах, Edamam видає API-запити з ліміт 400 на хвилину на безплатному плані. Будуємо гібридну систему: локальна база з кешем популярних продуктів (SQLite / Room / CoreData), fallback на API при промаху кеша, модуль користувацьких продуктів для kastомних позицій.
Сканер штрих-кодів. На iOS використовуємо AVCaptureSession з AVMetadataObjectTypeEAN13Code та низкою інших форматів. Проблема в тому, що сесія повинна стартувати швидко — користувач уже тримає телефон над упаковкою. Якщо інціалізувати сесію лінивою при відкритті екрана, затримка 0.5–0.8 секунди бить по UX. Рішення — завантажити сесію в момент авторизації на екрані. На 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).