praegnanz.de büro für intervernetzte medien

Gerrit, 29.11.2011

Zwei Ärgerlichkeiten in iOS-Webapps

Es ist ja wunderbar, dass es unter iOS schon seit Version 1 möglich ist, einfache Websites als Web-Applikation auf dem Homescreen abzulegen. Es handelt sich dabei um mehr als simple Bookmarks, denn beim Klick auf das Icon startet quasi eine dedizierte Browser-Instanz, die wahlweise auch die Adresszeile unterdrückt und somit potenziell wie eine native App wirken kann. Auf den ersten Blick. Frameworks wie Sencha Touch oder jQuery Mobile helfen dem geneigten Webdesigner dabei, amtliche Apps in Windeseile zu entwickeln, die auf Webtechnologien basieren, sich aber an den Paradigmen von nativen mobilen Apps orientieren.

Schön.

Weniger schön sind zwei Details, die ich hiermit anprangere:

1) Umgang mit einfachen Hyperlinks

Apple ist der Meinung, dass eine Web-App eine geschlossene Einheit sein muss, sobald man die Adresszeile über <meta name="apple-mobile-web-app-capable" content="yes" /> ausblendet. Jeglicher normaler Hyperlink ist dann toxisch; Sobald ein User innerhalb der App auf einen Link klickt, bricht die Web-App ab, man gelangt zum normalen MobileSafari-Browser, wo sich dann die gewünschte Website öffnet. Uncool. Der einzige Weg, innerhalb von Webapps zu navigieren, ist also das Nachladen von Daten per Ajax. Normale Seitenwechsel über normale Links brechen das Konzept, was aus meiner Sicht unverständlich ist.

In der von mir gestalteten Kultur-Terminkalender-App sind natürlich Hyperlinks zu den Websites aller Spielstätten enthalten. Aber wehe, man klickt dort tatsächlich drauf! Damit kommen wir zum zweiten Problem:

2) Fehlende Resume-Fähigkeit

Wenn die aktuell laufende Web-App beendet wird, ist sie beendet. Es gibt keinen Freeze-Zustand. Wer die App verlässt, muss sie danach neu starten und manuell zu seiner Unterseite zurückfinden. Extrem ärgerlich für den neugierigen Linkklicker. Er wird bestraft, fliegt aus der App und kommt nicht so leicht wieder zum Ausgangspunkt zurück.

Ich wünsche mir hier Besserung! Warum haben Web-Apps nicht eine eingebaute Webview-Funktion für externe Links, wie sie in fast allen nativen Apps (Twitter-Clients, RSS-Reader usw.) üblich sind? Man begibt sich kurz in das »echte« Web, und kann dann per Back-Button wieder zurück zur Web-App wechseln. Und interne Links sollten einfach per default innerhalb der App verbleiben, damit die Ajax-Laderei nicht mehr verplichtend, sondern nur noch eine Option ist

Und warum kann man nicht zumindest ein paar Megabyte RAM für laufende Web-Apps reservieren, um deren Zustand zu speichern, wenn man sie mal kurz verlassen muss?

Apple, mach mal bitte! Schnell.

