Розробка мобільного застосунку для передачі показань лічильників ЖКГ

Розробка мобільного застосунку для передачі показань лічильників ЖКГ

Уявіть: мешканець відкриває застосунок, бачить список лічильників, вводить показання та надсилає. Здається, що все просто. Але на ділі кожна помилка валідації, кожен збій OCR на блискучому циферблаті перетворює рутинне завдання на головний біль для керівних компаній. Ми вирішуємо такі проблеми вже 5 років: спроєктували та запустили 12 застосунків для передачі показань з інтеграцією в 1С, РКЦ та Інфократ. Наш досвід — 50+ проєктів у сфері ЖКГ.

Як працює основна механіка та де вона ламається?

Мешканець заходить у застосунок, бачить список лічильників за своїм особовим рахунком (вода холодна, гаряча, електрика, газ), вводить показання та надсилає. Це — 80% випадків. Решта 20% створюють 80% проблем. Розберемо три ключові вузли.

Валідація показань

Показання не можуть бути меншими за попередні — крім випадку заміни лічильника. Якщо різниця між поточними та попередніми перевищує порогове значення (наприклад, 50 кубів води за місяць — підозріло), система має запитати підтвердження, а не мовчки прийняти. Пороги — налаштовувані параметри в адміністративній панелі, не захардкоджені константи. Це дозволяє керівній компанії гнучко змінювати ліміти без оновлення застосунку.

Дедлайн передачі

Більшість КК приймають показання з 15 по 25 число. За межами цього вікна форма має бути заблокована зі зрозумілим повідомленням — не просто «помилка», а «Показання приймаються з 15 по 25 число. Наступне вікно відкриється через X днів». Реалізується через серверний конфіг, не через логіку в застосунку.

OCR-введення через камеру

ML Kit Text Recognition (Android) / Vision Framework (iOS) для розпізнавання цифр з екрана лічильника. У теорії зручно — на практиці розпізнавання роликового лічильника з відблисками працює в 60-70% випадків. Тому OCR — допоміжний інструмент, не заміна ручному введенню. Результат розпізнавання заповнює поле, мешканець підтверджує або виправляє.

OCR працює в 2 рази швидше за ручне введення, але точність розпізнавання рукописних цифр на 15% нижча — тому ми робимо OCR допоміжним, а не основним методом. При цьому 80% застосунків відмовляють в апруві App Store через некоректне використання камери — ми врахували це в архітектурі (див. Guidelines 5.1 — Apple Developer).

Для тестування OCR на реальних даних запитайте демо-доступ.

Як уникнути помилок при валідації показань?

Найчастіша проблема — ігнорування неочевидних кейсів: заміна лічильника, аварійне збільшення витрати (прорив труби), передача нульових показань при відсутності проживання. У нашому рішенні кожен виняток обробляється окремим правилом: якщо різниця між показаннями від'ємна — запитуємо підтвердження з прикріпленням фото; якщо перевищує поріг — блокуємо відправлення до дзвінка оператору. Усі правила налаштовуються в адмін-панелі.

Як відбувається інтеграція з білінгом?

Найважливіша частина. Дані мають потрапити в систему обліку керівної компанії — 1С:Бухгалтерія, РКЦ, Інфократ або іншу. Способи: REST API (якщо білінг підтримує), файловий обмін XML/CSV за розкладом, прямий запис у базу (з дозволу вендора — рідко, але буває). На стороні нашого бекенду (Laravel + PostgreSQL) зберігається історія всіх переданих показань з timestamp, device ID та IP — для розбору суперечок про те, чи були показання передані та коли.

Порівняння способів інтеграції:

Чому інтеграція з білінгом — найвужче місце?

Тому що кожна КК використовує свою систему: 1С, РКЦ, Інфократ, Альфа-Діалог, Міські портали. Універсального API немає. Ми розробляємо адаптер під конкретний білінг на основі його документації. На практиці 30% часу йде на узгодження форматів даних та тестування прийому на стороні замовника. Щоб прискорити процес, ми надаємо специфікацію API та допомагаємо налаштувати прийом даних. Гарантуємо, що після здачі дані передаватимуться коректно.

Процес роботи

1. Аналітика — вивчаємо поточний білінг, схеми даних, бізнес-процеси КК.
2. Проєктування — дизайн екранів (Figma), опис API, прототип валідації.
3. Розробка — Flutter + Dart, Laravel 10 API, PostgreSQL.
4. Тестування — на 10+ пристроях (iOS та Android), включаючи моделі з різними версіями ОС.
5. Інтеграція — налаштування обміну з білінгом, завантаження тестових даних.
6. Запуск — публікація в App Store та Google Play, налаштування push-сповіщень (FCM), навчання операторів.
7. Підтримка — гарантійне обслуговування 3 місяці.

Що входить у результат

• Вихідний код застосунку (Flutter) з коментарями.
• Документація API (Swagger/OpenAPI).
• Адміністративна панель для налаштування порогів та вікон передачі.
• Інструкція для операторів (3–5 сторінок).
• Сертифікати підпису (iOS provisioning profile, Android keystore).
• Доступи до App Store Connect та Google Play Console.
• Навчання співробітників (відеодзвінок 1–2 години).

