Archiv der Kategorie: iPad

Plattformunabhängige Entwicklung von Mobile Learning Applikationen für iPhone und Android Smatphones

Die beiden Platzhirsche bei den Betriebssystemen für Touchscreen Smartphones sind derzeit unbestritten Googles Android auf Telefonen diverser Hersteller und Apples iOS auf dem iPhone. Um Applikationen für das iPhone zu entwickeln ist Apple MAC-Hardware zwingend erforderlich, auf anderen Betriebssystemen darf nicht entwickelt werden. Programmiert wird ausschließlich in Objective-C einer objektorientierten Variante C-Variante und nicht etwa im weiter verbreitertem C++. Die erstellten Applikationen (Apps) dürfen nur über den Apple Appstore vertrieben werden. Wesentlich offener gibt sich da Googles Android und setzt ganz auf die weit verbreitete Programmiersprache Java, in der bis auf wenige Ausnahmen die Apps erstellt werden. Zeitkritische Anwendungen können mit den Native Development Tools auch in C geschrieben werden. Es kann wahlweise unter Windows, Linux und MacOS für Android entwickelt werden.

Wahlverwandtschaften

Trotz dieser Unterschiede sind sich diese Plattformen in vielerlei Hinsicht doch sehr viel ähnlicher als man auf den ersten Blick vermuten würde. Der Android-Webbrowser basiert ebenso wie der Safari-Browser auf dem iPhone auf der freien Webkit Rendering Engine. Auch ein Großteil der Webbrowser weiterer mobiler Plattformen wie z.B. Nokia S60, Palm Pre, Openmoko und in Zukunft wohl auch Blackberry verwenden unter der Haube die schlanke Open Source Webkit Engine, die für die eigentliche Darstellung (das Rendering) der Webseiten sorgt. Die Benutzeroberfläche der Browser kann also durchaus verschieden sein, die einheitliche Rendering Engine sorgt dafür das Webseiten auf allen diesen Geräte gleich dargestellt werden bzw. die Unterstützung neuer Webstandards wie HTML5 ähnlich weit fortgeschritten ist.

Das ist übrigens nicht die einzige Gemeinsamkeit der beiden Welten. Die Apple iPhones arbeiten ebenso wie die Android Smartphones mit einer CPU die auf der ARM-Architektur beruht (Android kann sogar auf einem iPhone installiert werden;-)). Sowohl bei iOS als auch bei Android handelt es sich um UNIX-ähnliche Betriebsysteme. Android verwendet einen Linux-Kernel, iOS lässt sich geschichtlich über Mac OS X und Nextstep auf BSD-UNIX zurückführen.

Webkit

Ursprünglich als Rendring Engine für den Linux KDE-KHTML-Browser entworfen, dann von Apple unter dem Namen Webkit als Rendering Engine für Safari weiterentwickelt, arbeitet nun auch ein Google Team an Webkit für Google Chrome und dem mitgelieferten Browser im Android-Betriebssystem. Wenn Sie dieses Blog auf einem Mac, einem iPhone, einem iPad (Safari-Browser) oder auf einem Android-Smartphone lesen, wird die Darstellung der Seite durch Webkit erledigt. Ein sehr schlanker und empfehlenswerter Webkit-basierter Browser für Linux und Windows ist übrigens Midori.

Plattformunabhängigkeit

Die Entwicklung von plattformübergreifenden HTML-basieren Anwendungen ist meiner Ansicht nach immer gegenüber nativen APPs zu favorisieren. Besonders für E- und M-Learning Anwendungen ist eine Standardisierung nützlich um zu verhindern, dass die im Hochschulbereich knappen Entwicklungskapazitäten an einzelne Endgeräte verschwendet werden. Wiederverwendbarkeit und langer Lebenszyklus sind bei webbasierten Anwendungen eher sicherzustellen als bei nativen Apps. Eine Ausnahme ist die Erstellung von Content für bestehende Apps, die auf mehreren Plattformen verfügbar sind (siehe z.B. hier).