13 Kommentare

  1. Zusatzstoff am 29. November 2011 #

    Bezüglich Punkt 1:

    Die beiden genannten Frameworks legen es aber genau darauf an die Daten dynamisch nachzuladen. Nicht umsonst bieten sie umfangreiche und sehr komfortable Data Storage Methoden.
    Mit den externen Links hast du leider recht, das nervt wirklich.

    Bezüglich Punkt 2:

    Auch hier kann man mit den Frameworks den Lokalen Browser Cache nutzen den HTML5 so bietet. Mit entsprechend Aufwand kann man zumindest sehr grob Zustände der Webapp zurückschreiben.

  2. Gerrit am 29. November 2011 #

    @Zusatzstoff: Ja, man kann das sicher nachprogrammieren. Aber man könnte es auch als eine Aufgabe des OS ansehen, Webapps genauso einfrieren zu können wie native Apps!

  3. Markus Schlegel am 29. November 2011 #

    Wenn man es mit dem Resume wirklich ernst meint, muss man das auch bei nativen Apps zusätzlich einbauen. Es kann ja zu jedem Zeitpunkt passieren, dass die Anwendung im Hintergrund geschlossen wird. Mit Cocoa bekommt man das nur besser mit, wenn man in den Hintergrund geschoben wird und wenn man mal besser alles wegspeichern sollte, weil die App bald geschlossen wird. Wenn’s nach mir geht, sollten Webapps einfach auch solche Events bekommen. Vielleicht kann man die Page Visibility API dafür missbrauchen; bin mir aber auf iOS nicht sicher, ob das überhaupt oder schon zuverlässig funktioniert.

  4. HP Scheller am 29. November 2011 #

    Nur aus Interesse: Unter Android 2.2. öffnet sich der normale Browser, die Adressleiste wird nach oben gescrollt. Bei Links zu anderen Websites kann man ganz normal per Backbutton zum letzten Zustand zurückspringen. Ok würde ich sagen.

    Ein Wort zu den Frameworks. jQuery ist super! Aber doch bitte nur auf dem Desktop. Hier wird ein riesiger Overload an Funktionen mitgeschleppt den kein mobiler Browser braucht (IE6 Hacks usw.) Ich setze lieber sowas wie zeptojs.com ein.

  5. Thomas Schroeter am 29. November 2011 #

    Hallo, die von Apple bereitgestellte Funktionalität, einen Link auf den Home Screen abzulegen, ist letztendlich eben nur eine Art Webseiten Aufruf. Es ist also darauf ausgelegt den Inhalt aus dem Internet dynamisch wieder zu laden. Das einzige was Apple in iOS einbinden könnte, wäre die Speicherung der letzten URL die innerhalb der App aufgerufen wurde.

    Wenn Du mit aktuellen Mitteln den Zustand Deiner Web App erhalten möchtest, dann kann so etwas aktuell nur auf der Seite des Servers mit einem Cookie funktionieren.

    Ähnlich wie man bei Google angemeldet bleibt. Es wird ein Cookie beim Benutzer gespeichert. Beim nächsten Aufruf der Webseite über den Link auf dem Home Screen erkennt der Browser das Cookie, schickt es zum Server und der Server schickt einen Redirect auf den letzten Zustand an den Client zurück.

    Man kann das auch komplett auf der Seite des Client mittels Javascript lösen. Bedient sich dann einfach der Storage-Funktionalität von HTML5.

    In jedem Fall ist Programmierarbeit nötig. Funktioniert aber. Vielleicht hilft Dir das …

    viele Grüße,
    Thomas

  6. Thomas Schroeter am 29. November 2011 #

    Bezüglich Punkt 1:

    Schau Dir dies hier an, dass funktioniert auch mit WebKit basiertem Browser da Merkmal von HTML5:

    https://developer.mozilla.org/en/Web-based_protocol_handlers

    Innerhalb Deiner eigenen Domain und somit auch Deiner Web-App kannst Du eigene Protocol-Handler nutzen:

    myapp://function?key=value&key=value

    1. Javascript öffnet das sog. Ajax-Fenster mit integriertem <iframe>

    2. redirect auf eine andere Seite, innerhalb Deiner Domain/App

    Gruß,
    Thomas

  7. Ulf am 29. November 2011 #

    @HP Scheller: Android ist ja auch ein Betriebssystem, das diese Bezeichnung verdient … =8>)

  8. Gerrit am 29. November 2011 #

    @Ulf: Und das Sega Mega-Drive konnte mehr Sprites auf einmal darstellen als das Super Nintendo!

  9. Simon Praetorius am 29. November 2011 #

    @HP Scheller: Das Verhalten mit der URL-Leiste ist meiner Ansicht nach genau das, was man nicht haben will. Eine WebApp soll einer nativen App in Benutzung und Stabilität möglichst nahe kommen, und deshalb soll der Benutzer keine Möglichkeit haben, Befehle auszuführen, die nicht im User Interface vorgesehen sind. Abgesehen davon verwirrt den 0815-User eine Eingabezeile, wenn da nicht gerade www.google.de steht.

    @Thomas Schroeter: Das hört sich interessant an. Es sieht aber zumindest nach einer kurzen Google-Suche so aus, als wäre das weder unter Android noch unter iOS implementiert. Oder liege ich da falsch?

    @Gerrit: Ich finde das Verhalten von Hyperlinks eigentlich das korrekte Verhalten. Die WebApp verhält sich wie eine normale App, die beim Klick auf einem Link die Standardanwendung dafür öffnet. Meines Wissens nach sind die ganzen „extra-WebViews“ Eigenimplementierungen der jeweiligen Apps, also wäre das auch bei einer WebApp die Aufgabe des Entwicklers bzw. des verwendeten Frameworks. Für die Bestandteile der Anwendungen finde ich es das korrekte Vorgehen, alles per AJAX nachzuladen. Meistens macht es hier auch Sinn, eine große HTML-Datei beim ersten Aufruf zu schicken, die alle Views enthält, und später nur noch Daten als JSON nachzuladen. Dadurch wird der Entwickler „gezwungen“, sein Interface möglichst effizient zu generieren, was die Usability erhöht. Und wenn man wirklich mal eine quick’n›dirty WebApp zusammenbastelt, bindet man ein Event an alle a-Tags und biegt die synchronen Requests in asynchrone um. Soo viel Aufwand ist das nicht.

    Bei der Resume-Fähigkeit gebe ich dir allerdings recht. Hier wäre es schön, wenn der Entwickler mehr Unterstützung hätte. Ob das nun ein Event ist, das beim Schließen der App gefeuert wird, oder ob das OS selbst eine Art Snapshot erstellt, beides wäre willkommen. Bei letzterem muss man allerdings bedenken, dass dieser Snapshot vermutlich nicht so langfristig wäre wie die eigene Speicherroutine, da die Local Storage der WebApp nicht einfach so weggeworfen kann.

  10. Thomas Schroeter am 29. November 2011 #

    @Simon Ja, die Funktion scheint tatsächlich noch nicht implementiert zu sein. Dann bleibt an dieser Stelle nur, per Javascript das onclick-Event abzufangen, dass Standardverhalten zu ignorieren und selbst per javascript auf den Link zu reagieren. Man kann sich ja die registerProtocolHandler-Funktion vor erst in Javascript recht einfach selbst implementieren.

  11. Sebastian am 29. November 2011 #

    Wir haben im Unify-Framework genau den Punkt 2 automatisiert (per local storage, geht wunderbar). Wenn Webapps eigene Datenmodell haben und aus diesen und einem Identifier genau den Zustand wieder herstellen können ist das Verhalten von iOS gegeben.
    Aus technischer Sicht garantiert iOS keiner App, dass sie einen Wechsel überlebt, also auch ein Wechseln in den Browser kann eine native App abschießen. Der Trick ist, dass genau der Einstieg in die App wieder den vorigen Zustand hervorbringt.

  12. Marcus Behrens am 24. Dezember 2012 #

    Another little difference: if you use a mailto link in a »home screen web app« and the user presses the link then the web app is closed and ios standard email app is started. In a web app running in safari the new email dialog comes on top of the browser window. Once you have sent the email you are back in the web app. In the case of the home screen web app the user is left in the mail app.

    This and the confusion created by having 2 versions of the app with different local data makes me rather scroll the browser address bar up and stick to running in safari. This way the user can choose to use his bookmarks, add to home screen or simply enter the url to access one and the same web app.

  13. Manuel am 17. März 2014 #

    Auch wenn der Post schon etwas älter ist – das Problem besteht ja noch immer – eine verrückte Idee (hab jetzt nicht in den Kommentaren gelesen ob das schon jemand vorgeschlagen hatte): Theoretisch sollte es ja möglich sein einen In-App/»Webview«-Browser innerhalb einer Homescreen Webapp mittels iframe nachzustellen.

    Man fängt pauschal mal alle Click-Events auf Links ab, schleust die durch ne Funktion in der man auf navigator.standalone testet, sollte das true sein, öffnet man den Link in einem iframe den man in den DOM Tree injected (und bietet optimalerweise, ähnlich wie Facebook, Twitter und Co, die Möglichkeit, die URL doch im Safari zu öffnen).

    Ist nur doof wenn die zu ladende Seite das Einbinden per x-frame-options Header verboten hat. Aber dafür gibt es ja dann den entsprechenden Link zum Öffnen im Safari ;)

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.