iPhone Web App Game – Lessons Learned
Im letzten Monat hatte ich das Vergnügen ein Glücksspiel zu implementieren.
Um genau zu sein handelt sich um eine sog. 5 Reel Slot Machine, bzw. eigentlich um eine Simulation derselben. Sie trägt den Namen „Gold of Yucatan„, denn das ist das Thema: Das Gold von Yucatan zu finden… Ja, na, eh.
Das Ergebnis meiner Bemühungen ist auf den hier zu bewundern. Leider braucht man auch für ein Probespiel mit rein virtuellem Einsatz einen Account. Das iPhone Spiel kriegt man nur angeboten, wenn man mit einem iPhone oder iPod Touch User Agent daher kommt. Es empfiehlt sich Safari 4, wenn man kein iPhone zur Hand hat, denn der hat die entsprechenden UA Strings schon eingebaut und rendert auch die CSS3 Transitions korrekt.
Ich habe ein paar Photos gemacht:
Was ist nun das besondere an iPhone Web Apps?
Wenn man alles richtig macht, hat man am Ende eine Applikation, die sich fast genauso verhält, wie eine native iPhone Applikation. Einziger klarer Unterschied: Ohne Datenverbindung geht nix, denn die Web App wird immer vom Server geladen. Andererseits spart man sich dafür auch die Apple Zensur: Man muß nicht erst durch den iTunes Store, sondern kann das ganze einfach auf eigene Faust machen.
Wenn man will, kann man aber trotzdem von Apple beworben werden. Sie bieten einen eigenen Web App Katalog an. Zugegeben, der ist im Vergleich zum App Store äußerst unbekannt, der Werbeerfolg wird sich also in Grenzen halten. Bei der riesigen Menge an nativen Apps im App Store hilft die reine Präsenz in selbigen allerdings auch kaum mehr.
Architektur
Eine iPhone Web App befindet sich unter genau einer Resource, also einer einzigen HTML Seite. Alles was man anzeigen will, muß sich darin befinden.
Man kann natürlich dennoch mehrere „Seiten“ haben, der Inhalt muß sich aber eben innerhalb einer einzigen HTML Datei befinden. Dieser kann mit JavaScript auch dynamisch generiert bzw. nachgeladen und hin- und hergewechselt werden.
Die alte WML Metapher des „Decks“ und der „Cards“ drängt sich auf.
Da ich jQuery Fan bin (meine Plugins dafür sollten das wohl hinreichend beweisen…), drängt sich mir die Verwendung desselben natürlich auf. Zum Glück war David Kaneda so freundlich und hat bereits jQTouch entwickelt. (Projektseite bei Google Code)
Das kapselt alles nötige Know-How in einer JavaScript und einer CSS Datei.
jQTouch Features
- Automatisches setzen der benötigten spezifischen Web App
<head>Tags - Vorgefertigte Card Überblendungen mit CSS 3 Transitions und Animations
- Unterstützung des Designs durch setzen entsprechender Klassen bei Orientierungsänderung
- Eigene Tap Erkennung und Event Handling des Taps; Dies umgeht die Auslöseverzögerung bei einem Standard
onclickEvent.
Ich empfehle den Einsatz der letzten Revision im Trunk (aktuell 133) des Subversion Repositiories.
Es gibt dort leider ein paar kleine Probleme, die aber schnell abgestellt sind: Die min-height’s für die verschiedenen Größen und Orientierungen sind nicht korrekt und vollständig.
Was ist beim Design zu beachten?
In erster Linie ist es wichtig, die unterschiedlichen Viewportdimensionen, die es zu unterstützen gilt, zu beachten.
Einerseits wird die App zuerst einmal im Safari aufgerufen. Dort haben wir 320 x 416 Pixel im Portrait- und 480 x 268 Pixel im Landscape-Modus zur Verfügung. (Die Adresszeile wird bei einer Web App automatisch ausgeblendet, man kann die 60 Pixel, die diese verbraucht also mitrechnen.)
Andererseits haben wir die Situation, bei der die App vom Home Screen gestartet wird. Hier gibt es kein „Browser Chrome“, also keine Bedienelemente mehr. Dadurch stehen 320 x 460 bzw. 480 x 300 Pixel zur Verfügung. Wenn man die Statusleiste auf black-translucent setzt, sogar nochmal 20 Pixel mehr – der Nutzen davon ist allerdings sehr begrenzt, die Statusleiste bleibt ja trotzdem da und hindert den Nutzer an der Bedienung darunterliegender Elemente.
Die App muß also dementsprechend gestaltet sein, so daß sie mit unterschiedlichen Größen zurechtkommt. Vor allem Hintergrundgrafiken sollten entsprechend angepasst werden. Optimal ist es, den zusätzlichen Platz nicht ungenutzt zu lassen, was natürlich nur in bestimmten Kontexten funktioniert.
Zu beachten ist auch, daß die Navigation vollständig mit eigenen Bedienelementen möglich ist – insbesondere der „Zurück“-Button des Browsers fehlt ja!
Das position: fixed Problem
Es liegt nicht weit entfernt, bei einer Web App fixierte Status- oder Toolbars einzubauen.
Da das iPhone die CSS Eigenschaft position: fixed nicht unterstützt, sondern dieses wie position: absolute behandelt und man andererseits <div>s die mit overflow: scroll scrollbar gemacht werden nur sehr benutzerunfreundlich mit zwei Fingern scrollen kann (und das auch längst nicht mit so geschmeidigem „natürlichem“ Feedback), braucht man einen Workaround.
Matteo Spinelli von cubiq.org hat meines Wissens hier die am einfachsten zu verwendende Arbeit abgeliefert: iScroll
Ein JavaScript Objekt, daß mit einem Einzeiler beliebige Elemente mit einem Finger scrollbar macht, und dabei die gleiche Natürlichkeit im Scrollverhalten an den Tag legt, wie sonst überall am iPhone gewohnt.
Damit sind fixierte Toolbars kein Problem mehr!
Und auf anderen Geräten?
Palm Pre
Auf dem Palm Pre funktionieren Touch Web Apps ähnlich gut, leider kann man dort die App nicht ins Menü bringen und der Splash Screen wird nicht angezeigt.
Der zur Verfügung stehende Platz ist auch etwas anders: Der Viewport ist 320 x 460 Pixel (480 – 20 Pixel für die Statusleiste), allerdings befinden sich unten links und rechts zwei bis drei ca. 50 Pixel große runde Browser Bedienelemente, die den Inhalt überlagern: „Zurück“ und u.U. „Vor“ links, „Neu laden“ bzw. „Stopp“ (je nach Ladezustand) rechts.
Die Orientierungserkennung ist leider auch nicht verfügbar. Das ist besonders ärgerlich, wenn man weiß, das es sie in nativen Applikationen (die ja in JavaScript geschrieben sind) eben doch gibt!
Wenn man auf explizite horizontale Unterstützung verzichten kann, und am unteren Ende ein bißchen aufpasst, kann man also ohne Probleme auch für Pre anbieten.
Das Palm Pixi ist allerdings ziemlich lästig, weil das einen um 80 Pixel kürzeren Bildschirm hat – auf die möchte man eher nicht mehr verzichten.
Kleines Bonbon: Da Palm webOS Apps ja sowieso in HTML/CSS/JS geschrieben sind, fällt eine Portierung von einer Web App hin zu einer installierbaren webOS App äußerst leicht. Die aktuelle Marktdurchdringung lässt das momentan natürlich nicht besonders interessant erscheinen. Das könnte sich allerdings jederzeit ändern.
Android
Von den Android Geräten, die ich bis jetzt in den Fingern hatte oder mir zugetragen wurden (v.a. HTC Magic und Hero) bin ich schwer enttäuscht worden: Die Geschwindigkeit ist unterirdisch, Transitions werden offenbar nicht durch Hardware beschleunigt, Bewegung in animated GIFs ist faktisch nicht zu erkennen.
Das alles wäre noch zu ertragen und mit Abstrichen drumherum zu arbeiten. Allerdings kommts noch schlimmer: Hintergrundbilder von sich überlagernden <div>s werden teilweise einfach gar nicht angezeigt.
Obwohl da eigentlich ein WebKit wie bei den anderen Geräten am Werk sein sollte, gibts massive Renderfehler. Sehr arm.
Wichtige Links
Nochmal schnell zusammengefasst die wichtigen Links aus dem Text:
Apple: Was sind Webapps?
Safari Dev Center: Human Interface Guidelines for Webapps
jQTouch
jQTouch bei Google Code
iScroll
Categories: Technik | 
Tags: Android, howto, iPhone, iPhone Web App, Palm Pre, Pre, Web App, Web Game, Webapp | 
4 Comments »