Терміни та вартість

Терміни — від 5 до 8 тижнів залежно від складності інтеграції. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Ми надамо детальний кошторис протягом 2 робочих днів.

Отримайте консультацію з інтеграції білінгу — наші інженери проаналізують вашу поточну систему та запропонують оптимальне рішення.

Як обрати кроссплатформну розробку: Flutter, React Native чи KMM?

Коли потрібен додаток на iOS та Android, а бюджет на дві окремі команди — постає питання вибору фреймворку. Ми бачили проєкти, де неправильний вибір призводив до переписування через півроку. Кожен інструмент диктує свій стек і накладає обмеження. Перед стартом проводимо аудит технологічних вимог та експертизи команди.

Три основні гравці зараз: Flutter, React Native та Kotlin Multiplatform Mobile. Вони вирішують різні проблеми і погано порівнюються в лоб. Нижче розберемо, як обрати оптимальний варіант під ваш проєкт.

Кроссплатформна розробка: основні критерії вибору

Перше — зрозуміти, що саме ви будете робити: багатий брендовий UI чи нативний look and feel? Друге — якою мовою володіє команда. Якщо це JavaScript/TypeScript — React Native дає швидкий старт. Якщо Dart — Flutter. Якщо хочуть оптимізувати логіку — KMM. Третє — які нативні API будуть задіяні: камера, Bluetooth, фонові оновлення. Для деяких стеків інтеграція складніша.

Як ми обираємо кроссплатформний фреймворк?

1. Аналіз вимог — список нативних API, необхідність автономної роботи, брендовий UI або стандартний.
2. Оцінка команди — експертиза в Dart, JavaScript/Kotlin, наявність iOS-розробника.
3. Прототип (proof-of-concept) — реалізація критичного сценарію на обраному стеку за 2–3 дні.
4. Фінальне рішення — на основі бенчмарків продуктивності та вартості підтримки.

Чим відрізняються Flutter і React Native?

Це порівняння, яке реально впливає на вибір. Розберемо за конкретними технічними характеристиками.

Модель рендерингу

Flutter рендерить UI самостійно через Impeller (замінив Skia починаючи з версії 3.10). Платформа надає лише canvas — Flutter малює кожен піксель сам. Це означає:

• Піксельна точність на всіх платформах. Один і той же віджет виглядає однаково на iOS та Android — добре для брендових додатків, погано якщо потрібно виглядати «нативно» на кожній платформі.
• Немає залежності від версії ОС. Material 3 у Flutter працює однаково на Android 8 та Android 14. Системні компоненти Android не беруть участі.
• Platform channels для нативного коду. Доступ до камери, Bluetooth, NFC — через MethodChannel або EventChannel. flutter_camera, flutter_blue_plus — це обгортки над platform channels.

React Native використовує нативні компоненти платформи. <View> на iOS — це UIView. <Text> — це UILabel. Це означає:

• Нативний look and feel без додаткових зусиль.
• New Architecture (Fabric + TurboModules) з JSI прибрала JSON-міст між JS та нативним кодом. Синхронні виклики працюють без серіалізації. Це критично для анімацій та жестів.
• React Native Reanimated 3 запускає worklets на UI thread — анімації в 60/120 fps без блокування JS thread.

Продуктивність на практиці

Для більшості бізнес-додатків різниця в продуктивності між Flutter та React Native New Architecture непомітна користувачеві. Різниця з’являється в граничних випадках.

Flutter повільніший при взаємодії з платформеними API через platform channels — кожен виклик асинхронний, є накладні витрати на серіалізацію даних. google_maps_flutter рендерить карту через PlatformView — це нативний UIView/View, вбудований у Flutter-дерево. До Impeller це викликало проблеми з продуктивністю (Hybrid Composition vs Virtual Display). З Impeller ситуація покращилась, але PlatformView все ще дорожчий за чистий Flutter-віджет.

React Native повільніший у сценаріях з важкою JS-логікою на main thread. Парсинг великого JSON, складні обчислення — це блокує JS thread і видно як фриз UI. Рішення: Hermes (JS-двигун, оптимізований для RN) + винесення обчислень у нативний модуль або react-native-workers. З Hermes час холодного старту знижується на 30–40% порівняно з JavaScriptCore, тобто Hermes у 1,3–1,4 раза швидше за старий двигун.

Екосистема та зрілість

Dart — бар’єр входу для команд з JS/TS-бекграундом. Освоїти базовий Dart за тиждень реально. Перебудувати мислення під Flutter-віджети та widget tree — займає більше. TypeScript у React Native — стандарт де-факто. Команда з React-досвідом починає продуктивно швидше.

Коли обирати Flutter?

Коли обирати React Native?

• Команда з React/TypeScript-експертизою.
• Потрібен нативний look and feel платформи.
• Активне використання нативних компонентів (Maps, Camera з нативними можливостями).
• Шарінг коду з React-вебом через монорепозиторій.

