Як я пишу Flutter-додаток для обліку батарей і обслуговування девайсів (BatDev)

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт. Мене звати Артем і я фулстек девелопер із основною спеціалізацією Drupal.

Відносно нещодавно почав вивчати Flutter для втілення своїх ідей в сфері мобільної розробки і хочу поділитися досвідом розробки цікавого додатку.

З чого все почалось

Після минулої зими у мене «померла» батарея електросамоката, а зарядна станція стала вимикатись коли на дісплеї було ще ~20%. Формально я знав, що Li-ion / LiFePO₄ треба підзаряджати на зберіганні і що в інструкції є інтервали обслуговування. На практиці це завжди було «не до того»: обстріли, життєві турботи, а коли є трохи часу, то вже не пам’ятаєш що і коли заряджав чи використовував. По суті немає єдиного місця, де видно, що саме сьогодні варто перевірити, і немає зручних нагадуваннь, коли пристрій місяцямі лежить десь у гаражі чи на верхній полиці.

Так з’явилась ідея BatDev — додатку менеджменту пристроїв з батареями, де по кожному девайсу завжди видно поточні статуси (використання / зберігання / обслуговування), історію, нотатки (ємність, пробіг на заряді тощо). Ну і головне — нагадування про обслуговування згідно рекомендаціям виробника.

Чому не Google Calendar і не «ще один todo»

Перша думка була доволі проста: поставити нагадування в календарі. Але вона швидко відпала.

У календарі немає моделі даних під девайс: тип батареї, інтервал у днях, прив’язка до статусу «на зберіганні», історія періодів, нотатки з датами. Для мене ключове було не «нагадати раз», а вести стан пристрою в часі: коли був у роботі, коли в зберіганні, коли робилось обслуговування — і з цього вже автоматично рахувати «коли наступне». Вести це вручну, коли девайсів десятки — для мене це просто пекло.

В голові одразу виникла ідея мобільного додатку. Якраз влітку я почав цікавитись і вивчати Flutter. Щоб не створювати «велосипед» я звісно перешерстив плеймаркет в пошукуів хоч чогось схожого по різним ключовим словам. Результат — тільки купа додатків для менеджменту батареї телефону. Тому я вирішив імплементувати ідею самостійно з активним використанням штучного інтелекту.

Стек (навмисно простий)

• Flutter / Dart
• один код під Android зараз, iOS пізніше.
• Isar (isar_plus) — локальна БД: Device, DeviceState, Note.
• http + session cookie до власного API на Drupal (каталог категорій/моделей, типи батарей, переклади UI)
• Без Firebase Auth/Firestore на цьому етапі: дані користувача живуть на телефоні; синхронізація на бек — окремий наступний етап.

Архітектурно розбив на модулі: add_device, device_list, device_page, notifications, settings, плюс _common (моделі, ApiClient, БД). Це не «enterprise», але допомагає не змішувати UI форми додавання з логікою нотифікацій.

Модель даних: статуси важливіші за «чекбокс обслужив»

Найважливіше і націкавіше саме для мене — історія. Це як з машиною — хочется знати коли було пройдено останє ТО, що коли мінялось, як часто ламається та чи інша деталь. На основі цих даних можна робити висновки о надійності авто, а можливо і о його продажу якнайшвидше.

Тому замість одного поля lastMaintenance я зберігаю весь ланцюжок періодів з певним статусом:

• state: 1 — активне використання, 2 — зберігання, 3 — обслуговування;
• startDate — початок періоду; кінець = старт наступного запису.

Так простіше будувати timeline / «графік використання» і рахувати рекомендовану дату обслуговування саме для режиму зберігання (якір — старт зберігання або останнє обслуговування + maintenance_interval у днях).

Окрема «колекція» — нотатки з датою: тут ми можемо писати будь які данні на певну дату в звичайному текстовому форматі.

Спочатку я планував поле «реальна ємність» де можна було б записувати ємність батареї і потім будувати графік старіння акумулятору і т.ін. Проте не завжди і не на всіх девайсах можна виміряти залишкову ємність. Тим більше якщо треба точно.

