Інтеграція MQTT-протоколу для IoT-комунікації в мобільному додатку
MQTT — не просто «легкий» протокол для IoT. Це publish/subscribe поверх TCP з гарантіями доставки (QoS 0/1/2), персистентними сесіями та повідомленнями «останньої волі» (Last Will). Для мобільних додатків, які керують пристроями або моніторять сенсори в реальному часі, MQTT — правильний вибір. Але мобільна специфіка (фон, батарея, нестабільна мережа) вимагає ретельного налаштування.
QoS та його реальна вартість
QoS 0 — fire and forget. Повідомлення відправлено, підтвердження немає, дублікатів немає. Для відображення телеметрії (температура, GPS) — нормально, втрата одного пакета не критична.
QoS 1 — at least once. Broker підтверджує отримання PUBACK. Клієнт зберігає повідомлення до отримання PUBACK і повторює при необхідності. Можливі дублікати. Для команд пристрою (включити/вимкнути) — найчастіше достатньо.
QoS 2 — exactly once. Чотирифазне рукостискання: PUBLISH → PUBREC → PUBREL → PUBCOMP. Гарантує рівно одну доставку. Для фінансово значущих команд або критичних операцій. Вартість — подвійний трафік, подвійна затримка.
На мобілі QoS 2 у фоні — проблема. Чотирифазний обмін вимагає стабільного з'єднання протягом кількох RTT. При втраті мережі серед handshake сесія «застряє» до переподключення. На iOS з обмеженнями фону — майже гарантований збій. Рекомендуємо QoS 1 + idempotent команди на стороні пристрою.
Клієнтські бібліотеки та їх підводні каміння
Android: Eclipse Paho Android Service — de facto стандарт, але офіційно не підтримується з 2021 року. Альтернатива — HiveMQ MQTT Client (com.hivemq:hivemq-mqtt-client), активно підтримується, працює з Kotlin Coroutines через kotlinx.coroutines. Для MQTT 5 — лише HiveMQ.
iOS: CocoaMQTT (Swift) або MQTTNio (SwiftNIO-based). CocoaMQTT простіше в налаштуванні, MQTTNio краще масштабується для високочастотних потоків.
Flutter: mqtt_client — популярна бібліотека, підтримує MQTT 3.1.1. Підтримка MQTT 5 поки що немає. Для WebSocket-транспорту (MQTT поверх WSS, не TCP) — MqttServerClient vs MqttBrowserClient — використовуйте правильний.
React Native: немає нативного MQTT. Варіанти: react_native_mqtt (обгортка над нативними Paho для Android/iOS) або WebSocket-транспорт з mqtt.js (працює в RN без polyfills при WSS).
Управління з'єднанням на мобілі
Keep-alive interval (CONNECT пакет, поле keepAlive) — broker закриває з'єднання, якщо не отримає PINGREQ протягом keepAlive * 1.5 секунд. Типові значення для мобіля: 30–60 секунд. Менше — більше трафіку й розходу батареї. Більше — ризик не помітити розрив вчасно.
Last Will Message: при реєстрації з'єднання вкажіть willTopic та willMessage (наприклад {"status":"offline"}). Якщо з'єднання розірветься аварійно (без DISCONNECT), broker автоматично опублікує це повідомлення. UI інших клієнтів бачить статус пристрою як offline без додаткової логіки.
Persistent Session (cleanSession: false в MQTT 3.x, sessionExpiryInterval > 0 в MQTT 5): broker зберігає очередь QoS 1/2 повідомлень для клієнта, поки він офлайн. При переподключенні клієнт отримує накопичені повідомлення. Критично для IoT-команд, які повинні дійти до пристрою навіть при тимчасовому відключенні. Зберігайте clientId постійним — обов'язковою умовою для роботи персистентної сесії.
TLS та аутентифікація
Для production: MQTT over TLS (mqtts://, порт 8883). Взаємна TLS-аутентифікація (mTLS) — стандарт для IoT-пристроїв, але для мобільного клієнта зазвичай достатньо: username/password + серверний TLS-сертифікат.
На Android: зберігайте credentials в EncryptedSharedPreferences. На iOS: Keychain. Не hardkodьте URL broker'а та credentials у коді — використовуйте remote config або sealed secrets у CI.
Орієнтири за часом для інтеграції MQTT в існуючий мобільний додаток — 1–3 тижні залежно від складності topic-схеми та вимог до offline-режиму.