Design do CANBoat, parte II - porquê um website, e porquê TCP e JSON

Uma das primeiras coisas que as pessoas me perguntam quando lhes mostro a minha app no iPhone ou no iPad é onde a podem descarregar na App Store. A resposta é simples: não podem. Nem precisam. Seria mau design se precisassem!

A ideia é que todos os dispositivos a bordo com um browser decente consigam aceder aos dados do CANBoat. Assim poupo trabalho de desenvolvimento, porque não tenho de escrever apps à medida para Blackberry, Android, iPhone, Windows Mobile, etc. Só tenho de garantir que a página web aparece bem nos browsers modernos. Decidi, isso sim, que não vou fazer concessões ao Internet Explorer, a não ser que seja o IE 9.

A opção por um servidor web alojado num pequeno servidor (Linux) sempre ligado, com clientes a correr um browser, tem mais duas grandes vantagens.

Em primeiro lugar, como não é preciso instalar nada, o hardware do cliente passa a ser descartável. Se perder um (por exemplo, porque apanhou uma molha), arranja-se outro. Para usar no cockpit vai continuar a precisar de alguma proteção, mas isso já é verdade para o próprio telemóvel. O iPod touch de há uns anos, que os miúdos já não querem porque está duas gerações atrasado, serve na perfeição como cliente. E ainda dá uma desculpa para arranjar um ecrã maior – leia-se um iPad, que de repente passa a ter “uma excelente razão para ser comprado”.

Em segundo lugar, como todo o estado fica guardado no servidor, pode desligar o cliente durante o tempo que quiser. Quando o voltar a ligar, a página atualiza-se ou reinicia a ‘web app’, e os dados estão todos lá, porque o servidor sabe qual é o estado do sistema. Os registos e afins NÃO precisam de uma app de iPhone sempre a correr. Até o alarme de fundeio (quando finalmente o implementar) vai funcionar assim!

AS PÁGINAS WEB

O bonito dos browsers modernos é que conseguem fazer muita coisa com apenas um bocadinho de Javascript. Por exemplo, os mostradores seguintes são todos desenhados do lado do cliente, em umas poucas centenas de linhas de código Javascript:

Os mostradores acima são o que veem os clientes ligados através de uma ligação lenta. Se estiverem ligados por Wifi, os mostradores aparecem com uma imagem bonita, com reflexo, o que melhora bastante a experiência.

Além disso, o servidor analisa as capacidades do browser, para que a página se ajuste ao que o dispositivo consegue fazer. Neste momento, troco a barra de separadores por uma lista pendente se detetar um ecrã pequeno. São também enviados vários elementos Apple Webkit para permitir correr a aplicação sem cabeçalho de página nos dispositivos iOS.

ATUALIZAR OS DADOS NO ECRÃ

Como os browsers ainda não conseguem receber pacotes UDP, têm de obter os dados de outra forma. A única coisa que conseguem fazer é abrir ligações TCP para atualizar os dados. Essa técnica chama-se AJAX (Asynchronous Javascript and XML), mas em vez de XML uso o formato JSON. O JSON é ideal para Javascript, porque se converte facilmente em objetos Javascript a sério.

O JSON enviado para os três mostradores acima é mais ou menos isto:

[
  {"name":"Heading","units":"°","value":357.7},
  {"name":"Batt Voltage","units":"V","value":"27.06"},
  {"name":"NMEA Voltage","units":"V","value":"12.65"}
]

NOTA: Esta página foi republicada a partir do meu antigo blogue, no URL http://yachtelectronics.blogspot.nl/2010/09/canboat-design-part-ii-why-website-and.html