Der Erfolg des iPhones hat mehrere Entwickler dazu inspiriert die Benutzeroberfläche des iPhones webbasiert nachzubauen oder eigene Touchscreen-Interfaces für Webseiten zu entwickeln. Ursprünglich erschien mir Sencha Touch, ein plattformübergreifendes Touch-API für mobile Browser, sehr geeignet eine Touch-Oberfläche zu entwickeln, dann bin ich aber durch meinen Kollegen Dr. Daniel Biella auf iWebkit aufmerksam geworden. iWebkit besticht durch seine Einfachheit in der Anwendung, schon rudimentäre HTML-Kenntnisse reichen aus um eine iWebkit-Seite zu erstellen. Auf dem iPhone und iPad sehen iWebkit-Seiten aus wie eine native App und sie laufen auch ganz fabelhaft auf Android- Nokia S60- Palm Pre- und Openmoko-basierten Geräten.

Ein Beispiel

Ob sich die gemeinsame Basis der beiden Smartphone Welten Android und iPhone für eine HTML-basierte, an die Touch-Bedienung angepasste, eigene Oberfläche eignet habe ich anhand eines alten Projektes aus meiner Zeit an der FernUniversität in Hagen, dem Pediaphon, einer Sprachausgabe für die Wikipedia, ausprobiert. Als beispielhafte iWebkit-Anwendung wird hier ein eigenes Pediaphon-User-Interface für Webkit-basierte Mobilbrowser vorgestellt. Die Audioausgabe wird hier mit HTML5 realisiert (deshalb läuft es erst ab Android 2.3 Gingerbread), für Android 2.2 Froyo basierte Telefone gibt es auch eine Flash Alternative. Diese Einschränkung bezieht sich auf die HTML5-Audiounterstützung, nicht auf iWebkit selbst. Apple unterstützt HTML5-Audio schon seit iOS Version 4.

Hier einige Screenshots vom GUI (Auf einem Android 2.3 Gingerbread Emulator, aber auch schon live mit einem Orange San Francisco getestet):

IWebkit Pediaphon Touch-Interface
IWebkit Pediaphon Touch-Interface

Ausprobiert werden kann das Pediaphon iWebkit-Interface hier in Deutsch und in Englisch, Spanisch, Französisch und Italienisch.

 

WLAN-Lokalisation a la Apple, die neuen Datenschutzrichtlinien – noch ein Datenkrake

Eine Antwort

Hier der zweite Teil des Hands-On, sollte eigentlich nur zum Geolocation API sein, aber aus aktuellem Anlass auch zu Location based Services und Privatsphäre.
Das HTML5 Geolocation API funktioniert im Safari auf dem iPad ganz ausgezeichnet.
Artig fragt hier der Safari um Erlaubnis, gibt aber wohl (wie auch Google-Maps mobile, hatte ich schon im März 2009 vermutet, ganz unten im Artikel) die SSID aller WLANs in der Umgebung an Apple weiter.

Leider gibt es das iPad nur mit verspiegeltem Display, also zum arbeiten nicht zu gebrauchen, schade.

Die Aufregung in der Fachwelt verwundert mich ein wenig. Die Anbieter solcher Location based Services wären doch ohne solche Informationen von den mobilen Clients gar nicht in der Lage ihre Datenbanken aufzufüllen. Den betroffenen Nutzern sollte aber klar sein, dass solche Dinge immer Auswirkungen auf die Privatsphäre haben. Außerdem sind ja nun anscheinend die iPhone- und iPod-Nutzer als Wardriver unterwegs, spüren WLAN-Netze auf und geben diese Informationen an Server in den USA weiter. Mit deutschen Datenschutzgesetzen ist das mit Sicherheit nicht vereinbar. Aber ohne SSID-Datenbanken keine Funktionalität, so einfach ist das. Wer aber nicht möchte das Informationen über seinen Aufenthalt publik werden könnten, darf diese Daten nicht an Google oder Apple weitergeben. Was einfach fehlt ist, wie auch bei sozialen Netzwerken, Sachverstand und ein verantwortungsvoller Umgang mit diesen Techniken.

HTML-Geolocation kann hier (auch einmal ohne Google Maps 😉 ) ausprobiert werden: Openstreetmap HTML5 Geolocation, optimiert für kleine Displays, Android Froyo, iPhone, iPad, iPod touch.

Hands-On Apple IPhone 4 und iPad – HTML5 Audio

Eine Antwort

