HTML5 und das Framework jquery Mobile

Transkript

1 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 Betreuer: Prof. Ulrich Stegelmann 2. Betreuer: Dipl.-Inform. Axel Blum Aachen, den

2 ,

3 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.

4 Inhaltsverzeichnis Eidesstattliche Erklärung 2 Vorwort 3 Inhaltsverzeichnis 5 Abbildungsverzeichnis 6 Tabellenverzeichnis 7 1 Einleitung 8 2 Grundlagen der Webprogrammierung TCP/IP Das HTTP-Protokoll Webserver Was ist HTML? JavaScript CSS Softwareentwicklung für mobile Endgeräte 17 4 HTML5, CSS3 und JavaScript-APIs Vergleich zu HTML Neuerungen Webapplikationen oine nutzen Video Browserunterstützung JavaScript-APIs Das JavaScript Framework jquery Mobile Einführung Design Features Appentwicklung für das Apple-Betriebssystem ios Native Apps

5 Inhaltsverzeichnis 5.2 Vergleich von Webapps mit nativen Apps Fazit 37 7 Ausblick 38 Literatur- und Quellenverzeichnis 40 Hilfsmittel 43 5/ 43

6 Abbildungsverzeichnis 2.1 Die vier Schichten von TCP/IP Aufruf: Beispiel HTML-Dokument HTML5 & CSS3 Support, (Aufruf am um 13:00 Uhr) vgl. jquery Mobile Supported Platforms, und in Anlehnung an: Original Graded Browser Matrix, beide: 2010 (Aufruf am um 13:00 Uhr) Beispiel HTML-Dokument Beispiel HTML-Dokument mit jquery Mobile Beispiel HTML-Dokument ohne jquery Mobile Barcode ipod gekoppelt mit Bluetooth-Barcodescanner

7 Tabellenverzeichnis 3.1 Vergleich: mobile Endgeräte vs. Desktop PCs [Davi12, vgl. S.7f.] Vergleich von HTML5-Apps mit nativen Apps

8 1 Einleitung Smartphones und mit ihnen die mobilen Applikationen sind auf dem Vormarsch. 1 Dabei ist Smartphone nicht gleich Smartphone: es werden die unterschiedlichsten 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. 2 SDK ist die Abkürzung von Software Development Kit. Sie bietet verschiedene Werkzeuge an, die z.b. von Softwareentwicklern benutzt werden können.

9 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] Doch was ist HTML5? Was kann es? Inwieweit können mit HTML5, CSS 3 und JavaScript 4 funktionsfähige Webanwendungen erstellt werden? Und welche weitere Funktionalitäten bringen kostenlose Frameworks wie z.b. jquery Mobile 5 mit sich? 3 Mittels Cascading Style Sheets können Layoutvorlagen erstellt werden 4 Eine Skriptsprache 5 9/ 43

10 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

11 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 Transport Control Protocol, IP ist die Abkürzung für Internet Protocol. IP- und TCP-Implementierungen sind Bestandteile 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 s 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-

12 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

13 2 Grundlagen der Webprogrammierung 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: 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

14 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 Hypertext 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 HTTP- Protokoll 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 HTML- Dokuments: 1 <!DOCTYPE html> 2 <head> 3 < t i t l e>dies i s t ein T i t e l</ t i t l e> 4 </ head> 5 <body> 6 <h2>dies i s t eine U e b e r s c h r i f t 2. Ordnung</ h2> 14/ 43

15 2 Grundlagen der Webprogrammierung 7 <a h r e f=" b e i s p i e l 1. html "> Dies i s t ein Link auf mich s e l b s t</ a> 8 <! Dies i s t e i n Kommentar > 9 </ body> 10 </ html> 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 D.h. das Skript wird vom Browser des Users ausgeführt und nicht auf dem Webserver 3 Ein Beispiel für serverseitigen Einsatz von JavaScript ist ASP.NET, mit welchem Webanwendungen - auf dem.net-framework aufbauend - erstellt werden. 15/ 43

16 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 Zusammenhang 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 wurde im Jahre 1996 veröentlicht. Die aktuelle Version ist CSS / 43

17 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 Pixel zwischen 240x400 und 800x480 Pixel Orientierung Querformat Portrait und Landscape Bedienung Maus und Tastatur Hand Netzwerkverbindung meist LAN WLAN oder UMTS Rechenleistung Gröÿenordnung GFLOPS 1 Gröÿenordnung 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

18 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 Desktop- PC 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

19 4 HTML5, CSS3 und JavaScript-APIs 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 Vergleich zu HTML Neuerungen HTML5 deniert neue Elemente und Attribute 3. 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 2 Die genaue Spezikation von HTML 4.01 nden Sie unter 3 Die HTML5-Spezikation nden Sie unter

20 4.1 Vergleich zu HTML 4 Funktionen bereit, die ein Softwareentwickler benutzen kann, wenn er die API in seine Software einbindet. Im folgenden Unterkapitel wird beispielhaft auf einige Aspekte eingegangen 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 dem Client zur Verfügung. In einem Cookie 4 können maximal 4096 Byte gespeichert 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

21 4 HTML5, CSS3 und JavaScript-APIs 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 beeinussen können, was z.b. bei Cookies 5 durchaus möglich ist. 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 Storage- Event 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: 21/ 43

22 4.1 Vergleich zu HTML 4 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 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 Video- Codec, 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 Ogg- Container. 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

