Um broker MQTT para apps móveis permite que o celular veja os dados de um dispositivo no instante em que eles mudam e envie comandos de volta com pouquíssimo overhead. Este guia explica como os apps móveis devem se conectar, quando o MQTT é a ferramenta certa e quando as notificações push da plataforma são, como manter baixo o consumo de bateria e como lidar com credenciais com segurança, com um exemplo funcional usando a ConnectMQ.
Por Que Apps Móveis Usam MQTT
Apps móveis de IoT geralmente precisam de três coisas: mostrar o estado em tempo real (a porta está trancada, qual é o nível do reservatório da fazenda), enviar comandos (ligar a bomba de irrigação) e reagir rapidamente a mudanças. Fazer polling em uma API REST a cada poucos segundos entrega as três de forma ruim: desperdiça bateria e dados, adiciona latência e sobrecarrega o backend. O MQTT mantém uma única conexão de longa duração aberta enquanto o app está ativo e envia apenas o que mudou.
O broker no meio desacopla o app dos dispositivos. O celular nunca precisa saber o endereço IP de um dispositivo; os dois lados conversam com um endpoint conhecido. Se esse papel é novo para você, leia primeiro o que um broker MQTT faz.
Opções de Conexão a Partir de um Celular
| Transporte | URL | Quando usar |
|---|---|---|
| MQTT sobre TLS | mqtts://broker.connectmq.com:8883 |
Apps nativos com uma biblioteca MQTT com suporte a TCP (Kotlin, Swift, Flutter) |
| MQTT sobre Secure WebSocket | wss://broker.connectmq.com:8084/mqtt |
React Native, Ionic, PWAs e webviews; redes que bloqueiam a 8883 |
Ambos são criptografados e funcionam com MQTT 3.1.1 e 5.0. O WebSocket costuma ser o caminho de menor resistência em apps baseados em JavaScript e em redes Wi-Fi restritivas; o TLS nativo é ligeiramente mais eficiente. Nunca use as portas sem criptografia 1883 ou 8083 em um app de produção. O guia de MQTT sobre WebSocket explica o transporte WebSocket em profundidade.
MQTT vs Notificações Push
Esta é a decisão de design mais importante, e a resposta normalmente é "os dois".
| Necessidade | MQTT | Push da plataforma (APNs / FCM) |
|---|---|---|
| Atualizações ao vivo com o app aberto | Excelente | Pouco adequado |
| Alertas com o app fechado | Não confiável | Feito para isso |
| Comandos bidirecionais | Sim | Não |
| Custo de bateria em segundo plano | Alto se mantido aberto | Gerenciado pelo sistema operacional |
| Entrega com o celular offline | Sessão persistente enquanto durar | Enfileirada pela plataforma |
Os sistemas operacionais móveis suspendem apps em segundo plano e seus sockets. O iOS, em particular, não permite manter uma conexão MQTT aberta indefinidamente em segundo plano. Por isso, a arquitetura robusta é:
- Primeiro plano: o app conecta ao broker, assina os dispositivos que o usuário está visualizando e envia comandos via MQTT.
- Segundo plano: o app se desconecta de forma limpa. Um pequeno serviço de backend assina os topics de alerta no broker e envia notificações push da plataforma quando algo importante acontece.
- Volta ao primeiro plano: o app reconecta, as retained messages entregam imediatamente o estado atual e a interface fica atualizada em instantes.
O relay de backend do passo 2 é apenas mais um cliente MQTT que você executa, por exemplo um serviço em Node.js ou Python. A ConnectMQ não envia notificações push por conta própria, e manter essa lógica no seu próprio serviço dá a você controle sobre quais eventos viram notificações.
Considerações sobre Bateria e Dados
- Conecte apenas quando necessário. Abra a conexão quando a tela relevante aparecer e feche-a quando o app for para o segundo plano.
- Assine de forma restrita. Assine
home/42/devices/+/state, não#. Cada mensagem recebida custa tempo de rádio. - Use retained messages para o estado. O app recebe o último valor conhecido na hora da assinatura, então você nunca precisa fazer polling ou pedir uma atualização.
- Escolha um keep alive moderado. De 30 a 60 segundos equilibra a detecção rápida de conexões mortas com menos despertares do rádio.
- Mantenha os payloads compactos. Chaves JSON curtas ou codificações binárias ajudam em links celulares.
- Use topic aliases e message expiry do MQTT 5 quando houver suporte. Os aliases reduzem nomes de topic longos e repetidos; o message expiry impede que comandos obsoletos sejam entregues com atraso.
- Faça backoff na reconexão. Redes móveis mudam o tempo todo; backoff exponencial evita loops apertados de nova tentativa que drenam a bateria.
Exemplo Funcional: React Native ou Web com MQTT.js
O MQTT.js roda em navegadores e no React Native via WebSocket. Este módulo encapsula conexão, assinatura e tratamento do ciclo de vida do app.
import mqtt from "mqtt";
const BROKER_URL = "wss://broker.connectmq.com:8084/mqtt";
export function createDeviceConnection({ clientId, username, password, homeId, onState }) {
const client = mqtt.connect(BROKER_URL, {
clientId,
username,
password,
protocolVersion: 5,
keepalive: 45,
clean: true,
reconnectPeriod: 3000,
connectTimeout: 10000,
});
const stateTopic = `homes/${homeId}/devices/+/state`;
client.on("connect", () => {
client.subscribe(stateTopic, { qos: 1 }, (err) => {
if (err) console.warn("Subscribe failed", err.message);
});
});
client.on("message", (topic, payload) => {
const deviceId = topic.split("/")[3];
try {
onState(deviceId, JSON.parse(payload.toString()));
} catch {
console.warn("Ignoring non-JSON payload on", topic);
}
});
client.on("error", (err) => console.warn("MQTT error", err.message));
return {
sendCommand(deviceId, command) {
client.publish(
`homes/${homeId}/devices/${deviceId}/cmd`,
JSON.stringify(command),
{ qos: 1, properties: { messageExpiryInterval: 30 } }
);
},
pause() {
client.end(false);
},
resume() {
if (!client.connected) client.reconnect();
},
};
}
No React Native, chame pause() e resume() a partir de um listener de mudança do AppState. O message expiry de 30 segundos significa que um comando enfileirado enquanto um dispositivo está offline não será disparado inesperadamente minutos depois. Algumas configurações de React Native precisam de um polyfill de WebSocket ou de Buffer; confira o guia de MQTT no React Native para os detalhes de cada plataforma e o de MQTT no Flutter se você desenvolve com Dart.
Para experimentar sem conta, aponte-o para o servidor MQTT público gratuito, omita username e senha, use qualquer client ID único e não vazio e prefixe os topics com algo exclusivo, como connectmq/demo/m7d2w/homes/.... Tudo na área pública pode ser lido por qualquer pessoa, então use-a apenas para demos.
Lidando com Credenciais com Segurança
O binário de um app móvel pode ser descompilado, então trate como público tudo o que estiver embutido nele.
- Não distribua uma única senha de broker compartilhada no app. Se ela vazar, o tráfego de todos os usuários fica exposto e você não consegue revogá-la sem quebrar todas as instalações.
- Emita credenciais por usuário ou por sessão a partir do seu backend. Depois que o usuário faz login no seu app, sua API retorna as credenciais MQTT e o client ID que aquele usuário deve usar.
- Delimite os topics por usuário ou por casa. Projete os topics de modo que os dados de cada usuário fiquem sob um prefixo próprio, e aplique no dispositivo e no backend quais comandos são aceitos de quem.
- Rotacione e revogue. Quando um usuário sai da conta ou um celular é perdido, revogue as credenciais dele.
- Valide os comandos no dispositivo ou no backend. Nunca confie que um comando veio de uma tela legítima.
A ConnectMQ vincula os client IDs às credenciais emitidas e bloqueia IPs após repetidas falhas de login, o que ajuda contra credential stuffing. Leia boas práticas de segurança MQTT para a lista completa.
Planejamento de Capacidade para Apps
Cada app aberto é uma conexão. Dez dispositivos e cinquenta usuários ativos no app significam sessenta conexões simultâneas no pico, não dez. O ConnectMQ Serverless (Free) permite até 25 conexões, o que atende ao desenvolvimento e a um beta pequeno; o Serverless (Paid) vai até 1.000 conexões, com QoS 2 e shared subscriptions; clusters dedicados atendem públicos maiores. Como os apps se desconectam em segundo plano, as conexões simultâneas costumam ser bem menos numerosas do que as instalações, mas meça o seu padrão real em vez de adivinhar.
Para as opções de hospedagem por trás desses planos, veja o guia de broker MQTT na nuvem.
Conecte Seu App à ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, teste seus topics no cliente no navegador e aponte o exemplo com MQTT.js para o seu novo endpoint. A ConnectMQ é um broker MQTT gerenciado com endpoints TLS e Secure WebSocket prontos para clientes móveis desde o primeiro minuto.
Perguntas frequentes
Um app móvel consegue manter uma conexão MQTT aberta em segundo plano?
Não de forma confiável. Os sistemas operacionais móveis suspendem sockets em segundo plano, então use MQTT enquanto o app estiver em primeiro plano e notificações push da plataforma para alertas em segundo plano.
Um app móvel deve usar WebSocket ou TCP para MQTT?
Apps baseados em JavaScript geralmente usam Secure WebSocket na porta 8084 com path /mqtt. Apps nativos podem usar TLS na 8883; ambos são criptografados.
Como obtenho o estado atual do dispositivo quando o app abre?
Faça os dispositivos publicarem o estado como retained messages. O broker entrega o valor mais recente imediatamente quando o app assina.
É seguro embutir credenciais do broker em um app móvel?
Não. Emita credenciais por usuário a partir do seu backend após o login, para que uma credencial vazada possa ser revogada individualmente.