Am 8.7.2010 war die Firma Apple für ein Hands-On Kolloquium im ZIM zu Gast. Neben der Vorstellung der iPDU (iPhone Development at University) war auch Zeit für umfangreiche Tests mit den Geräten. Die Apple-Vertreter bewarben iTunes U (iTunes für Universitäten) als Plattform für eLearning Aktivitäten. Meiner Ansicht nach ist es aber Unsinn eLearning Content speziell für Apple-Endgeräte zu entwickeln, und damit andere Plattformen auszuschließen. Auch wegen Apples Preis- bzw. Providerpolitik wird man nicht davon ausgehen können, dass zukünftig alle Studierenden nur mit iPhones lernen, auch wenn viele Entscheider (die ihre Telefone üblicherweise nicht selber bezahlen) nun das mobile Internet über UMTS nutzen können (auch ohne zu wissen was ein APN ist).
Dennoch verfügen die Geräte mit Safari über einen sehr brauchbaren Browser der für webbasiertes mobiles eLearning (mLearning) gut geeignet ist. Der rein politische Boykott von Flash auf diesen Geräten treibt glücklicherweise die Unterstützung von HTML5 voran. Auch der Android-Browser verfügt über eine Webkit-Engine und kann ab Android 2.1 (Eclair) HTML5 interpretieren. Der Audio-Tag soll aber erst ab Gingerbread voll unterstützt werden, das aktuelle Froyo (frozen yogurt) 😉 spielt immer noch kein HTML5-Audio ab. Der eigentliche Tag wird unterstützt nur die Codecs fehlen noch im Browser (getestet mit http://html5test.com/). Also ist auch für Android HTML5-Audiounterstützung nur eine Frage der Zeit.

Leider konnte das mitgebrachte iPhone nicht wirklich ins Netz und hat nur Seiten der Uni angezeigt. Das Display des iPhone 4 ist wirklich erstklassig. Das Gehäuse sieht auch sehr viel besser aus als die alten iPhones, nur die Antennen hat Apple wohl vermurkst. Wer trotzdem schnell und problemlos (dauert nur zwei Wochen, ein Freund hat es ausprobiert) ein iPhone 4 ohne Simlock kaufen möchte kann dies recht komfortabel und sicher per Kreditkarte mit Rechnungsadresse in Deutschland (Steuer) im Apple-Shop-UK tun. (Mit Borderlinx von DHL, siehe auch bei teletarif.de)

Das Hands-On am ZIM (mit einem Koffer voller iPads) war eine gute Gelegenheit für mich in Ruhe mit dem HTML5 Audio-Feature auf dem iPad zu beschäftigen. Ich hatte vorher schon einmal bei einem Elektronik-Discounter das iPad kurz getestet nun konnte ich ohne Zeitdruck sorgfältig testen. Da Apple mit iOS4 nun nach dem mobilen Internet auch das Multitasking erfunden hat 😉 , kann auf dem iPAD die Audiowiedergabe in Safari starten ohne das der Browser wie beim iPhone < 4 und dem iPod touch zugunsten von Quicktime angehalten wird. Leider startet die Wiedergabe trotz korrekter HTML5 Auszeichnung nicht automatisch, auch das hat wohl politische Gründe um die Nutzer von Volumentarifen zu schützen. Leider benötigte ich immer mehrere Versuche um die Wiedergabe auf dem iPad zu starten, wenn es dann einmal lief klappte es danach immer sofort.

Mit Javascript kann man Autoplay aber auch auf dem iPad erzwingen.

Der Teufel steckt leider auch bei HTML5 Audio/Video im Detail, nämlich in der Unterstützung der Codecs. Während wie erwartet die ‚guten‘ Mozilla Firefox, Opera und Google Chrome den open source OGG-Container für Audio unterstützen, setzen die ‚bösen‘ (Apple Safari [OSX und auch iOS] und Microsoft IE9 😉 auf MP3. Schade eigentlich, entweder also wieder hässliche Browserweichen in Javascript oder der Nutzer muss per Formular entscheiden wie jetzt beim neuen iPad-konformen Pediaphon.

Wer seinen (möglicherweise mobilen) Browser auf HTML5-Konformität testen möchte kann das bei http://html5test.com/ recht komfortabel tun.