Тоді я думав зробити «відносну ємність» бо для якихось девайсів можна порахувати Аг чи Вт*г, а для інших гарний показник час роботи пристрою від одного заряду чи кількість накатаних кілометрів.

Проте знову ж таки, буває що треба записати ще якісь допоміжні данні — напругу на ячейках, чим заряджали, як зберігали і т.п. Саме тому я вирішив зупинитись на простоті — текстові нотатки з прив’язкою до дати, щоб через рік було з чим порівняти.

Локалізація не через arb-файли, а через API

Звертаючи увагу, що перевірка реліз білду в гугл-плей може займати тиждень, була мета — додавати нові локалізації в додаток без створення нового білду. Тож питання транслейшенів винесено на сторону бекенду. В друпал через кастомний модуль додаємо потрібні строчки та переклади з контекстом «mobile_app» (щоб не плутатитись з перекладами з ядра).

При старті додатку UI-рядки тягнуться з /{lang}/api/translation, а список достпупних мов — з /api/translations. Каталог кешується локально (SharedPreferences), щоб перший кадр не чекав мережу.

Що робив з AI (Cursor), а що лишалось «головою»

Писав/рефакторив багато з асистентом: форми add/edit, міграція API-ключів, Isar-схема, autocomplete моделей. Корисно на рутині й на «пройдись по rename скрізь».

Але рішення «що є джерелом правди» (локальна БД vs Drupal catalog), як моделювати статуси, що синхронізувати пізніше без картинок — це все одно продуктові/архітектурні вибори. AI добре виконує план; погано сам вирішує, який план правильний, якщо йому згодувати рекламний опис замість обмежень.

Що свідомо ще не зроблено

• синхронізація девайсів користувача на бекенд — було б досить зручно на випадок перевстановлення додатку, заміни телефону і т.п. щоб додаток підтягував минулі девайсі і їх історію статусів. Можливо буде в майбутніх версіях;
• iOS — хочу максимально відкатати додаток на Андроїд, зібрати відгуки і проаналізувати доцільність виходу на iPhone, бо Аппстор — це нова для мене тема, ще й щорічний девелоперський збір. Тож треба продумати й модель монетизації;
• повне наповнення каталогу моделей — наповнення буде йти по ходу роботи додатку. Почну з популярних моделей зарядних станцій, в перспективі додати більш широкий спектр відомих моделей (повербанки, LiFePO4 акумулятори, самокати і т.д.);
• публічний реліз у Play — наразі додаток перебуває у стадії закритого тестування і доступний за посиланням лише для учасників групи раннього доступу. Тож доєднуйтесь до групи і встановлюйте додаток.

На тесті повний функціонал без реклами — не як «маркетингова акція», а щоб швидше зібрати реальні сценарії, отримати цінні відгуки та наповнити каталог девайсів.

Висновки на зараз

1. Для такого продукту важливіша модель часу (статуси/інтервали), ніж красивий список девайсів.
2. Чим простіше, тим краще — онлайн каталог популярних моделей девайсів, кастомні нотатки на дату.
3. При плануванні архітектури слід продумати збільшення функціоналу, кількості девайсів, додавання перекладів без необхідності постійного оновлення продакшен релізу.
4. Closed testing корисний саме як інженерний етап для збору відгуків, побажань і можливих багів.
5. AI — значно економить час і може допомогти в написанні коду, проте найважливіші архітектурні рішення саме за вами. І нести відповідальність чи відчувати наслідки цих рішень будете саме ви )

Задавайте питання, озвучуйте ідеї в коментарях.
Хто хоче отримати ранній доступ і доєднатися до закритого тестування на Android доєднуйтесь до групи після чого встановлюйте додаток BatDev з гугл-плей. До кінця цього року в планах виход і на IPhone.

Бажаю, щоб ваші зарядні станції та ліхтарики не знадобились вам цієї зими, проте не забувайте про вчасне обслуговування, щоб бути напоготові!

P.S. Далі ще декілька скріншотів для загального розуміння ідеї і функціоналу додатку.