Artikelformat

JavaScript-Inkompatibilitäten in mobilen WebApps

Nachfolgend stelle ich Stolpersteine vor, die mir bei der Entwicklung einer mobilen, JavaScript-basierten WebApp begegnet sind. Zielplattformen waren iOS, Android und Windows Mobile.

Datum speichern und laden

Praktisch alle modernen Browser bieten mit localStorage die Möglichkeit an, Daten lokal auf dem Gerät zu speichern. Das localStorage-Objekt realisiert einen sogenannten Key-Value-Store. Man kann zu einen Schlüsselbegriff jeweils einen String speichern und wieder laden. Das funktioniert auch plattformübergreifend erstaunlich gut.

Wollen wir jetzt ein Datum abspeichern, so müssen wir das Datum zum speichern zunächst in einen String umwandeln und zum einlesen wieder zurück konvertieren. Da JavaScript schon seit dem letztem Jahrhundert ein Date-Objekt besitzt, erwartet man dass dieses Objekt die passenden Funktionen bietet.

Erstaunlicherweise sind die Standard-Methoden wie Date.parse() nur wenig hilfreich. Als Format ist nur das Datumsformat nach RFC 2822 festgelegt, das nur für englischsprachige Menschen optimiert ist. Ein Datum sieht in diesem Format etwa so aus:

“Mon, 31 Dec 1995 12:30:00 ”

Erst seit JavaScript 1.8.5 bzw. ECMAScript Version 5 wird das Datumsformat nach ISO 8601 unterstützt, bei dem das Datum die Form “YYYY-MM-DDThh:mmTZD” hat. Die Komplexität dieses Formats ist eigentlich deutlich geringer. So müssen keine Monatsnamen oder gar Wochentage erkannt werden, und die Felder sind an fest definierten Positionen. Trotzdem klappt ein Date.parse() mit einem ISO-Datum in vielen Geräten nicht: Bei meinen Tests erhielt ich Fehler auf Geräten mit Android 2.1 und 2.3 sowie auch bei einem BlackBerry-OS6-Gerät. Auch die umgekehrte Methode Date.toISOString() fehlt.

Dialoge und die prompt-Methode

Für einfache Dialoge bieten sich die in JavaScript eingebauten Funktionen an:

  • alert()
  • confirm()
  • prompt()

Die Dialoge dieser Funktionen sind automatisch im auf der Plattform passenden Design. Da es modale Dialoge sind, bleibt die Anwendungslogik schön übersichtlich. Wollen wir den Nutzer nach einen String fragen, reicht diese einfache Programmzeile:

username = prompt('Ihr Nutzername:');

Bei Texteingaben auf dem Handy gibt es oft ein Usabilityproblem: Oft muss man das Eingabefeld erst ein zweites Mal aktivieren, bevor die Bildschirmtastatur erscheint. Nach der Eingabe muss man dann erst die Bildschirmtastatur zum verschwinden bringen, um dann noch einmal einen OK-Button zum Speichen zu drücken.

All das wird unter z.B. unter Apple-iPhone nicht nötig, die JavaScript-prompt() Methode liefert direkt einen benutzerfreundlichen Dialog mit aktivierter Bildschirmtastatur. Insgesamt also gerade auf mobilen Geräten eine sehr praktische Funktion.

Dialog in iOs und Alternative mit Textfeld in Windows Mobile

Jedoch hat ein anderen Hersteller, Microsoft, entschieden, dass die prompt-Methode ein Sicherheitsproblem darstellt. Dementsprechend wird prompt() unter Internet Explorer ab Version 7 (in der Standardeinstellung) und auch in Windows Mobile nicht mehr unterstützt.

Ärgerlich dabei ist, das der Windows-Mobile Browser den Dialog “heimlich” unterdrückt. Das Ergebnis kann man nicht von einer leeren Nutzereingabe unterscheiden, und so können wir im JavaScript-Code nicht reagieren und Alternativen für die Texteingabe anbieten. Also muss man wieder zum ungeliebten “Browser-Sniffing” greifen.

Autor: Karsten Meier

Weil ich gerne Probleme löse bin ich Informatiker geworden. Ich berate und Konzeptionieren und entwickle mit fast allem, was einen Prozessor hat.

Hinterlassen Sie eine Antwort