Em uma rede de telas, uma interrupção pode exigir que alguém vá até a loja para reiniciar um equipamento. Uma conexão instável pode atrasar a programação. Uma atualização pode corrigir a reprodução e, ao mesmo tempo, introduzir uma incompatibilidade com o aplicativo instalado.
É nesse cenário que desenvolvemos o Player da Lucimark. O objetivo é manter a programação em exibição, reduzir interrupções visíveis e recuperar a operação automaticamente sempre que as condições do dispositivo permitirem.
O Player tem como base uma aplicação web, compartilhada entre a versão para navegador e o aplicativo Android. Essa escolha permite reutilizar a lógica de reprodução. Também exige cuidado: armazenamento, atualização e acesso ao hardware têm capacidades diferentes em cada ambiente.
Para orientar essas decisões, trabalhamos com um contrato de reprodução: executar a programação recebida, preparar o próximo conteúdo, retomar a operação após interrupções e fornecer sinais que ajudem a entender uma falha. Esse contrato guia o comportamento esperado nas duas plataformas, respeitando os limites de cada uma.
Um núcleo compartilhado, capacidades diferentes
Manter versões independentes do player significaria evoluir duas implementações da sequência de reprodução, do cache e da recuperação de falhas. Com o núcleo compartilhado, essas regras podem ser desenvolvidas e verificadas em conjunto.
Uma camada de integração adapta o armazenamento, a identificação do dispositivo e as atualizações a cada ambiente. No Android, ela também permite acessar recursos do equipamento que ajudam a controlar sua operação.
Compartilhar a mesma base, porém, não torna as capacidades equivalentes. O aplicativo Android integra recursos do sistema para manter a tela ativa. No navegador, o Player também tenta manter a tela ligada quando está em tela cheia ou instalado como aplicativo web, se o navegador oferecer esse recurso; fora dessas condições, a página precisa permanecer visível.
Essa distinção precisa fazer parte do projeto: uma capacidade indisponível deve ter um comportamento previsto. Para o operador, importa saber quais condições são necessárias para manter aquela tela em funcionamento.
A sequência de reprodução e o que aparece na tela
Durante a reprodução, o player precisa decidir qual conteúdo está ativo e preparar o seguinte. Na Lucimark, essa sequência é organizada por uma lógica compartilhada entre as duas plataformas.
O player mantém o conteúdo atual e prepara o próximo. Na troca, atualiza em conjunto o conteúdo e a indicação do que deve estar visível. Essa coordenação evita que a tela exiba um item diferente do previsto para aquele momento.
Também precisamos cuidar da medição do tempo. O player acompanha a duração da reprodução de forma independente dos ajustes no horário do dispositivo. Assim, uma correção no relógio não altera a sequência em andamento.
Quando a página fica oculta, o player adapta a forma de acompanhar a sequência. Ao voltar a ficar visível, reajusta o estado da reprodução. Esse mecanismo ajuda a recuperar o estado após limitações de execução em segundo plano. Para a operação contínua, o equipamento precisa manter o player ativo e visível.
Há ainda uma diferença entre selecionar o próximo conteúdo e ter esse conteúdo pronto para aparecer. Um vídeo pode precisar de tempo para apresentar a primeira imagem. Por isso, a camada de apresentação também tem mecanismos para manter temporariamente o conteúdo anterior enquanto o seguinte fica pronto, com limites de espera. Essas medidas reduzem interrupções visíveis durante as transições e precisam ser verificadas nas condições reais de uso do equipamento.
Uma atualização também precisa de um caminho de volta
No Android, separamos as atualizações em dois caminhos:
| Caminho | O que muda | Quando é necessário |
|---|---|---|
| Atualização da aplicação web | A lógica de reprodução e a interface | Correções e melhorias compatíveis com o aplicativo instalado |
| Atualização do aplicativo Android | O aplicativo instalado no equipamento | Mudanças na integração com o sistema e nos recursos do dispositivo |
Essa separação permite atualizar a aplicação web remotamente sem substituir todo o aplicativo Android a cada alteração. Precisamos, porém, preservar a compatibilidade: uma nova versão não pode exigir um recurso que o aplicativo instalado ainda não oferece. Da mesma forma, voltar a uma versão anterior exige considerar as duas partes.
Durante o desenvolvimento das atualizações remotas, encontramos um problema no retorno à versão incluída no aplicativo. O player mantinha uma indicação antiga de atualização mesmo depois de o servidor orientar a reversão.
A origem estava em uma distinção importante: não receber uma nova orientação é diferente de receber uma orientação para voltar à versão original. Ajustamos essa interpretação e a recarga da aplicação, que também podia reutilizar uma cópia antiga da página.
Esse caso reforçou um critério de desenvolvimento: verificar uma atualização inclui testar o caminho de volta e confirmar qual versão o equipamento está executando.
Offline começa antes de a conexão cair
O player só consegue continuar com os recursos que já recebeu. Retomar a reprodução sem rede depende de ter a programação e as mídias necessárias armazenadas no dispositivo.
Armazenamos no dispositivo os dados de registro, a programação e as mídias. Na inicialização, esse estado local permite recuperar o que já estava disponível. Arquivos em cache considerados saudáveis podem ser reaproveitados sem bloquear a abertura com uma consulta de validação para cada mídia. Quando a revalidação falha, o arquivo local pode continuar servindo à reprodução.
A política de limpeza também precisa respeitar a programação: remover uma mídia apenas por sua idade pode apagar um arquivo que a tela ainda precisa exibir. Por isso, as referências da programação atual protegem os arquivos contra essa remoção.
No Android, vídeos compatíveis podem usar diretamente o armazenamento de arquivos do equipamento, conforme os recursos da versão instalada. Se um arquivo deixa de existir, o player precisa reconhecer essa ausência e obtê-lo novamente quando houver conexão.
Limitamos a quantidade de downloads simultâneos e espaçamos as novas tentativas quando há falhas. Isso ajuda a controlar a carga quando vários equipamentos voltam a funcionar ao mesmo tempo, como após uma queda de energia.
O alcance do offline também depende do conteúdo. Vídeos e imagens já armazenados têm condições diferentes de conteúdos que consultam dados externos, transmissões ao vivo e notícias atualizadas pela internet. A programação precisa considerar essas dependências para que o operador saiba o que continuará disponível durante uma interrupção de rede.
Entender a interrupção faz parte da recuperação
Quando uma tela aparece como offline, a causa ainda pode estar em aberto. Rede indisponível, encerramento do aplicativo e perda de energia exigem respostas diferentes da operação.
No navegador, um registro local ajuda a identificar um encerramento inesperado. No Android, a integração com o equipamento acrescenta sinais de inicialização, bateria baixa e desconexão de energia.
Esses dados ajudam a identificar a causa provável da interrupção. Um corte brusco pode impedir o registro do evento, e os sinais disponíveis variam entre equipamentos. Parte da informação só chega quando o player volta a se comunicar. Por isso, o diagnóstico orienta a investigação e ajuda a operação a decidir o próximo passo.
Confiabilidade como critério de desenvolvimento
O núcleo compartilhado permite verificar regras de reprodução no navegador e reaproveitá-las no Android. As integrações nativas, por sua vez, exigem verificações no equipamento: o navegador não reproduz todas as condições de inicialização, armazenamento e vídeo de uma instalação real.
Ao avaliar uma mudança no player, voltamos a perguntas práticas:
- A sequência continua correta durante a troca de conteúdo?
- A programação já armazenada pode ser recuperada após um reinício sem rede?
- A atualização é compatível com o aplicativo instalado e tem um caminho de reversão?
- Os sinais disponíveis ajudam a investigar uma interrupção e deixam claros seus limites?
É assim que traduzimos Telas que nunca param em trabalho de engenharia: preparar a continuidade, reduzir a necessidade de intervenção e tornar as falhas mais compreensíveis quando acontecem.
Para quem opera uma rede de telas, vale começar por um cenário concreto: se a energia cair e o dispositivo reiniciar antes de a internet voltar, o que ele conseguirá exibir — e como você saberá o que aconteceu?
Quem for montar ou avaliar o equipamento pode cruzar esse critério com os requisitos do player e o guia de como colocar a primeira tela no ar.