23 4 HTML5, CSS3 und JavaScript-APIs 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 Browserunterstützung Wie schon oben erwähnt, wird nicht von jedem Browser jeder Teil der HTML5- Spezikation unterstützt. Abbildung 4.1 gibt einen Überblick über die Unterstützung von HTML5-Webanwendungen durch verschiedene Browser. Abbildung 4.1: HTML5 & CSS3 Support, (Aufruf am um 13:00 Uhr) 23/ 43

24 4.2 JavaScript-APIs Die Abbildung lässt erkennen, dass der Browser, der auf einem Windows- Betriebssystem z.z. die gröÿtmöglichste Unterstützung für HTML5-Webanwendungen bietet, der Safari 5 ist JavaScript-APIs Mit HTML5 sind einige neue - über JavaScript zugängliche - APIs entwickelt worden. Die Web Storage-API wurde bereits im Kapitel 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 erwähnte Web Storage API. 6 Einen Überblick über Features des Safari-Browsers nden Sie unter 24/ 43

25 4 HTML5, CSS3 und JavaScript-APIs 4.3 Das JavaScript Framework jquery Mobile Einführung jquery Mobile ist ein auf JavaScript basiertes Framework. Es ist eine Weiterentwicklung der Bibliothek jquery 7 : 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 25/ 43

26 4.3 Das JavaScript Framework jquery Mobile Abbildung 4.2: vgl. jquery Mobile Supported Platforms, und in Anlehnung an: Original Graded Browser Matrix, beide: 2010 (Aufruf am 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 : / / code. j q u e r y. com/ m o b i l e / 1. 0 / j q u e r y. mobile min. c s s " /> 2 < s c r i p t s r c=" h t t p : / / code. j q u e r y. com/ j q u e r y min. j s "></ s c r i p t> 3 < s c r i p t s r c=" h t t p : / / code. j q u e r y. com/ m o b i l e / 1. 0 / j q u e r y. mobile 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 heruntergeladen und auf einem eigenen Webserver gehostet werden. 26/ 43

27 4 HTML5, CSS3 und JavaScript-APIs 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 CSS- Datei 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 html> 2 <head> 3 < t i t l e>b e i s p i e l 2</ t i t l e> 4 < 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 : / / code. j q u e r y. com/ m o b i l e / 1. 0 / j q u e r y. mobile min. c s s " /> 5 < s c r i p t s r c=" h t t p : / / code. j q u e r y. com/ j q u e r y min. j s "></ s c r i p t> 6 < s c r i p t s r c=" h t t p : / / code. j q u e r y. com/ m o b i l e 7 </ head> 8 <body> / 1. 0 / j q u e r y. mobile min. j s "></ s c r i p t> 9 <a h r e f=" i n d e x. html " data r o l e=" button " data theme=" a " >Theme a</ a> 10 <a h r e f=" i n d e x. html " data r o l e=" button " data theme="b" >Theme b</ a> 11 <a h r e f=" i n d e x. html " data r o l e=" button " data theme=" c " >Theme c</ a> 12 <a h r e f=" i n d e x. html " data r o l e=" button " data theme="d" >Theme d</ a> 13 <a h r e f=" i n d e x. html " data r o l e=" button " data theme=" e " >Theme e</ a> 14 </ body> 15 </ html> Abbildung 4.3 zeigt das Ergebnis. 27/ 43

28 4.3 Das JavaScript Framework jquery Mobile Abbildung 4.3: beispiel2.html Wie das Design von jquery Mobile aussieht, kann unter 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 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

29 4 HTML5, CSS3 und JavaScript-APIs Folgender Source-Code wird für den Inhalt einer HTML-Seite benutzt: 1 <body> 2 <d i v data r o l e=" page "> 3 <d i v data r o l e=" h e a d e r ">Header</ d i v> 4 <d i v data r o l e=" c o n t e n t ">Content</ d i v> 5 <d i v data r o l e=" f o o t e r ">Footer</ d i v> 6 </ d i v> 7 </ body> 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. Abbildung 4.4: beispiel3.html mit jquery Mobile Abbildung 4.5: beispiel3.html ohne jquery Mobile Des Weiteren ist es mit jquery Mobile möglich, mehrere Seiten in einer HTML- Datei 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

30 4.3 Das JavaScript Framework jquery Mobile 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 ein- ussreich. 30/ 43

31 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 wiederum auf Unix basiert. Die neueste Version von ios ist ios 5 1. 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 in der Version 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 Mehr Infos zu ios 5 unter 2 Sie ist nach kostenloser Registrierung als Apple-Developer unter downloadbar.

32 5.2 Vergleich von Webapps mit nativen Apps 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 rmeninternen App, bei der der Nutzerkreis klar deniert 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

33 5 Appentwicklung für das Apple-Betriebssystem ios Das letzte Szenario ist eine weltweite App für eine oene Benutzergruppe. 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 plattform- und 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

34 5.2 Vergleich von Webapps mit nativen Apps 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

35 5 Appentwicklung für das Apple-Betriebssystem ios 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 JavaScript, HTML5, CSS3 Objective-C, Cocoa-API Wiederverwendbarkeit möglich eingeschränkt möglich von Code und Logik Zugri über Webbrowser automatisch auf Homescreen sichtbar Setzen eines "Lesezeichens auf den Homescreen möglich Plattform- und geräteunabhängig ja nein 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 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 Oine- Fä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

36 5.2 Vergleich von Webapps mit nativen Apps Benötigt die App einen Zugri auf die Hardware des Clients, so ist eindeutig 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 Cocoa- API notwendig sind. Die HTML5-Kenntnisse haben den Vorteil, dass damit plattform- und 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

37 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.

38 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-