Разработка мобильного приложения для трекинга настроения
Трекер настроения кажется простым приложением ровно до того момента, пока не начинаешь разбираться в деталях: как хранить субъективные оценки так, чтобы потом из них получалась осмысленная аналитика, как строить графики динамики без визуального шума, как отправлять напоминания, которые не раздражают и не тонут в Do Not Disturb. Это не «сделай CRUD на Firebase» — это продуманная система работы с эмоциональными данными.
Что реально усложняет задачу
Главная техническая сложность — модель данных. Настроение можно оценивать по пятибалльной шкале, по шкале валентности-arousal, с эмодзи, с тегами контекста. Если структуру заложить неверно, то через месяц пользователь видит невалидные графики или вообще не может сравнить прошлый месяц с текущим.
Вторая боль — напоминания. UNUserNotificationCenter на iOS даёт только 64 pending-уведомления. При индивидуальном расписании на каждый день недели этот лимит сгорает мгновенно. Нужно либо генерировать уведомления динамически через BGAppRefreshTask, либо использовать повторяющиеся триггеры с локальной логикой. На Android WorkManager с PeriodicWorkRequest надёжнее, но и там Doze Mode режет доставку при агрессивных настройках энергосбережения.
Третья история — аналитика. Скользящее среднее за 7 дней, корреляция настроения с активностью из HealthKit (шаги, сон), кластеризация паттернов по дням недели. Всё это считается на клиенте — и если не кэшировать результаты агрегации, то каждый открытый экран аналитики перечитывает весь CoreData store с заметной задержкой.
Как строим
Архитектурно — MVVM с Combine (iOS) или ViewModel + StateFlow (Android). Локальное хранилище: CoreData с NSPersistentCloudKitContainer для iCloud-синка или Room + DataStore для Android. Бэкенд нужен не всегда — многие проекты работают полностью offline-first.
Для кросс-платформенной версии на Flutter используем Isar как встроенную БД вместо SQLite: он быстрее при сложных индексированных запросах и хорошо ложится на реактивную модель через watchLazy. Riverpod управляет состоянием, charts_flutter или fl_chart — визуализация.
Конкретный кейс: приложение с трекером настроения + дневником. Пользователь вносит запись — мы сохраняем MoodEntry с timestamp, числовой оценкой, enum-тегами (work, sleep, exercise, social) и опциональным текстом. Раз в сутки фоновая задача пересчитывает агрегаты за последние 30 дней и кладёт их в отдельную таблицу MoodAggregate. Экран аналитики читает только агрегаты — никаких тяжёлых запросов к основному хранилищу.
Интеграция с HealthKit (iOS) — запрашиваем HKQuantityTypeIdentifier.stepCount и sleepAnalysis за период, коррелируем с mood-данными через простую линейную регрессию на клиенте. Пользователи видят: «в дни, когда вы делали 8000+ шагов, ваше настроение в среднем на 0.8 балла выше».
Процесс работы
Сначала — аудит требований: какие метрики трекать, нужен ли бэкенд (мульти-устройства, шеринг с психологом), целевые платформы, нужна ли интеграция с HealthKit/Google Fit. Затем — проектирование модели данных и экранов, прототипирование в Figma, разработка, тестирование (XCTest / Espresso для unit, ручное на физических устройствах), публикация.
Ориентиры по срокам
MVP с журналом, базовой аналитикой и напоминаниями — 3–5 недель. Полноценное приложение с HealthKit/Google Fit, iCloud-синком, экспортом PDF и onboarding — 8–12 недель. Стоимость рассчитывается индивидуально после анализа требований.
Типичные ошибки при самостоятельной разработке
- Хранить mood-записи как строки вместо нормализованных enum'ов — потом аналитика невозможна без миграции.
- Запускать агрегацию на main thread в
viewDidAppear— пользователь видит фриз при открытии аналитики. - Игнорировать часовые пояса: если пользователь перелетел в другую страну, записи за «сегодня» попадают в «вчера». Хранить UTC, отображать в local timezone.
- Просить разрешение на уведомления при первом запуске без объяснения — отказ от разрешения обнуляет всю логику напоминаний навсегда (повторно запросить нельзя, только через Settings).