Escrever Kotlin pra terminal POS Sunmi é tipo dev Android só que tudo tá querendo te matar.
O Sunmi V2 Pro roda Android 7.1. Bicho, isso é de 2017. Metade das libs Jetpack não suporta. Tu tá escrevendo Kotlin com uma mão amarrada nas costas porque o API level alvo é da época que o povo ainda achava que Android Wear ia dar certo.
A impressora térmica é a estrela do show. Ela roda num serviço de sistema que trava a main thread por 200-400ms toda vez que imprime cupom. Tu vai pegar dialog de ANR se não tomar cuidado. Nossa solução: fila de impressão baseada em coroutine que joga tudo pra dispatcher background. Levou duas semanas pra ficar certo porque a doc do SDK da Sunmi é escrita num idioma que tecnicamente é inglês mas espiritualmente é mandarim.
Pagamento complica mais. Stone, Rede e Cielo têm SDKs com lifecycle, callbacks e interpretações criativas do que "sucesso" significa. Fizemos uma camada que normaliza tudo num único PaymentResult sealed class. Uma operadora nova precisa só de um adapter. Clean Architecture salva vida aqui.
A tela de 5.5 polegadas deixa pouco espaço pra layout chique. Aprendemos a desenhar pro terminal primeiro e adaptar pra tablet depois. O garçom usa isso no rush de sábado à noite com a mão suja de gordura, então precisa de botão grande e feedback claro, sem ambiguidade.
Testar em hardware real é inegociável. O emulador não tem impressora térmica, leitor NFC nem os quirks de timing do fork Android da Sunmi. A gente mantém quatro terminais físicos nas mesas, e todo PR passa por teste no ferro antes do merge. O emulador mente.
Não é trabalho glamoroso; ninguém escreve artigo no Medium sobre Kotlin num POS de restaurante. Só que esse código processa dinheiro de verdade pra restaurante de verdade todo santo dia. Quando quebra, alguém não recebe. Eu penso nisso quando escrevo cada linha.