Ich habe den gestrigen Tag damit verbracht, mir noch einmal ausführlich anzusehen, was für Frameworks es gibt, die das iPad als Plattform bedienen wollen, um darauf eine Magazin-ähnliche Darstellung von Inhalten zu realisieren. Dabei habe ich ausdrücklich nach Lösungen gesucht, die sich der Techniken HTML5 und CSS3 bedienen und nicht nach solchen, die ausschließlich als Javascript-Framework daher kommen, um iOS-Bedienkonzepte nachzubilden, wie beispielsweise Sproutcore und ähnliche.
Gewünscht war allerdings natürlich eine Unterstützung der iPad-Touch-Steuerung, im einfachsten Fall sollte man im Artikel nach unten und oben durch den Inhalt scrollen und mittels einer horizontalen Wischbewegung den Artikel nach vorn oder zurück wechseln können. Wenn’s geht auch gern mit zusätzlichen Gimmicks.
Das Ergebnis der Recherche samt Tests war sehr ernüchternd.
Die Anzahl der Frameworks, die solche Bedingungen bieten sind höchst überschaubar, tatsächlich sind mir trotz langer Google-Sessions nur folgende Vertreter unter gekommen: Aside, Baker, das davon abgeleitete Laker und Magaka. Leider erscheint mir keins davon wirklich geeignet – insbesondere deswegen weil ich unter Windows entwickle und definitiv nicht vor habe, mir ein überteuertes Macbook oder sonst einen Apfelrechner zu kaufen, nur damit ich Apps kompilieren kann.
Aside kickt sich sofort selbst ins Aus, weil die Performance der Demo so hundsmiserabel ist, dass man das ernsthaft keinem Leser antun kann. Mir ist völlig schleierhaft, wie man so etwas als Techdemo vorstellt und glaubt, dass die Demo ernsthaft jemanden dazu bringen könnte, das Framework zu nutzen. Das ruckelt und ruckt an allen Ecken und Enden und macht in der Benutzung deswegen überhaupt keinen Spaß. Unbrauchbar – zumindest im derzeitigen Zustand. Warten wir ab, was iOS5 bringt, das soll ja beispielsweise für eine deutliche Verbesserung der Javascript-Performance sorgen.
Auch das Baker eBook Framework 2.0 hat dieses Problem. Es ist nicht hinnehmbar, dass ein Wisch, der das nächste Kapitel auf den Bildschirm der Apfel-Flunder bringen soll, erstmal dafür sorgt, dass man zwei und mehr Sekunden auf einen drehenden Ladeindikator blicken muss.
Auch hier überzeugt die Demo-App in keinster Weise, man fragt sich, ob bei Baker noch nie jemand was von Pre-Caching gehört hat? Somit scheidet auch dieses Framework aufgrund von deutlichen Performance-Problemen aus.
Zudem muss man zwingend einen Mac besitzen, um das fertige Projekt zu einer App zu komplilieren, siehe dazu im nächsten Abschnitt über Laker mehr.
E
twas vielversprechender sieht das von Baker abgeleitete Framework Laker aus. Dieses widerum katapultiert sich aus der Liste, weil man erstellten HTML5-Content offenbar zwingend auf einem Mac kompilieren muss, um eine App daraus zu machen, die man dann über den bewachten App-Store aufs Device bekommen kann. Erstens möchte ich den App Store durch die Nutzung von HTML gerade umgehen (mir schreibt Apple nicht vor, was ich veröffentliche) und zum zweiten kaufe ich mir (wie oben bereits angemerkt) garantiert keinen Mac zum Kompilieren von HTML5… Erschwerend kommt hinzu, dass man sich die Laker-Demo-App immer noch nicht ansehen kann, da sie von Apple nicht freigegeben wird.
Letzter im Bunde war Magaka, das Gerd Schröder auf seinem Blog Padlive bereits vor einiger Zeit vorgestellt hatte und das auf den ersten und zweiten Blick (durch Demo) sehr vielversprechend aussieht. Allerdings hat Magaka zwei ganz grundlegende Nachteile. Der erste: keinerlei Dokumentation, noch nicht einmal rudimentärste! Der Autor entgegnete auf Anfrage, man solle sich einfach die Demo ansehen, man könne im Quelltext einfach alles erkennen… Ah… ja…
Nur fehlt mir leider die Zeit, durch langes Quelltextwühlen selbst herauszufinden, wie das Ding im Einzelnen funktioniert, insbesondere angesichts des angeblichen Funktionsumfangs kein guter Plan. Zweitens scheint es schon recht lange kein Update mehr für Magaka gegeben zu haben. Da das Framework weitestgehend unbekannt ist, hat sich auch kein Dritter dessen erbarmt und mal ein Tutorial verfasst.
Quintessenz: derzeit nichts wirklich Brauchbares in Sicht – und das obwohl es das iPad nicht erst seit gestern gibt. Man verstehe mich nicht falsch: ich bin sehr dankbar, dass es Personen gibt, die sich um solche Projekte bemühen und sie als Open Source freigeben – nur würde ich mir zum einen wünschen, dass man in seinen Lobeshymnen des eigenen Projekts etwas vorsichtiger wäre, solange es noch offensichtliche Probleme gibt, zum anderen sollte man zumindest für eine ganz grundlegende Doku sorgen.
Ich werde jetzt nochmal ein wenig mit treesaver.js experimentieren (obwohl auch dort die Doku gruselig ist) und versuchen herauszufinden, warum dabei kein Zoom möglich ist…
Danke für die Erwähnung. Ich habe da noch eine Lösung, über die ich die Tage bloggen werde.
vg Gerd
Das war auch mein Ergebnis, das ich bei der Suche nach möglichen Lösungsansätzen im Internet gefunden habe. Wobei eine Web-App in HTML5 für mich noch der vielversprechendste Weg ist. Eigenständige Apps kann man wohl nur erstellen, wenn man einen Mac hat. Kann ich zwar nicht verstehen, aber so sei es nun einmal. Ich werde weiter suchen und falls ich was finde…werde ich es hier posten.
Mittlerweile ist das Baker Framework in Version 3.1 erschienen. Diese bringt nicht nur die Unterstützung für mehrere iOS5 Funktionen wie den Newsstand mit, sondern hat sich in meinen Augen auch was die Performance angeht verbessert.
Wenn du Pre-Caching nutzen möchtest sollte es kein großer Aufwand sein, das ganze Einzubauen. Außerdem gestatten sowohl das Laker Kompendium, als auch Baker ab Version 3.0 das Erstellen von WebApps.
Für den Weg in den Appstore kommst du um einen Mac nicht herum. Das liegt vor allem daran, dass Apple sein Developer Kit mit xCode und allen anderen Tools nur für seine eigene Plattform entwickelt.
Da ich im Prinzip nach einer Open Source-Lösung suche, und mir garantiert für die Entwicklung keinen völlig überteuerten Mac kaufe, kommen Baker & Co- ohnehin nicht in Frage. :o)