CANBoat-Design Teil II – warum eine Website, und warum TCP und JSON

Eine der ersten Fragen, die mir Leute stellen, wenn ich ihnen meine App auf dem iPhone oder iPad zeige, ist, wo sie sie im App Store herunterladen können. Meine Antwort ist einfach: gar nicht. Brauchst du auch nicht. Es wäre sogar schlechtes Design, wenn du das müsstest!

Die Idee ist, dass jedes Gerät an Bord mit einem halbwegs ordentlichen Webbrowser auf die CANBoat-Daten zugreifen kann. Das spart mir Entwicklungsaufwand, denn ich muss keine eigenen Apps für Blackberry, Android, iPhone, Windows Mobile usw. schreiben. Ich muss nur dafür sorgen, dass die Webseite in modernen Browsern ordentlich dargestellt wird. Eine Entscheidung habe ich allerdings getroffen: Auf den Internet Explorer nehme ich keine Rücksicht, es sei denn, es handelt sich um IE 9.

Die Wahl eines Webservers auf einem dauerhaft laufenden kleinen (Linux-)Server, mit Clients, die einfach einen Webbrowser benutzen, hat noch zwei weitere, sehr große Vorteile.

Erstens wird die Client-Hardware zum Verbrauchsartikel, weil man nichts installieren muss. Geht ein Gerät verloren (oder säuft zum Beispiel ab), besorgst du dir einfach ein neues. Für den Einsatz im Cockpit brauchst du zwar trotzdem einen gewissen Schutz, aber das gilt für dein Handy ja sowieso. Der iPod touch vom letzten Jahr, den deine Kinder nicht mehr wollen, weil er zwei Generationen hinterherhinkt, gibt einen hervorragenden Client ab. Und es liefert dir eine Ausrede für einen größeren Bildschirm – sprich ein iPad, für dessen Anschaffung du plötzlich einen „sehr guten Grund“ hast.

Zweitens kannst du den Client ausschalten, so lange du willst, weil der gesamte Zustand auf dem Server liegt. Wenn du ihn wieder einschaltest, wird die Seite aktualisiert oder du startest die „Web-App“ neu, und alle Daten sind wieder da, weil der Server den Systemzustand kennt. Das gesamte Logging usw. erfordert KEINE dauerhaft laufende iPhone-App. Sogar der Ankeralarm (sobald ich irgendwann dazu komme, ihn zu implementieren) wird so funktionieren!

DIE WEBSEITEN

Das Schöne an modernen Browsern ist, dass sie mit ein bisschen Javascript eine Menge erreichen können. Die folgenden Anzeigeinstrumente werden zum Beispiel alle clientseitig mit ein paar hundert Zeilen Javascript-Code gezeichnet:

So wie oben sehen die Instrumente bei Clients aus, die über eine langsame Verbindung angebunden sind. Sind sie per WLAN verbunden, werden die Instrumente mit einem schicken Bild samt Spiegelung dargestellt, was das Ganze optisch deutlich aufwertet.

Außerdem prüft der Server die Fähigkeiten des Browsers, damit die Seite auf das jeweilige Gerät abgestimmt ist. Im Moment mache ich aus der Tab-Leiste eine Dropdown-Liste, wenn ich einen kleinen Bildschirm erkenne. Außerdem werden verschiedene Apple-Webkit-Angaben mitgeschickt, damit die Anwendung auf iOS-Geräten ohne Seitenkopf laufen kann.

AKTUALISIEREN DER ANGEZEIGTEN DATEN

Da Browser (noch) keine UDP-Pakete empfangen können, müssen sie ihre Daten auf anderem Weg bekommen. Das Einzige, was sie können, ist TCP-Verbindungen aufbauen, um ihre Daten zu aktualisieren. Diese Technik heißt AJAX (Asynchronous Javascript and XML), aber statt XML verwende ich das JSON-Format. JSON ist ideal für Javascript, weil es sich ganz einfach in echte Javascript-Objektdaten umwandeln lässt.

Das JSON, das für die drei Instrumente oben verschickt würde, sieht ungefähr so aus:

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

HINWEIS: Dieser Beitrag wurde von meinem alten Blog übernommen, URL http://yachtelectronics.blogspot.nl/2010/09/canboat-design-part-ii-why-website-and.html