HTML5 und das Framework jQuery Mobile

Transcription

HTML5 und das Framework
jQuery Mobile
Seminararbeit im Wintersemester 2011/12
Fachhochschule Aachen
Standort Jülich
Fachbereich Medizintechnik und Technomathematik
Studiengang Scientic Programming
Naeema Anees
Matrikelnr. 836393
1. Betreuer: Prof. Ulrich Stegelmann
2. Betreuer: Dipl.-Inform. Axel Blum
Aachen, den 15.12.2011
,
Vorwort
Diese Seminararbeit beschäftigt sich mit HTML5 und dem Framework jQuery
Mobile. Kapitel 1 gibt eine kurze Einführung in das Thema und erörtert auch
die Relevanz. Die Grundlagen des Webs und der Webprogrammierung werden
in Kapitel 2 vermittelt. Kapitel 3 erläutert Aspekte der Softwareentwicklung
für mobile Endgeräte. In Kapitel 4 werden HTML5, CSS3 und JavaScript-APIs
vorgestellt. Darauf aufbauend wird in Kapitel 5 auf die Entwicklung von Apps
für das Betriebssystem iOS eingegangen. In Kapitel 6 wird ein Fazit gezogen.
Abschlieÿend gibt Kapitel 7 einen kurzen Ausblick.
Alle verwendeten Codebeispiele sind in HTML5 und JavaScript geschrieben
und - wenn nicht anders gekennzeichnet - eigenhändig verfasst. Alle Abbildungen
sind - sofern nicht anders gekennzeichnet - entweder Screenshots oder wurden
mit Microsoft Visio Premium 2010 erstellt.
Inhaltsverzeichnis
Eidesstattliche Erklärung
2
Vorwort
3
Inhaltsverzeichnis
5
Abbildungsverzeichnis
6
Tabellenverzeichnis
7
1 Einleitung
8
2 Grundlagen der Webprogrammierung
11
2.1
TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Das HTTP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4
Was ist HTML? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.6
CSS
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3 Softwareentwicklung für mobile Endgeräte
17
4 HTML5, CSS3 und JavaScript-APIs
19
4.1
Vergleich zu HTML 4
. . . . . . . . . . . . . . . . . . . . . . . .
19
4.1.1
Neuerungen . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1.2
Webapplikationen oine nutzen . . . . . . . . . . . . . . .
20
4.1.3
Video
4.1.4
Browserunterstützung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
22
23
4.2
JavaScript-APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Das JavaScript Framework jQuery Mobile
. . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3.1
Einführung
4.3.2
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3.3
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5 Appentwicklung für das Apple-Betriebssystem iOS
5.1
Native Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
Inhaltsverzeichnis
5.2
Vergleich von Webapps mit nativen Apps
. . . . . . . . . . . . .
32
6 Fazit
37
7 Ausblick
38
Literatur- und Quellenverzeichnis
40
Hilfsmittel
43
5/ 43
Abbildungsverzeichnis
2.1
Die vier Schichten von TCP/IP. . . . . . . . . . . . . . . . . . . .
2.2
Aufruf: http://webap-uklac05.klinikum.rwth-aachen.de/barcode/default.html. 13
2.3
1.Beispiel HTML-Dokument . . . . . . . . . . . . . . . . . . . . .
4.1
HTML5 & CSS3 Support, http://www.ndmebyip.com/litmus/,
4.2
vgl. jQuery Mobile Supported Platforms, http://jquerymobile.com/gbs/
2010 (Aufruf am 17.11.2011 um 13:00 Uhr)
. . . . . . . . . . . .
12
15
23
und in Anlehnung an: Original Graded Browser Matrix, http://jquerymobile.com/originalgraded-browser-matrix/; beide: 2010 (Aufruf am 4.11.2011 um
13:00 Uhr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
26
2.Beispiel HTML-Dokument . . . . . . . . . . . . . . . . . . . . .
28
3.Beispiel HTML-Dokument
. . . . . . . . .
29
. . . . . . . . .
29
4.5
mit jQuery Mobile .
3.Beispiel HTML-Dokument ohne jQuery Mobile
7.1
Barcode
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
7.2
iPod gekoppelt mit Bluetooth-Barcodescanner . . . . . . . . . . .
39
4.4
Tabellenverzeichnis
3.1
Vergleich: mobile Endgeräte vs. Desktop PCs [Davi12, vgl. S.7f.]
17
5.1
Vergleich von HTML5-Apps mit nativen Apps . . . . . . . . . . .
35
1 Einleitung
Smartphones und mit ihnen die mobilen Applikationen sind auf dem Vormarsch.
1 Dabei ist Smartphone nicht gleich Smartphone: es werden die unterschiedlichs-
ten Geräte mit verschiedenen Betriebssystemen vertrieben. Jedes Betriebssystem
besitzt seine eigenen Architekturen für die Entwicklung von mobilen Applikationen - den sogenannten Apps. Für Android existiert z.B. ein Android-SDK
2
für Java mit Klassenbibliotheken. Apps für Apples Betriebssystem iOS werden
dagegen mittels der Entwicklungsumgebung XCode in der Programmiersprache
Objective-C geschrieben. Damit ist jede so entwickelte App nur auf dem dafür
vorgesehenen Betriebssystem einsetzbar. Hat ein Unternehmen nun das Ziel, eine
App zu entwickeln, die auf möglichst vielen Betriebssystemen eingesetzt werden
soll, so muss für jedes Betriebssystem eine eigene App entwickelt werden.
HTML verspricht Abhilfe: Mittels HTML entwickelte mobile Webseiten sind
auf jedem Gerät aufrufbar - benötigt wird nur ein Browser, der HTML unterstützt. In seinem Buch HTML5 Mobile Websites - Turbocharging HTML5 with
jQuery Mobile, Sencha Touch, and Other Frameworks schreibt Matthew David:
If you look at all ve companies, Apple, Google, Microsoft, RIM and HP, and
their mobile operating systems, one single common thread can be see among
all of them: HTML5-enabled browsing. [Davi12, S.7] Er bezieht sich dabei auf
HTML5 - der neuesten Version von HTML. Diese wird aktuell diskutiert: Am
09.November 2011 verkündete z.B. Adobes Vizepräsident und Generalmanager
Danny Winokur, dass Adobe die Entwicklung vom Flash Player für die Browser
mobiler Geräte einstellen und sich mit HTML5 beschäftigen wird:
However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution
for creating and deploying content in the browser across mobile plat-
1
vgl. http://blogs.sybase.com/ubermobile/2011/07/infographic-forecasting-the-great-appstore-boom/
2
SDK ist die Abkürzung von Software Development Kit. Sie bietet verschiedene Werkzeuge
an, die z.B. von Softwareentwicklern benutzt werden können.
1 Einleitung
forms. We are excited about this, and will continue our work with key
players in the HTML community, including Google, Apple, Microsoft
and RIM, to drive HTML5 innovation they can use to advance their
mobile browsers. [Wino11]
Damit gab Winokur Apple-Gründer Steve Jobs posthum Recht: dieser hat im
April 2010 Adobe aufgefordert, sich mehr auf HTML5 zu konzentrieren als auf
Flash:
New open standards created in the mobile era, such as HTML5,
will win on mobile devices (and PCs too). Perhaps Adobe should
focus more on creating great HTML5 tools for the future, and less
on criticizing Apple for leaving the past behind. [Jobs10]
Steve Jobs weigerte sich, Flash auf seinen Systemen (z.B. dem iPhone) zuzulassen, er warb mehr für HTML5:
Though the operating system for the iPhone, iPod and iPad is proprietary, we [Apple] strongly believe that all standards pertaining to
the web should be open. Rather than use Flash, Apple has adopted
HTML5, CSS and JavaScript all open standards. Apple's mobile
devices all ship with high performance, low power implementations
of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers
create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is
completely open and controlled by a standards committee, of which
Apple is a member. [Jobs10]
3
Doch was ist HTML5? Was kann es? Inwieweit können mit HTML5, CSS
4 funktionsfähige Webanwendungen erstellt werden? Und welche
5
weitere Funktionalitäten bringen kostenlose Frameworks wie z.B. jQuery Mobile
und JavaScript
mit sich?
3
Mittels Cascading Style Sheets können Layoutvorlagen erstellt werden
Eine Skriptsprache
5
http://jquerymobile.com/
4
9/ 43
Die vorliegende Seminararbeit wird versuchen, eine Einführung in diese Thematik zu geben, die Fragestellungen zu beleuchten und - falls möglich - zu beantworten.
10/ 43
2 Grundlagen der
Webprogrammierung
Die Menschen sind heute nicht mehr verwurzelt, sondern vernetzt. [Lubk03,
S.109]
2.1 TCP/IP
Im Internet erfolgt die Kommunikation überwiegend mittels der Protokollfamilie TCP/IP. TCP ist die Abkürzung von
die Abkürzung für
Transport Control Protocol,
IP ist
Internet Protocol. IP- und TCP-Implementierungen sind Be-
standteile eines Betriebssystems.
Das TCP/IP-Referenzmodell baut mit seinen Schichten auf den Netzwerkkartentreibern auf. Abbildung 2.1 zeigt die vier Schichten von TCP/IP.
Die Anwendungsschicht - Application Layer - implementiert die Schnittstellen
für die Anwendungen. In der Anwendungsschicht werden Formalien festgelegt
wie z.B. das Format von Nachrichten. Des Weiteren benutzt die Anwendungsschicht Protokolle wie z.B. SMTP für E-Mails oder HTTP zur Übertragung von
Webseiten. Auf HTTP wird im nächsten Unterkapitel eingegangen. Die Anwendungsschicht gibt die Daten an die Transportschicht weiter.
Die Transportschicht - Transport Layer - ist für die Kommunikation zwischen
den Anwendungen (Anwendung 1 auf Gerät A will mit Anwendung 2 auf Gerät B kommunizieren) verantwortlich. Dabei wird TCP genutzt. TCP sorgt für
einen zuverlässigen Datentransport durch verbindungsorientierte Kommunika-
2.1 TCP/IP
Abbildung 2.1: Die vier Schichten von TCP/IP.
tion. Vor der eigentlichen Kommunikation wird eine Verbindung zwischen den
beiden Geräten, die miteinander kommunizieren wollen, aufgebaut und eine exklusive Leitung für die Kommunikation reserviert. Dabei täuscht TCP die Verbindungsorientierung vor, denn es wird nicht explizit eine Leitung für eine Kommunikation reserviert, sondern es wird durch Kontrollsegmente und Quittungen
sichergestellt, dass die Daten am Zielgerät fehlerfrei ankommen. Für den Transport werden die Daten - der Bytestrom - in IP-Pakete zerlegt und verschickt. Auf
dem Zielgerät müssen diese Pakete wieder zusammengesetzt werden. Für kurze
und schnelle Übertragungen existiert das Protokoll UDP - die Abkürzung von
User Datagram Protocol -, welches verbindungslos arbeitet, d.h. die Daten werden zufällig ins Netz geschickt - ohne Reservierung einer exklusiven Leitung.
Jedes IP-Paket erhält einen sogenannten Header, der Informationen zur eindeutigen Identizierung enthält und damit der korrekten Zustellung des Paketes
dient.
Die Internetschicht - Network Layer - sorgt für die Adressierung. Sie stellt
sicher, dass Rechner auch über die Grenzen des eigenen Rechners hinaus miteinander kommunizieren können. Dies geschieht, indem auch sie dem Paket einen
Header mit den erforderlichen Informationen hinzufügt. Das Protokoll dazu ist
IP.
Die Netzwerkschicht - Network Access Layer - verbindet durch ein Protokoll
den Host
1 mit dem Netz und bietet somit die Grundlage zur Versendung von
IP-Paketen. Auch sie fügt dem Paket einen Header hinzu.
1
Ein Host stellt in einem Netzwerk Dienste zur Verfügung.
12/ 43
Der Empfänger durchläuft diese Schichten in genau entgegengesetzter Richtung und jede Schicht liest den jeweiligen Header aus.
2.2 Das HTTP-Protokoll
HTTP ist die Abkürzung von
Hypertext Transfer Protocol, es ist ein Protokoll
der Anwendungsschicht (vgl. Kapitel 2.1). Es wird beim Aufruf von Webseiten
benutzt und verwendet TCP mit Port 80. Ein Port ist ein Kanal, über den ein
Protokoll angesprochen wird. Ports sind durchnummeriert. Bei der Adressierung
eines Protokolls wird folglich nicht nur die IP-Adresse, sondern auch die Portnummer angegeben. Im Allgemeinen dient das HTTP-Protokoll der Übertragung
von Daten in einem Netzwerk. Abbildung 2.2 zeigt an einem Beispiel den Aufruf
einer Webseite.
Abbildung 2.2: Aufruf:
http://webap-uklac05.klinikum.rwth-
aachen.de/barcode/default.html.
2.3 Webserver
Ein Webserver stellt Webanwendungen - genauer gesagt Webseiten, Graken und
andere Inhalte - zur Verfügung. Sie können über das HTTP-Protokoll z.B. von
einem Browser abgerufen werden.
13/ 43
2.4 Was ist HTML?
Im Windows-Umfeld existiert der IIS - die Abkürzung von Internet Information Services - , der für Windows Server verfügbar ist.[Micr11, vgl.] Dieser stellt
Dokumente und Daten über Protokolle wie z.B. HTTP oder FTP bereit.
2.4 Was ist HTML?
HTML ist die Abkürzung für
HyperText Markup Language.
Das Wort Hy-
pertext steht für einen Link, der auf eine andere Webseite führt und der Begri Markup bezeichnet eine Hervorhebung. HTML ist keine Programmiersprache im eigentlichen Sinne, sondern es ist - wie der Name es schon sagt - eine
Hypertext-Beschreibungssprache. Mit HTML können Dokumente erstellt werden, die dann von einem Browser dargestellt werden. HTML basiert auf dem
sogenannten SGML - das ist die Abkürzung für Structured Generalized Markup
Language[Lubk03, vgl. S. 109f.]
Von HTML existieren mehrere Versionen. Diese werden entsprechend durch
fortlaufende Nummern gekennzeichnet: Die neueste Version ist HTML5. Dementsprechend war die allererste Version von HTML das HTML 1, welches im Jahre
1990 veröentlicht wurde[Lubk03, vgl. S. 110]. HTML baut auf dem HTTPProtokoll auf.
Ein HTML-Dokument besteht aus ASCII-Zeichen. Es enthält zum einem Inhalt, welcher dargestellt wird und zum anderem eine Struktur dieses Inhaltes
mittels Tags, welche beschreiben, wie der Inhalt dargestellt wird. Ein Tag ist ein
in der jeweiligen HTML-Spezikation festgelegter Ausdruck, der vom Browser
interpretiert wird. Üblicherweise werden Tags durch spitze Klammern - also <
und > - dargestellt. Es gibt Start- und End-Tags.
Folgender Quellcode ist ein Beispiel für die Struktur eines einfaches HTMLDokuments:
1 < ! DOCTYPE h t m l>
2 <h e a d>
3
< t i t l e >D i e s
ist
ein
T i t e l </ t i t l e >
4 </ h e a d>
5 <b o d y>
6 <h2> D i e s
14/ 43
ist
eine
Ueberschrift
2 . Ordnung</ h2>
7 <a
h r e f =" b e i s p i e l 1 . h t m l ">
Dies
ist
ein
Link
auf
mich
s e l b s t </ a>
8 < ! −−
Dies i s t ein Kommentar−−>
9 </ b o d y>
10 </ h t m l>
Abbildung 2.3 zeigt das Ergebnis.
Abbildung 2.3: beispiel1.html
Die Dateiendung eines HTML-Dokumentes ist üblicherweise .htm oder .html.
2.5 JavaScript
JavaScript ist eine Skriptsprache. Skriptsprachen sind Sprachen, für die kein
Compiler benötigt wird, d.h. der Code muss nicht in Maschinensprache übersetzt
werden. JavaScript wird hauptsächlich clientseitig
2 eingesetzt 3 . JavaScript ist
plattformunabhängig: Die Verwendung von JavaScript ist unabhängig von dem
Betriebssystem eines Clients, es muss nur JavaScript auf dem Client verfügbar
sein.
2
3
D.h. das Skript wird vom Browser des Users ausgeführt und nicht auf dem Webserver
Ein Beispiel für serverseitigen Einsatz von JavaScript ist ASP.NET, mit welchem Webanwendungen - auf dem .NET-Framework aufbauend - erstellt werden.
15/ 43
2.6 CSS
In einem HTML-Dokument kann JavaScript eingebunden werden - entweder
direkt in die Datei oder ausgelagert in einer eigenen Datei. Der JavaScript-Code
wird dann zur Laufzeit von dem Webbrowser interpretiert. Das HTML-Tag zur
Verwendung von JavaScript lautet <script> bzw. für JavaScript-Code <script
type="text/javascript">.
JavaScript wird in einer Sandbox ausgeführt. Sie begrenzt den Zugri von
JavaScript auf Browserobjekte, um zu verhindern, dass JavaScript-Code uneingeschränkt auf Ressourcen des Clients wie z.B. dem Dateisystem zugreifen kann.
2.6 CSS
CSS ist die Abkürzung von
Cascading Style Sheets. CSS wird im Zusammen-
hang mit HTML für die Gestaltung der durch HTML denierten Inhalte benutzt.
Mittels CSS kann eine Vorlage, die Stylesheet genannt wird, angefertigt werden,
die auf das komplette Dokument angewandt wird. Z.B. kann darin festgelegt
werden, dass jeder Link, der bereits von dem User angeklickt wurde, in rot dargestellt wird. Soll die Farbe dann irgendwann z.B. in grün umgewandelt werden,
so muss diese Änderung nur an einer Stelle - in der css-Stylesheet-Deniton und nicht bei jedem Link eingepegt werden.
Auch CSS bendet sich in einem permanentem Entwicklungsprozess: die erste
Version von CSS - CSS 1.0 - wurde im Jahre 1996 veröentlicht. Die aktuelle
Version ist CSS 3.0.
16/ 43
3 Softwareentwicklung für mobile
Endgeräte
Mobile Endgeräte besitzen andere Merkmale als Desktop PCs. Die Tabelle 3.1
vergleicht einige Merkmale von mobilen Endgeräten mit Desktop PCs.
Merkmal
Desktop PC
mobiles Endgerät
Displayauösung
Standard: 1280x1024
zwischen 240x400 und
Pixel
800x480 Pixel
Orientierung
Querformat
Portrait und Landscape
Bedienung
Maus und Tastatur
Hand
Netzwerkverbindung
meist LAN
WLAN oder UMTS
Rechenleistung
Gröÿenordnung
Gröÿenordnung
GFLOPS
1
MFLOPS
Tabelle 3.1: Vergleich: mobile Endgeräte vs. Desktop PCs [Davi12, vgl. S.7f.]
Aus den Unterschieden ergeben sich einige Punkte für die Softwareentwicklung
für mobile Endgeräte, die sich von der für Desktop PCs unterscheiden:
Da die Displayauösungen bei mobilen Endgeräten generell kleiner als bei
Desktop-PCs sind, muss beim Design beachtet werden, dass auch alles erkennbar
ist. Vor allem muss berücksichtigt werden, dass die Bandbreite der Displayauösungen für mobile Endgeräte sehr groÿ ist. Auch sollte - wegen der Überschaubarund Nutzbarkeit - eine Softwarelösung für ein mobiles Endgerät nur Funktionen
anbieten, die wirklich benötigt werden. Auch muss berücksichtigt werden, dass
sich der Bildschirm der meisten mobilen Endgeräten drehen lässt, wodurch sich
die Seitenverhältnisse ändern. Die mobile Anwendung muss darauf reagieren und
das Design dementsprechend anpassen.
Mobile Endgeräte werden in aller Regel über einen berührungssensitiven Bild-
1
FLOPS ist die Abkürzung von
Floating-Point Operations
Per Second
schirm (Touchscreen) - und nicht über Eingabegeräte wie Maus und Tastatur bedient. Die Konsequenz ist, dass Buttons und andere Formen von der Gröÿe
her so dargestellt werden müssen, dass sie mit dem Finger bedienbar sind. Die
Gröÿe darf dementsprechend nicht zu klein sein. Des Weiteren sollte das Eingeben von langen Texten vermieden werden, da dies ein langsamer und unter
Umständen schwieriger Prozess für den User darstellt. Deshalb sollten - wenn es
möglich ist - mehrere Optionen oder ein Standardtext vorgegeben werden. Auch
sollte berücksichtigt werden, dass die eingeblendete Tastatur meistens einen Teil
des Bildschirms verdeckt.
Es muss auch davon ausgegangen werden, dass ein Nutzer eines mobilen Endgerätes sich bewegt, d.h. im Extremfall ändert sich seine Position dauernd. Dies
hat zur Folge, dass keine konstante und schnelle Netzverbindung zu erwarten
ist. Deshalb muss zum einem mit einer niedrigen Übertragungsgeschwindigkeit,
zum anderem mit kurzzeitigen Oine-Phasen gerechnet werden. Konsequenzen
hat dies z.B. für Videos oder groÿen Graken, die auf einem mobilen Endgerät
angezeigt werden sollen. Hier sollte über eine Anpassung der Inhalte nachgedacht werden. Kommt der User mit seinem mobilen Endgerät in ein Gebiet ohne
Empfang, so sollte sich dies so wenig wie möglich auf die Software auswirken.
Dies kann z.B. durch lokale Puer, in denen Daten zwischengespeichert werden,
geschehen.
Auch die deutlich langsamere Rechenleistung im Vergleich zu einem DesktopPC sollte berücksichtigt werden. Deshalb sollte eine Software für mobile Geräte keine unnötigen Operationen ausführen. Eine Lösungsmöglichkeit, dennoch
komplexe Anwendungen auszuführen, ist z.B. die Ausführung dieser auf einem
Server und nicht auf dem Client selbst. Auch sollte die Software nur Funktionen
anbieten, die sinnvoll sind. Dies dient auch der besseren Anwendbarkeit der Software für den User, der dann von unnötigen, zu komplexen oder unverständlichen
Funktionen verschont wird.
18/ 43
Die HTML-Spezikationen werden vom World Wide Web Consortiums - abgekürzt als W3C - entwickelt. Dieses Gremium gibt sogenannte W3C Recommendations (deutsch: W3C Empfehlungen) heraus, die Techniken des World
Wide Webs betreen. Gegründet wurde das W3C von Tim Berners-Lee, der
als Gründer von HTML gilt. Die Idee von HTML entwickelte er während seiner Tätigkeit am CERN. Er machte sich Gedanken über einen Informationsaustausch zwischen Wissenschaftlern. Tim Berners-Lee wollte verhindern, dass
Wissen mit Menschen verloren geht, wenn diese den CERN
1 verlassen. Mithilfe
eines Hypertext-Systems wollte er eine Möglichkeit schaen, rasant veränderndes
Wissen aufzuzeichnen.[Bern89, vgl.]
HTML5 ist die neueste Version von HTML. Sie bendet sich oziell allerdings
noch in der Entwicklungsphase durch den W3C, Standard ist zur Zeit HTML
2
4 .
4.1 Vergleich zu HTML 4
4.1.1 Neuerungen
3
HTML5 deniert neue Elemente und Attribute . Die Syntax ist kompatibel
zu der von HTML 4. Im Zusammenhang mit HTML5 sind aber auch neue
JavaScript-APIs deniert worden. Eine API (Abkürzung von application programming interface) ist eine Programmierschnittstelle. Sie stellt Methoden und
1
Europäische Organisation für Kernforschung
Die genaue Spezikation von HTML 4.01 nden Sie unter http://www.w3.org/TR/html401/
3
Die HTML5-Spezikation nden Sie unter http://www.w3.org/TR/html5/
2
Funktionen bereit, die ein Softwareentwickler benutzen kann, wenn er die API in
seine Software einbindet. Im folgenden Unterkapitel wird beispielhaft auf einige
Aspekte eingegangen.
4.1.2 Webapplikationen oine nutzen
HTML5 bietet als Möglichkeit zur Oine-Speicherung einer Webanwendung die
Möglichkeit des Caches: Ein Cache ist ein temporärer Zwischenspeicher, in dem
Ressourcen gespeichert werden, auf die öfter zugegrien wird. Bei HTML5 kann
eine Datei - das sogenannte Cache Manifest - erstellt werden, die angibt, welche
Dateien auf dem Client gespeichert werden sollen. Bei dem ersten Aufruf einer
Webseite werden die im Cache Manifest angegebenen Dateien auf dem Client gespeichert. Bei jedem Aufruf der Webseite werden die lokal gespeicherten Dateien
verwendet. Zusätzlich wird das Cache Manifest ausgelesen und überprüft, ob sich
Änderungen in der Datei benden. Falls ja, wird diese erneut komplett abgearbeitet und die neuen Dateien beim nächsten Aufruf der Webseite verwendet. In
dem Cache Manifest kann nicht nur angegeben werden, welche Dateien gecachet
werden sollen, sondern es können auch explizit Dateien angegeben werden, die
nicht gecachet werden sollen, diese sind dann aber z.B. bei nicht vorhandener
Netzwerkverbindung auch nicht von dem Browser darstellbar. Eine dritte Möglichkeit ist, eine gecachte Datei anzugeben, die angezeigt wird, falls die eigentlich
anzuzeigende Datei nicht verfügbar ist (wie es z.B. bei nicht vorhandener Netzwerkverbindung der Fall sein kann) [SpHa11, vgl S.238.].
Web Storage ist eine JavaScript-API, die oftmals als Teil der
HTML5-Spezikation erwähnt wird. Tatsächlich ist es aber eine eigene Spezikation des W3Cs. Web Storage stellt Methoden zur Speicherung von Daten auf
4 können maximal 4096 Byte gespei-
dem Client zur Verfügung. In einem Cookie
chert werden gespeichert werden. Dagegen wird bei Web Storage vom W3C ein
Speicherlimit von 5 MB vorgeschlagen. Wenn dieses Limit erreicht worden ist,
empehlt der W3C, dass der User darüber benachrichtigt wird und dann entscheiden kann, ob das Speicherlimit für die eine Webseite erhöht werden soll.
Eine weitere Empfehlung des W3C ist es, dass der Nutzer einsehen kann, welche
Webseite wie viel Speicherbereich belegt.[W3C11, vgl.] Die Web Storage Daten
werden nicht bei jeder Anforderung zum Webserver geschickt, wie es bei Cookies
der Fall ist. Web Storage kann z.B. benutzt werden, um Benutzereinstellungen
dauerhaft oder sich nicht ändernde Daten zwischenzuspeichern. Durch die Spei-
4
Ein Cookie ist eine Datei mittels der eine Webseite individuell Informationen auf dem Client
speichern und sie später abrufen kann.
20/ 43
cherung auf dem Client ist für den Abruf der Daten keine Verbindung zu dem
Webserver notwendig. Dies ist gerade für mobile Geräte nützlich, falls diese z.B.
sich an einem Ort benden, wo kein Netz zur Verfügung steht.
Von Web Storage gibt es zwei Arten: sessionStorage und localStorage.
SessionStorage sind Daten, die nur bis zum Ende einer Session(Sitzung) behalten werden. Wird das Browserfenster oder der Tab geschlossen, so werden
automatisch alle Daten in sessionStorage gelöscht. Dies hat z.B. den Vorteil,
dass sich die sessionStorages verschiedener Sessions nicht gegenseitig beeinus-
5 durchaus möglich ist.
sen können, was z.B. bei Cookies
Im Gegensatz zu sessionStorage stehen Daten aus dem localStorage auch nach
dem Ende einer Session zur Verfügung. Ein Neustart des Browsers oder des Systems hat keinen Einuss. Gelöscht werden die Daten von localStorage entweder
programmatisch oder durch das Einstellen von privatem Browsen auf dem jeweiligem Client.
Sowohl localStorage als auch sessionStorage werden als Schlüssel-Wert-Paare
gespeichert. Beim Ändern von localStorage oder sessionStorage wird ein StorageEvent ausgelöst, welches programmatisch abgefangen werden kann, um angemessen zu reagieren.
Da sessionStorage an die jeweilige Session gekoppelt ist, hat nur die Webseite
der aktuellen Session Zugri auf diese Daten. Anders ist dies bei localStorage, dessen Daten sich so lange auf dem Client benden, bis sie entweder mittels einer Anwendung oder durch einen User explizit gelöscht werden. Ist dies
nie der Fall, können die Daten theoretisch für immer auf dem jeweiligen Client verweilen. Des Weiteren werden diese Daten unverschlüsselt gespeichert. Für
den User sind die Daten folglich einsehbar. Für andere Anwendungen gestaltet
sich der Zugri auf diese Daten etwas komplizierter: Der Zugri auf die Daten
von localStorage geschieht mittels JavaScript. Ein Sicherheitskonzept die sogenannte Same-Origin-Policy, abgekürzt SOP erlaubt JavaScript nur dann auf
localStorage zuzugreifen, wenn es aus derselben Quelle stammt, die diese Daten
auch angelegt hat. Jede Webseiten-Domäne verfügt sozusagen über einen eigenen Speicherbereich auf dem Client. Damit können aber auch andere Webseiten
5
Weitere Informationen zu Cookies nden Sie hier: http://www.faz.net/hilfe/2.335/was-istein-cookie-111792.html
21/ 43
der gleichen Domäne, von übergeordneten Domänen oder von Unterdomänen
auf diese Daten zugreifen.[SpHa11, vgl. S. 198] Das W3C empehlt zudem, das
Speicherlimit für eine gesamte Oberdomäne zu begrenzen, damit nicht durch
die Verwendung mehrerer Unterdomänen mehr Speicher als eigentlich vorgesehen benutzt werden kann.[W3C11, vgl.] Die Web Storage-Daten sind genau
wie Cookies an den jeweiligen Browser gebunden. Durch solche Methoden ist
keine permanente Verbindung zu dem Webserver notwendig, diese wird nur im
Falle einer Datenaktualisierung gebraucht. Diese Funktionen sind zwar Teil der
HTML5- bzw. der Web Storage-Spezikation, werden allerdings nicht von jedem
Browser unterstützt.
4.1.3 Video
Videos können durch das Video-Tag - <video> - direkt in eine HTML-Seite
eingebettet werden. Für das Abspielen von Videos in einem HTML-Dokument
war bisher allerdings immer ein Drittanbieter-Plugin wie z.B. QuickTime, RealPlayer oder Flash notwendig. Unterstützt der Browser allerdings HTML5, so
sind in Verbindung mit dem Video-Tag keine Plugins mehr notwendig.
Videos bestehen aus Video- und Audiospuren. Jedes Video hat einen Container und einen Codec. Der Container bestimmt das Dateiformat und enthält die
Daten, die mit einem bestimmten Codec digital kodiert wurden (damit geht auch
eine Komprimierung einher). Der Codec dekodiert die Daten beim Abspielen auf
dem PC wieder. Es existieren zahlreiche verschiedene Container und Codecs. Ein
Video mit der Dateiendung .wmv hat z.B. das Windows Media Video als VideoCodec, der Container ist meistens das Advanced Streaming Format (ASF).
Das resultierende Problem für Webanwendungen mittels HTML5 ist, dass die
verschiedenen Browser verschiedene Codecs benutzen: Firefox und Opera z.B.
benutzen Theora als Video-Codec und Vorbis als Audio-Codec in einem OggContainer. Safari verwendet das MPEG-4-Format mit dem H.264 Video-Codec
und AAC Audio-Codec.[Tw10, vgl.]. Solange kein einheitliches Format exisitert,
kann dieses Problem dadurch gelöst werden, dass im Source-Code für jedes Format, welches unterstützt werden soll, ein Video mit dem entsprechenden Dateityp hinterlegt wird. Der aufrufende Browser geht diese Zeilen so lange durch,
bis er ein Format gefunden hat, welches er dekodieren kann. Für den Fall, dass
ein Browser keines der angebotenen Formate oder generell kein HTML5 unterstützt, ist es möglich ein sogenanntes Fallback anzugeben. Dadurch kann dann
22/ 43
auf die Drittanbieter-Plugins wie z.B. Flash zurückgegrien werden oder es wird
ein Text dargestellt, der den User darüber informiert, dass der von ihm benutzte
Browser nicht die notwendige Unterstützung für das Abspielen des Videos bietet.
Vorteil von HTML5-Videos ist z.B., dass nicht mehr ein bestimmter Bereich
einer Webseite für ein Plugin reserviert wird, welches dann das Video darstellt,
sondern die Darstellung des Videos wird komplett selbst von dem HTML5-Code
übernommen.
4.1.4 Browserunterstützung
Wie schon oben erwähnt, wird nicht von jedem Browser jeder Teil der HTML5Spezikation unterstützt. Abbildung 4.1 gibt einen Überblick über die Unterstützung von HTML5-Webanwendungen durch verschiedene Browser.
Abbildung 4.1: HTML5 & CSS3 Support, http://www.ndmebyip.com/litmus/,
2010 (Aufruf am 17.11.2011 um 13:00 Uhr)
23/ 43
4.2 JavaScript-APIs
Die Abbildung lässt erkennen, dass der Browser, der auf einem WindowsBetriebssystem z.Z. die gröÿtmöglichste Unterstützung für HTML5-Webanwendungen
bietet, der Safari 5 ist.
6
4.2 JavaScript-APIs
Mit HTML5 sind einige neue - über JavaScript zugängliche - APIs entwickelt
worden. Die Web Storage-API wurde bereits im Kapitel 4.1.2 vorgestellt. Die
folgende Auistung enthält einige APIs beispielhaft:
•
HTML5 Drag und Drop-API: Umsetzung von Drag und Drop-Operationen
auf Webapplikationen
•
Web Storage: Daten im Browser speichern (siehe Kapitel 4.1.2)
•
Geolocation: Auslesen von Standortinformationen
•
File Writer: Schreiben von Dateien aus dem Browser heraus
•
Google Maps: Laden von Google Maps
•
Application Cache: Ansprechen des Oinecaches
•
Media elements: Audio und Video-Optionen
Nicht jede API ist Teil der HTML5-Spezikation. Einige dieser APIs werden von
W3C als standalone specications weiterentwickelt - wie z.B. die in Kapitel
4.1.2 erwähnte Web Storage API.
6
Einen Überblick über Features des Safari-Browsers
http://www.apple.com/de/safari/features.html.
24/ 43
nden
Sie
unter
4.3 Das JavaScript Framework jQuery Mobile
4.3.1 Einführung
jQuery Mobile ist ein auf JavaScript basiertes Framework. Es ist eine Weiterent-
7
wicklung der Bibliothek jQuery :
The jQuery Mobile framework is jQuery's latest rabbit out of the hat
project. The jQuery Mobile framework is open source and is supported by all the big players; iOS, Android, Bada, BlackBerry, Nokia,
Adobe, and so, covering all the names behind the project. [Bai11,
S.1]
jQuery Mobile wurde am 11. August 2010 angekündigt [Bai11, vgl S.8]. Sie
stellt Funktionen - vor allem Layouts und Widgets - zur Entwicklung von Webseiten und Webapps zur Verfügung. Abbildung 4.2 beschreibt, welche Geräte von
jQuery Mobile Beta 1.0 RC2 unterstützt werden. jQuery Mobile verfolgt das Ziel,
eine möglichst groÿe Zahl von Plattformen und Geräten zu unterstützen, nicht
nur High-End-Smartphones:
If you have the latest web browser then you will get all the bells and
whistles; if you have an older browser then the page will still render
and you will still have access to the content. The goal is to allow
you as a developer and designer to add complex features such as 3D
page transitions found in iOS, but you still have the page load and
function on devices that are several years old. [Davi12, S.70]
Falls eine neue Funktion von einem Browser nicht unterstützt wird, wird auf
eine ältere Funktion zurückgegrien, sodass für den User mit dem älteren Browser möglichst keine Nachteile entstehen und die Webseite trotzdem in vollem
Funktionsumfang benutzt werden kann.
Die Nutzung von jQueryMobile geschieht, indem folgende Zeilen in den Header
eingefügt werden:
7
Weitere Informationen zu jQuery nden Sie unter http://jquery.com/
25/ 43
Abbildung 4.2: vgl.
jQuery
Mobile
Supported
Platforms,
http://jquerymobile.com/gbs/ und in Anlehnung an: Original
Graded
Browser
Matrix,
http://jquerymobile.com/original-
graded-browser-matrix/; beide: 2010 (Aufruf am 4.11.2011 um
13:00 Uhr)
1 <l i n k
r e l =" s t y l e s h e e t "
h r e f =" h t t p : / / c o d e . j q u e r y . com /
mobile / 1 . 0 / j q u e r y . mobile
2 <s c r i p t
− 1 . 0 . min .
css "
/>
s r c =" h t t p : / / c o d e . j q u e r y . com / j q u e r y
− 1 . 6 . 4 . min .
j s "></ s c r i p t >
3 <s c r i p t
s r c =" h t t p : / / c o d e . j q u e r y . com / m o b i l e / 1 . 0 / j q u e r y .
mobile
− 1 . 0 . min .
j s "></ s c r i p t >
Diese binden die erforderlichen Dateien für jQuery Mobile ein. Alternativ können
die Dateien auch bei http://jquerymobile.com/download/ heruntergeladen und
auf einem eigenen Webserver gehostet werden.
26/ 43
4.3.2 Design
Die Denitionsdateien von jQuery Mobile enthalten eine CSS-Datei. Dadurch
ist das Design der Formen einheitlich vorgegeben und muss nicht jedes Mal
vom Entwickler selbst vorgegeben werden. Das Design, welches in dieser CSSDatei kodiert ist, ist optimal auf mobile Apps zugeschnitten - insbesondere,
was die Gröÿe betrit. Trotzdem ist der Entwickler nicht auf einen einzigen
Designstil festgelegt: zu den meisten Widgets existieren sogenannte Themes, die
dem Entwickler eine Auswahl an Designstilen anbieten.
Das folgende Beispiel zeigt mehrere Buttons, die sich nur in ihrem Theme und
der Beschriftung unterscheiden, wie auch aus dem Source-Code ersichtlich ist:
1 < ! DOCTYPE h t m l>
2 <h e a d>
3
< t i t l e>B e i s p i e l
4
<l i n k
2</ t i t l e >
r e l =" s t y l e s h e e t "
h r e f =" h t t p : / / c o d e .
j q u e r y . com / m o b i l e / 1 . 0 / j q u e r y . m o b i l e
. css "
5
<s c r i p t
s r c =" h t t p : / / c o d e . j q u e r y . com / j q u e r y
− 1 . 6 . 4 . min .
6
<s c r i p t
− 1 . 0 . min
/>
j s "></ s c r i p t >
s r c =" h t t p : / / c o d e . j q u e r y . com / m o b i l e
/ 1 . 0 / j q u e r y . mobile
− 1 . 0 . min .
j s "></ s c r i p t >
7 </ h e a d>
8 <b o d y>
9 <a
h r e f =" i n d e x . h t m l "
>Theme
10 <a
>Theme
11 <a
d a t a − t h e m e=" b "
d a t a − r o l e =" b u t t o n "
d a t a − t h e m e=" c "
d a t a − t h e m e=" d "
d a t a − t h e m e=" e "
d</ a>
>Theme
c</ a>
>Theme
13 <a
d a t a − t h e m e=" a "
b</ a>
>Theme
12 <a
a</ a>
e</ a>
14 </ b o d y>
15 </ h t m l>
Abbildung 4.3 zeigt das Ergebnis.
27/ 43
Wie das Design von jQuery Mobile aussieht, kann unter
http://jquerymobile.com/demos/1.0b1/ beobachtet werden. jQuery Mobile setzt
seine komplette Dokumentation auf dem jQuery Mobile-Framework selbst auf.
Mit Hilfe der CSS-Denition ist es folglich mit einfacheren Mitteln möglich,
ein konsistentes und einheitliches Layout zu erstellen und zu pegen.
4.3.3 Features
jQuery Mobile kann mit dem Element <div> benutzt werden. Diesem Element
kann eine Rolle zugewiesen werden, z.B page für eine Seite, header für den
Kopf einer Seite, footer für den Fuÿ einer Seite, navbar für eine Navigationsleiste oder content für Inhalt. Das div-Element wird zur Strukturierung
von Inhalten einer Seite benutzt: logisch zusammengehörende Elemente sollen
auch optisch zusammengehörend dargestellt werden. Es wird auch von älteren
Versionen von HTML verstanden.
28/ 43
Folgender Source-Code wird für den Inhalt einer HTML-Seite benutzt:
1 <b o d y>
2 <d i v
d a t a − r o l e =" p a g e ">
3
<d i v
d a t a − r o l e =" h e a d e r "> H e a d e r</ d i v>
4
<d i v
d a t a − r o l e =" c o n t e n t "> C o n t e n t</ d i v>
5
<d i v
d a t a − r o l e =" f o o t e r "> F o o t e r</ d i v>
6 </ d i v>
7 </ b o d y>
Abbildung 4.4 zeigt, wie die Webseite mit Einbindung von jQuery Mobile aussieht, Abbildung 4.5 zeigt das Aussehen der Webseite ohne Einbindung von jQuery Mobile. Dies ist ein wesentlicher Eekt der CSS-Denition von jQuery Mobile,
das Interpretieren dagegen basiert auf der JavaScript-Datei von jQuery und der
darauf aufbauenden Datei von jQuery Mobile.
mit jQuery Mobile
ohne jQuery Mobile
Des Weiteren ist es mit jQuery Mobile möglich, mehrere Seiten in einer HTMLDatei zu denieren. Dadurch kann ein Performance-Gewinn entstehen, da dadurch nicht für jede Seite eine neue Datei geladen werden muss, sondern nur
eine einzige für alle. Das Wechseln von Seiten innerhalb einer Datei beansprucht
dann weitaus weniger Bandbreite.
29/ 43
In der aktuellen Version 1.0 hat die CSS-Datei von jQuery Mobile eine Gröÿe
von 7KB, die JavaScript-Datei eine Gröÿe von 24KB. Kleine Dateigröÿen haben den Vorteil, dass nicht viel Bandbreite einer Verbindung beansprucht wird.
Gerade bei mobilen Anwendungen sind solche Performance-Gewinne äuÿerst einussreich.
30/ 43
5 Appentwicklung für das
Apple-Betriebssystem iOS
iOS ist ein von Apple entwickeltes Betriebssystem für mobile Geräte. Das iPhone, der iPod touch und das iPad werden mit iOS ausgeliefert. Es basiert auf
Mac OS X - dem Betriebssystem von Macintosh-Desktop-Computern - , welches
1
wiederum auf Unix basiert. Die neueste Version von iOS ist iOS 5 .
Zentral für iOS ist die Multi-Touch-geeignete Oberäche und Homescreen, auf
dem alle Apps abgelegt sind und von dem User individuell angeordnet werden
können. Einige Apps sind vorinstalliert, wie z.B. iTunes, Kalender, Mail, Kamera,
Erinnerungen oder Safari. Im App Store gibt es kostenpichtige und -lose Apps,
mit denen der User sein Gerät individuell erweitern kann. Dafür muss er einen
User Account bei Apple erstellen - eine sogenannte Apple-ID. Jedes Gerät wird
mit einer Apple-ID registriert.
5.1 Native Apps
Native Apps werden für das Apple-Betriebssystem iOS in der Programmiersprache Objective-C programmiert. Der Einsatz von JavaScript ist auch möglich.
Die von Apple bereitgestellte Entwicklungsumgebung XCode gibt es momentan
2
in der Version 4.2 . XCode kann nur auf einem Apple-Betriebssystem installiert
werden. Die dazugehörige API für das Entwickeln von Apps für iOS ist die Cocoa
Touch API.[Appl11, vgl.]
1
2
Mehr Infos zu iOS 5 unter http://www.apple.com/de/ios/features.html
Sie
ist
nach
kostenloser
Registrierung
als
Apple-Developer
http://developer.apple.com/xcode/ downloadbar.
unter
5.2 Vergleich von Webapps mit nativen Apps
Die Frage, ob eine Webapp oder eine native App geeigneter ist, ist nicht pauschal
zu beantworten. Sie ist abhängig von dem jeweiligen Kontext.
Im Folgenden wird von vier verschiedenen Szenarien für die Entwicklung einer
App ausgegangen:
1. rmeninterne App, geschlossene Benutzergruppe
2. rmeninterne App, oene Benutzergruppe
3. weltweite App, geschlossene Benutzergruppe
4. weltweite App, oene Benutzergruppe
Das erste Szenario beschreibt die Entwicklung einer
der der
Nutzerkreis klar deniert
rmeninternen App, bei
ist: es handelt sich um Mitarbeiter oder
einem bestimmten, klar denierten Teil von Mitarbeitern des Unternehmens. Es
kann davon ausgegangen werden, dass die App eingeschränkt oine-fähig sein
sollte, falls das Gerät keine Netzverbindung hat. Dabei bedeutet oine-fähig
nicht, dass die Inhalt trotzdem komplett zur Verfügung stehen müssen, da eine
rmeninterne App in der Regel auf Daten zugreift, die auf netzinternen Servern
liegen. Des Weiteren kann davon ausgegangen werden, dass das mobile Gerät,
mit dem die App aufgerufen wird, sich im Intranet bendet - sei es über WLAN
oder VPN. Damit sollten die bestehenden Sicherheitskonzepte greifen, z.B. sollte
eine Benutzerauthentizierung stattnden.
Das zweite Szenario ist die Entwicklung einer rmeninternen App für eine
oene Benutzergruppe. Dieses Szenario kann vernachlässigt werden, da bei
einer rmeninternen App die Benutzergruppe immer bekannt ist.
Eine
weltweite App für eine geschlossene Benutzergruppe beschreibt
das dritte Szenario. Hierbei sind die Kunden schon bekannt. Dies ist z.B. der
Fall, wenn es sich bei der App um eine mobile Version einer schon vorhandenen
Software oder Webseite handelt.
32/ 43
Das letzte Szenario ist eine
weltweite App für eine oene Benutzer-
gruppe. Hierbei muss die Benutzergruppe von der angebotenen App erfahren,
es muss Werbung betrieben werden.
Für rmeninterne Apps empehlt sich eine HTML5-App. Grundsätzlich ist
die HTML5-App mit jedem Browser aufrufbar, einzige Bedingung ist die Unterstützung von HTML5. HTML5 ist plattformund geräteunabhängig. Bei einer
nativen App dagegen muss für jedes Betriebssystem eine eigene App progammiert werden, da jedes Betriebssystem andere Programmiersprachen und andere
Frameworks unterstützt. Bei HTML5-Apps ist nur ein Webserver notwendig und
Updates können schnell verbreitet werden, indem die neue Version der App auf
den Webserver geladen wird. HTML geht - wie oben beschrieben - oft mit CSS
einher. Apple-Geräte sind für CSS optimiert, wie Matthew David in einem Buch
HTML5 Mobile Websites - Turbocharging HTML5 with jQueryMobile, Sencha
Touch, and Other Frameworks erläutert:
For mobile web design you will use CSS to format your web pages.
[...]Apple has GPU accelerated support for CSS. What this means is
that CSS simply runs faster. Animations, rounded corners, embedded
fonts, and transforms all look great on the iPhone. The powerful new
Nvidia and Qualcomm chipsets appearing in the most smart phones
really give presentation in your web pages an edge. The result is that
you can use CSS to design native app-like solutions without having
to write native code. Just CSS. [Davi12, S.16]
Mittels CSS ist es auf Apple-Geräten möglich, HTML5-Apps so zu entwerfen,
dass kaum ein Unterschied mehr zu einer nativen App besteht. Auch Apples
Browser Safari ist für HTML5 geeignet: er baut sowohl in seiner mobilen als
auch in seiner Desktopversion auf WebKit auf. WebKit ist eine OpenSource
Plattform. Und WebKit unterstützt HTML5[Davi12, vgl. S.4].
Apple bietet zwar eine In-House Distribution an, bei dem im Firmenintranet
ein interner App Store erstellt wird. Hierbei entfällt der Genehmigungsprozess
von Apples App Store. Allerdings ist dieses Programm kostenpichtig und kann
nur für die Verteilung nativer Apps genutzt werden. Auch ist die Entwicklung
von nativen Apps für iOS nur auf einem Macintosh-Computer mit Mac OS X
möglich(s.o.: XCode ist nur auf Mac OS X installierbar).
Bei einer
weltweiten App für eine geschlossene Benutzergruppe emp-
33/ 43
ehlt sich - aus den gleichen Gründen wie oben - eine HTML5-App. Schon bestehende Kunden können über die App benachrichtigt werden z.B. durch eine Mail,
Werbung auf der Webseite oder eingeblendete Werbung in der schon bestehenden
Software.
Soll dagegen eine App weltweit für eine oene Benutzergruppe vertrieben werden, so empehlt sich eine native App in den meisten Fällen mehr.
Zwar entfallen bei HTML5-Apps die Kosten für eine jährliche Entwicklerlizenz.
Allerdings gibt es ein enormes Problem: wie wird der User auf den Webserver,
auf dem die HTML5-App angeboten wird, aufmerksam? Ist die App keine mobile Version einer Webseite oder einer Software, so muss die Kunden erst einmal
gefunden werden, das Produkt muss vermarktet werden. Bei einer nativen App
wird die Vermarktung von Apple übernommen. Die Vorteile: der App Store ist
auf jedem iOS-Gerät vorinstalliert, die Vermarktung und Bezahlung wird von
Apple übernommen. Des Weiteren ist der App Store bekannt bei potenziellen
Kunden. Deshalb ist zu erwarten, dass die meisten User -insbesondere die nicht
so technikorientierten User- sich eine App mit der gewünschten Funktionalität
im App Store suchen werden. Allerdings ist dies mit Kosten verbunden: zum
einem fällt eine jährliche Entwicklerlizenz an, zum anderen behält Apple 30%
des Gewinns als Provision. Auch muss jede App einen Genehmigungsprozess erfolgreich durchlaufen, bevor sie im App Store vermarktet werden darf. Dieser
Genehmigungsprozess gewährleistet aber auch, dass gewisse Qualitätsstandards
eingehalten werden.
Aktuell wurde in dem Genehmigungsprozess, den jede App durchläuft, bevor
sie in Apples App Store vertrieben wird, eine Sicherheitslücke entdeckt: Charlie Miller entwickelte eine Börsenticker-App. Diese wurde von Apple für den
App Store freigegeben. Beim Starten dieser App konnte Charlie Miller unsignierten Code nachladen. In einem Video demonstriert er z.B. den Zugri auf
das Adressbuch eines iPhones. Grund dafür ist wohl, dass JavaScript auf einer
tieferen Speicherebene als üblich ausgeführt wird. Damit wollte Apple erreichen,
dass die Geschwindigkeit seines Browser erhöht wird. Die Schutzmechanismen,
die verhindern sollen, dass durch JavaScript-Code Missbrauch betrieben wird,
haben wohl eine Lücke, die Charlie Miller ausnutzte. Als Konsequenz wurde
Charlie Miller seine Entwicklerlizenz entzogen. [Schw11, Pryj11, vgl.]
In den meisten Fällen kann anhand der oben beschriebenen Szenarien entschieden werden, ob eine HTML5- oder eine native App eingesetzt werden soll.
Die Tabelle 5.1 vergleicht einige Kriterien für eine HTML5- und eine native App.
34/ 43
Kriterium/Merkmal
HTML5-App
native App
Oine-Fähigkeit
gegeben, ca. 5 MB
voll gegeben
Daten speicherbar
(siehe Kapitel 4.1.2)
Hardware-Zugri
sehr eingeschränkt
möglich, über
bereitgestelle APIs auf
z.B: GPS, 3D-, Push-,
Hardware-Funktionen,
Grakbeschleunigung
Entwicklungsumgebung
Editor
nur auf
Macintosh-Computer
mit Mac OS X möglich
nötiges Know-How
Wiederverwendbarkeit
JavaScript, HTML5,
Objective-C,
CSS3
Cocoa-API
möglich
eingeschränkt möglich
über Webbrowser
automatisch auf
von Code und Logik
Zugri
Homescreen sichtbar
Setzen eines
"Lesezeichens auf den
Homescreen möglich
Plattform- und
ja
nein
geräteunabhängig
Tabelle 5.1: Vergleich von HTML5-Apps mit nativen Apps
In Bezug auf die
Oine-Fähigkeit ist zu beachten, dass dies nicht für jede
App Sinn macht. Wird die App permanent mit aktuellem Inhalt versorgt, wie
es z.B. bei einer Nachrichten-App der Fall ist, so macht eine oine-fähige App
wenig Sinn. Bei einem Spiel dagegen z.B. ist keine permanente Netzverbindung
notwendig, im Gegenteil, der User erwartet, dass die App auch dann funktioniert, wenn das Gerät oine ist. Die Oine-Fähigkeit von HTML5-Apps wurde
bereits in Kapitel 4.1.2 diskutiert, mit Web Storage können ca. 5 MB an Daten
auf dem Gerät gespeichert werden. Bei nativen Apps dagegen kann der gesamte
freie Speicher des Gerätes genutzt werden. Aktuell wurde festgestellt, das iOS
5 andere Oine-Inhalte löscht, falls nicht genügend freier Speicher vorhanden
ist.[Nico11, vgl.] Ist das Datenvolumen, welches auf dem Client für die OineFähigkeit gespeichert werden soll, groÿ, so empehlt sich eine native App. Bei
kleinem Datenvolumen sollte über eine HTML5-App nachgedacht werden. Allerdings ist Web Storage nur für die Speicherung von Zeichenketten geeignet, Objekte müssten zuerst mittels JSON kodiert und beim Auslesen dekodiert werden.
JSON ist die Abkürzung von JavaScript Object Notation und ein Datenformat,
welches überwiegend für den Austausch von Daten verwendet wird.
35/ 43
Benötigt die App einen
Zugri auf die Hardware des Clients, so ist ein-
deutig eine native App zum empfehlen. Der Zugri auf Hardware mittels HTML5
ist sehr eingeschränkt, es existiert z.B. eine Geolocation API, mit der die aktuelle
Position des Gerätes ausgelesen werden kann. Apple dagegen bietet APIs für den
Zugri auf z.B.GPS, 3D-, Push-, Hardware-Funktionen oder Grakbeschleunigung. Des Weiteren hat eine native App den Vorteil, dass der Zugri nicht über
eine dritte Komponente geschieht, wie es der Browser bei einer HTML5-App ist.
Des Weiteren sei noch kurz angemerkt, dass für HTML5-Apps Kenntnisse in
HTML5, JavaScript und CSS3, bei nativen Apps in Objective-C und CocoaAPI notwendig sind. Die HTML5-Kenntnisse haben den Vorteil, dass damit
plattformund geräteunabhängige Apps erstellt werden können.
Der Zugri erfolgt bei HTML5-Apps über den Webbrowser. Der User hat die
Möglichkeit, ein "Lesezeichen auf den Homescreen zu legen. Eine native App
dagegen erscheint nach der Installation sofort auf dem Homescreen.
Nicht immer, ist eine explizite Entscheidung für oder gegen eine native oder
HTML5-App notwendig: auch eine Kombination ist möglich. Es kann eine Oberäche mittels HTML5 erstellt werden, die dann in eine native App eingebettet
wird. Die native App kann dann gerätespezische Aspekte implementieren wie
z.B. den Zugri auf Hardware. Der HTML5-Teil kann bei dieser Methode dann
für eine App für ein anderes Betriebssystem wiederverwendet werden.
Des Weiteren sei an dieser Stelle kurz angemerkt, dass diverse Tools wie z.B.
Titanium von Appcelerator oder PhoneGap von Nitobi existieren, die weitestgehend automatisiert aus Webanwendungen native Apps erstellen. Diese nativen
Apps können dann über den App Store iTunes vertrieben werden - ohne Kenntnisse der Objective-C-Programmierung.
Im nächsten Kapitel werden diese Aussagen noch einmal zusammengefasst.
36/ 43
6 Fazit
In Kapitel 5 wurden die Vor- und Nachteile von nativen und HTML5-Apps
beispielhaft für das Betriebssystem iOS beleuchtet.
Generell spricht weitaus mehr für eine HTML5-App - insbesondere die Plattformund Geräteunabhängigkeit. Auÿerdem ist wohl zu erwarten, dass die Zukunft
noch mehr Features bieten wird. Für Anwendungen, die speziell an die Hardware angepasst und für diese optimiert werden müssen - wie es z.B. bei Spielen
häug der Fall ist - empehlt sich zur Zeit eine native App für das jeweilige
Betriebssystem.
7 Ausblick
Im Folgenden wird eine Einführung in die Problemstellung gegeben, welche
Grundlage der Bachelorarbeit der Verfasserin und mit Hilfe von HTML5 und
dem Framework jQuery Mobile bearbeitet werden soll.
Zur eindeutigen Identizierung eines Produktes werden häug Barcodes eingesetzt wie z.B. an Kassen in Supermärkten. Ein Barcode besteht aus mehreren
zueinander parallelen Strichen. Diese Striche beinhalten Daten und können von
Barcodescannern eingelesen werden. Abbildung 7.1 zeigt beispielhaft einen Barcode.
Abbildung 7.1: Barcode
Auch in einem Krankenhaus spielen Barcodes eine Rolle z.B. bei der Materialnachbestellung oder der Paketverfolgung. Die Bachelorarbeit der Verfasserin
soll sich mit der Entwicklung eines mobiles Softwaresystems befassen, welches
in der Lage sein wird, Barcodes zu verarbeiten und mit anderen erfassten Daten
an ein System zu senden, welches die erfassten Daten weiterverarbeitet. Dies soll
mit einer mittels HTML5 und jQuery Mobile entwickelten Webseite geschehen,
die auf einem mobilen Gerät aufgerufen wird. Das mobile Gerät wird mit einem
externen Bluetooth-Barcode-Scanner gekoppelt. Mit diesem werden die Barco-
7 Ausblick
des eingescannt, weitere Attribute werden eingegeben - z.B. eine Stückanzahl. Ist
das Gerät mit einem Netzwerk verbunden, können die Daten direkt versendet
werden. Ansonsten werden die Daten zunächst lokal gespeichert. Sämtliche gespeicherte Daten können dann gesendet werden, falls eine Netzwerkverbindung
besteht.
Abbildung 7.2: iPod gekoppelt mit Bluetooth-Barcodescanner
39/ 43
Quellen
[Appl11]
iOS - Cocoa Touch , http://developer.apple.com/technologies/ios/cocoatouch.html (Aufruf am 24.11.2011 13:03 Uhr)
[Bai11]
Giulio Bai: jQueryMobile First Look, Packt Publishing, 2011
[Bern89]
Tim
Berners-Lee:
Information
Management:A
http://www.w3.org/History/1989/proposal.html,
Proposal,
März
1989,
Mai 1990 (Afruf am 28. 11.2011 11:20)
[Davi12]
Matthew David: HTML5 Mobile Websites - Turbocharging HTML5
with jQuery Mobile, Sencha Touch, and Other Frameworks, Focal
Press, 2012
[Jobs10]
Steve
Jobs:
Thoughts
on
http://www.apple.com/hotnews/thoughts-on-ash/,
Flash,
April
2010
(Aufruf am 11.11.2011 08:23 Uhr)
[Lubk03]
Mark Lubkowitz: Galileo Computing - Websiten programmieren
und gestalten, 3. Auage Galileo Press GmbH, 2007
[Micr11]
IIS, http://www.iis.net/, 2011 (Aufruf am 17.11.2011 08:44 Uhr)
[Nico11]
nicolas: Aufgeräumt: iOS 5 löscht Oine-Inhalte ausgewählter
Apps auf eigene Faust, http://www.iphone-ticker.de/iphone-appsaufraumen-26485/, 14. Oktober 2011 (Aufruf am 15.12.2011 14:45)
[Pryj11]
Witold Pryjda: Apple verbannt den Entdecker einer iOS-Lücke,
http://winfuture.de/news,66475.html, 08. November 2011 (Aufruf
am 28.11.2011 14:45)
[Schw11]
Ben
Schwan:
Charlie
Miller
zeigt
Lücke
im
iOS-Codesigning,
http://www.heise.de/mac-and-i/meldung/Charlie-Miller-zeigt-
Luecke-im-iOS-Codesigning-1374906.html
,
08.
November
2011
(Aufruf am 28.11.2011 14:45)
[SpHa11]
Markus Spiering, Sven Haiges: HTML5-Apps für iPhone und Android, 2. Auage Franzis Verlag GmbH, 2011
[Tw10]
tw:
HTML5:
Videos
einbinden,
http://tutorials.magbiz.net/programmierung/htmlprogrammierung/html5-videos-einbinden/, 23. Mai 2010 (Aufruf
am 21.11.2011 10:05 Uhr)
[Wino11]
Danny Winokur: Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5,
http://blogs.adobe.com/conversations/2011/11/ash-focus.html,
09.11.2011 5:59 (Aufruf am 11.11.2011 07:45 Uhr)
[W3C11]
W3C: Web Storage, http://dev.w3.org/html5/webstorage/,28.11.2011
(Aufruf am 14.12.2011 15:29 Uhr)
Allgemeine Literatur
[BaRiSc03]
Anatol
Badach,
Sebastian
Rieger,
Matthias
Schmauch:
Web-
Technologien Architekturen, Konzepte, Trends, Carl Hanser Verlag, 2003
[BoCeHiLi11] Bert
Bos,
Tantek
Çelik,Ian
Hickson,Håkon
Wium
Lie:
Cas-
cading Style Sheets Level 2 Revision 1 (CSS 2.1) Specication, http://www.w3.org/TR/CSS2/, 07. Juni 2011 (Aufruf am
17.11.2011 09:12 Uhr)
[Erle07]
Helmut Erlenkötter: HTML - Von der Baustelle bis JavaScript,
5.Auage Rowohlt Taschenbuch Verlag, 2007
[LaSh11]
Bruce Lawson, Remy Sharp : HTML5: Eine Einführung für Umsteiger, Addison-Wesley, München, 1. Auage, 29. Juni 2011
[Micro11]
Einführung
zu
DOM-Storage,
http://msdn.microsoft.com/de-
de/library/cc197062%28v=vs.85%29.aspx,
2011
(Aufruf
am
30.11.2011 09:03)
[OeHoSe10]
Florian
Oelmaier,
Jochen
Hörtreiter,
Andreas
Seitz:
Apple's
41/ 43
iPad im Enterprise-Einsatz: Einsatzmöglichkeiten, Programmierung, Betrieb und Sicherheit im Unternehmen, 1.Auage Springer
Berlin Heidelberg, 16. Dezember 2010
[Pilg10]
Mark Pilgrim: HTML5: Up & Running,1. Auage O'Reilly Media,
20. September 2010
[Roth05]
Jörg Roth: Mobile Computing - Grundlagen, Technik, Konzepte,
2. Auage dpunkt.verlag, 2005
[Stein11]
Ingo Steinhaus: Das Kräftemessen hat gerade begonnen - In: Mobile
Business, 2011, H. 10, S. 26.
[Tolk97]
Robert Tolksdorf: Die Sprache des Web: HTML 4, 3. Auage
dpunkt.verlag, 1997
42/ 43
Hilfsmittel
•
TexMakerX 2.1
•
MiKTeX 2.9
•
Microsoft Visio 2010
•
Notepad++

HTML5 und das Framework jQuery Mobile

Transcription

Similar documents

Spionage via Webcam: Welchen Schutz bieten Personal Firewalls

Full paper - Fachbereich Informatik

ckendes CV: Das verbindet diese erfolgreichen Frau

Mobile Hattrick - Distributed Computing Group