Чи варто обирати KMM для вашого проєкту?

KMM вирішує не UI-проблему, а проблему дублювання бізнес-логіки. Концепція: пишемо бізнес-логіку, роботу з мережею, кеш, валідацію один раз на Kotlin. iOS отримує .framework через Kotlin/Native, Android використовує бібліотеку безпосередньо. UI на кожній платформі — нативний.

// Спільний Kotlin код — працює на iOS та Android
class UserRepository(
    private val httpClient: HttpClient, // Ktor
    private val database: AppDatabase   // SQLDelight
) {
    suspend fun getUser(id: String): User {
        return database.userQueries.selectById(id).executeAsOneOrNull()
            ?: httpClient.get("$BASE_URL/users/$id").body<User>().also {
                database.userQueries.insert(it)
            }
    }
}

Ktor — HTTP-клієнт для KMM (працює на iOS через Darwin engine, на Android через OkHttp). SQLDelight генерує typesafe Kotlin API для SQLite, працює на обох платформах.

Реальні обмеження KMM

Coroutines на iOS: suspend-функції з shared коду викликаються через автоматично згенеровані обгортки. SKIE (Swift/Kotlin Interface Enhancer) від Touchlab значно покращує Swift-інтерфейс: async/await замість callback, AsyncStream для Flow. Без SKIE працювати з coroutines із Swift незручно.

Compose Multiplatform: JetBrains розвиває Compose для iOS — UI на Compose працює на iOS через Metal. Це стирає межу з Flutter: один Compose-код для обох платформ. Статус на сьогодні: Beta, у production є ранні adopters (Touchlab, JetBrains власні продукти), але стабільність нижче Flutter.

Складність iOS-інтеграції: XCFramework з KMM-модуля додається в Xcode-проєкт. SPM-інтеграція з’явилась і працює. Але iOS-розробники повинні розуміти Kotlin-API та правила роботи з пам’яттю через Kotlin/Native (ARC + Kotlin GC працюють разом, це не завжди очевидно).

Коли KMM виправданий

У компанії вже є зрілі iOS та Android команди, які дублюють бізнес-логіку. Переводити все на Flutter або React Native — занадто радикально. KMM дозволяє почати з малого: винести мережевий шар і моделі в shared, залишити UI нативним. Поступова міграція без переписування всього.

«Маєте нативний досвід — використовуйте React Native, хочете контролювати кожен піксель — Flutter» — один із принципів, який ми застосовуємо під час консультацій.

Помилки, яких варто уникати при виборі стеку

Вибір Flutter «тому що одна кодова база» для додатку, який сильно зав’язаний на нативні API (custom camera, BLE, background processing). Реалізовувати це через platform channels — додаткова складність, яка з’їдає виграш у швидкості розробки.

React Native без розуміння JS-thread. Важкі операції на JS thread дають видимі фризи. Це вирішувано, але потребує розуміння архітектури — інакше додаток працюватиме гірше нативного.

KMM без iOS-розробника в команді. Shared Kotlin-код потребує iOS-інженера, який інтегрує фреймворк у Xcode, пише SwiftUI поверх KMM API та дебажить Kotlin/Native-краші.

Процес і терміни

Кроссплатформний проєкт проходить ті ж етапи, що й нативний: аудит вимог → вибір стеку → дизайн → розробка → тестування на реальних пристроях обох платформ → публікація в App Store та Google Play → підтримка.

Тестування на реальних пристроях — не опціональний етап. Емулятор не відтворює проблеми з пам’яттю на бюджетних Android-телефонах і не показує різницю в поведінці жестів на iOS.

Економія бюджету порівняно з двома нативними командами сягає 40–50%. Для проєкту середньої складності це становить $40,000–$80,000 на етапі MVP. Вартість розраховується індивідуально після аналізу стеку та вимог.

Що входить у нашу роботу

• Технічний аудит та вибір стеку під ваш проєкт.
• Проєктування архітектури (чиста архітектура, MVVM, BLoC/Redux).
• Розробка UI за макетами дизайну на обидві платформи.
• Інтеграція нативних модулів (камера, геолокація, пуш-повідомлення).
• Налаштування CI/CD (GitHub Actions, Codemagic).
• Тестування на реальних пристроях (iOS/Android) — не менше 40 сценаріїв.
• Підготовка та публікація в App Store і Google Play з урахуванням гайдлайнів (App Store Review, Google Play Policy).
• Технічна підтримка 3 місяці після запуску.
• Передача вихідного коду, документації, доступів — все під ключ.

Ми маємо 5+ років досвіду в кроссплатформній розробці, реалізували понад 30 успішних проєктів. Гарантуємо дотримання строків та якість коду. Зв'яжіться з нами для аудиту вашого проєкту — підберемо оптимальний стек за один день. Отримайте консультацію з вибору стеку вже сьогодні, замовте розробку під ключ та отримайте готовий кроссплатформний додаток в обумовлені терміни.