Kern
App de saúde local-first em que a decisão de produto foi mostrar o dado cru e separar "sem permissão" de "permitido, sem dado" — em vez de esconder as duas coisas atrás de um traço.
Função
Creative Developer & Mobile Architect
Período
2024 - 2026
Cliente / Contexto
Projeto próprio
Tecnologias
Tipos de dado lidos
33Estados de cobertura
4Quadros no Android
60 FPSO problema
O Kern lê o que uma pulseira e uma balança publicam no Health Connect do Android. O problema que quase afundou o app não foi renderizar 3D em celular intermediário. Foi confiar no dado. Quando um painel mostra um traço no lugar de um número, existem três causas diferentes por trás: o usuário não deu a permissão, o fabricante não escreveu nada, ou a leitura falhou. Um dashboard comum apaga essa diferença. E apagar a diferença é o que faz alguém tomar decisão sobre o próprio corpo em cima de um dado que nunca existiu.
A decisão
Duas decisões carregam o produto. A primeira: **o dado cru fica permanente na tela**, embaixo dos painéis de tendência: tipo, origem, aparelho e o JSON como chegou. Não é modo de depuração; é o que permite descobrir se um número estranho é erro da conta ou erro do dado. O mesmo padrão validou o protocolo da balança, mostrando o hex ao lado do valor interpretado. A segunda: **a cobertura tem quatro estados nomeados** — "sem permissão", "permitido, sem dado", "erro na leitura" e ok. Um é decisão do usuário, o outro é decisão do fabricante; unificá-los num traço apaga exatamente o que se quer saber. Isso também custou uma decisão de arquitetura: o plugin pronto da comunidade converte só 5 tipos para JSON de verdade e devolve o resto como texto, então escrevi um plugin nativo próprio em Kotlin lendo o catálogo inteiro, 33 tipos. Kotlin entrou contra uma decisão anterior de "sem Kotlin no app", porque a API do Health Connect só existe em corrotina e chamá-la de Java exigiria montar Continuation na mão.
O resultado
O app roda a 60 FPS em celular intermediário, funciona inteiro offline e lê 33 tipos do Health Connect com JSON estruturado. O achado que justifica a abordagem apareceu justamente por causa dela: o código pedia a permissão de frequência cardíaca pelo nome "HeartRate", mas a chave real da androidx é "HeartRateSeries", conferida no bytecode do connect-client porque a documentação não diz. A API descarta chave desconhecida em silêncio, então três funcionalidades nunca tinham rodado, sem nenhum erro na tela. Uma interface que só mostrasse um traço teria escondido isso indefinidamente.