Eberhart mobilewebapp.docx 1

Mobile Webapplikation

Auch wenn es mobile Apps bereits seit den 1990er Jahren gibt, liegt der Beginn nicht so weit

zurück. Am 10. Juli 2008 begann der weltweite Siegeszug mobiler Apps durch die Eröffnung

des Apple App Store. Seit diesem Tag können iPhone- und iPod-Benutzer mobile Apps für ihr

mobiles Endgerät von einer zentralen Stelle laden. Gleich am ersten Wochenende nach der

Eröffnung wurden mehr als 10 Millionen mobile Apps daraus heruntergeladen.

Ausgestattet mit einem exzellenten App-Konzept konnten viele spannende Anwendungen

und Funktionalitäten einfach nachgerüstet werden. Das Konzept des App Store begann sich

zu etablieren. Zwei Jahre später drängten dann die Android-basierten Smartphones auf den

Markt, einhergehend mit einer großen Vielfalt an unterschiedlichen Geräten und

Displaygrößen, die heute abgerundet werden von einem Angebot an Tablet-PCs, ebenfalls

mit sehr unterschiedlichen Auflösungen und Formfaktoren.

Seitdem sind mobile Apps für die aktuell marktführenden mobilen Betriebssysteme Android

und iOS allgegenwärtig.

Diese Situation macht die Erstellung von nativen Apps mit einer breiten

Plattformunterstützung sehr aufwändig, da Code nicht einfach wiederverwendet werden

kann. Jede Plattform bringt ihre eigenen Sprachen, Entwicklungswerkzeuge und Eigenarten

mit. Hat man aber eine größere Gerätevielfalt abzudecken, kommt schnell der Wunsch nach

einer Cross-Plattform-Technologie auf, um eine App nur einmal entwickeln und dann mit

keinen oder nur minimalen Anpassungen überall verwenden zu können. Hierzu bieten sich

natürlich die Browser an und das mittlerweile allgegenwärtige HTML5, das antritt, das Cross-

Plattform-Versprechen einzulösen.

Eine App für alle Plattformen – das ist das Ziel. Aber wie geht das? Eine Lösung sind »Web-

Apps«, mobile Anwendungen, die auf HTML5 und JavaScript basieren.

Eberhart mobilewebapp.docx 2

Unterscheidungen:

1. Web-Apps

Eine Web-App ist eine Web-Applikation, die vom Aussehen her wie eine native Applikation aus den Stores daherkommt und vollständig auf dem mobilen Gerät bzw. Device läuft. Sie funktioniert meist auch ohne Internetverbindung und speichert Daten unter Umständen lokal. Die Hauptverarbeitung läuft auf dem Client und nicht auf dem Server! Mit HTML5 und dessen APIs hat der Entwickler viele Möglichkeiten, auf das Device zuzugreifen – aber nicht dieselben wie bei einer nativen App. So fehlt z.B. der Zugriff auf das Adressbuch. Der Vorteil ist, dass mithilfe einer Web-App viele Plattformen erreicht werden können. Für viele Unternehmen ist auch die vereinfachte Distribution ein Argument. Eine optimierte Benutzeroberfläche für die Finger-Bedienung ist jedoch Pflicht.

2. Native Apps

Dabei wird eine mobile App exakt auf ein konkretes Betriebssystem wie z.B. iOS oder

Android zugeschnitten und entwickelt. Das bedeutet, dass der Programmcode nicht 1:1 für

eine andere Plattform verwendet werden kann. Meist sind weitreichende Anpassungen oder

sogar eine komplette Neuprogrammierung erforderlich, die nicht nur viel Zeit beansprucht,

sondern auch verschiedene Experten benötigt.

Will man in den Stores wie bei Android und Apple die App anbieten ist dies schon aufwendig.

Apple z.B. verlangt eine Jahresgebühr für das Entwicklerprogramm usw. Dazu kommt, dass

z.B. Apple selbst entscheidet, ob die App zugelassen wird.

Eine App wird in einer Hochsprache geschrieben und wird dann in Maschinensprachencode kompiliert. Unter iOS ist die verwendete Hochsprache Objective-C, unter Android und Blackberry ist es Java (mit unterschiedlichen Bibliotheken und Konzepten). Diese Apps haben den vollen Zugriff auf das API der Betriebssystemhersteller.

Vorteile nativer Apps:

Hohe Performance

Zugriffsmöglichkeit auf die Hardware eines Gerätes (z.B. Kamera, Mikrofon)

Der Nachteil ist, dass diese Apps für jede Plattform fast komplett neu entwickelt respektive portiert werden müssen. Auf die unterschiedlichen Bedienungskonzepte muss unbedingt eingegangen werden, damit die Benutzer die Software annehmen bzw. kaufen.

3. Hybrid-Apps oder Container-App

Um die Vorteile der Web-Apps mit den Vorteilen der nativen Apps zu kombinieren, kann eine Web-App in einem Container (WebView) einer nativen App ablaufen und können über Plugins auf native Funktionen und Komponenten des mobilen Endgerätes zugreifen. Das bedeutet, dass die App wie eine native App daherkommt, im Inneren aber weiterhin eine HTML5-App ist. Mit den erwähnten Plugins (= zusätzlichen Java-Script-APIs) hat der

Eberhart mobilewebapp.docx 3

Entwickler trotzdem den kompletten Zugriff auf die nativen Möglichkeiten der Devices – wobei gewisse proprietäre Aspekte in Kauf genommen werden. Dabei wird die App zunächst betriebssystemunabhängig entwickelt. Anschließend wird sie mit nativen Funktionen kombiniert und erweitert, um gerätespezifische Eigenschaften wie z.B. Sensoren und Kamera oder die Kontakte nutzen zu können. Sie können über einen App Store veröffentlicht und installiert werden, ohne dass mehrere parallele Entwicklungsstränge existieren müssen.

4. Cross-kompilierte mobile App

Die Grundidee ist es, native mobile Apps für die unterschiedlichen mobilen Betriebssysteme

auf Grundlage EINER Quellcodebasis zu generieren. Dazu werden Cross-Compiler eingesetzt,

die den Quellcode ohne weitere Zwischenschicht für unterschiedliche Betriebssysteme

cross-kompilieren, sodass eine native mobile App entsteht. Entwicklungswerkzeuge dafür

sind Xamarin (iOS), React Native und Apache Cordova mit Ionic.

Eberhart mobilewebapp.docx 4

Web-App

Das sind mobile Webanwendungen, die in der Regel auf Basis von HTML5, CSS und

JavaScript entwickelt werden. Diese Web-Apps laufen vollständig in einem Webbrowser wie

z.B. Safari für iOS oder Google Chrome für Android bzw. in einer bildschirmfüllenden Web-

View und somit auf beliebigen mobilen Endgeräten. Dadurch ist eine Ausrichtung auf ein

bestimmtes Endgerät nicht zwingend notwendig. Man schreibt den Code ein einziges Mal

und er funktioniert auf sämtlichen Endgeräten. Der gemeinsame Nenner ist stets HTML5.

Größter Vorteil ist die Plattform übergreifende Nutzbarkeit.

Vorteile: reine Web-Apps werden in der Regel nicht über einen App Store

vertrieben. Zudem können sie ohne Installation genutzt werden.

Nachteile: Es sollte eine möglichst breitbandige Netzverbindung bestehen. Meist

sind sie nicht in der Lage auf sämtliche Hardwarekomponenten eines mobilen

Endgerätes zuzugreifen. Da sie nicht über einen App Store angeboten werden,

unterliegen sie auch nicht der hierbei durchgeführten Qualitätskontrolle.

Was unterscheidet mobile Web-Apps aber von mobilen Webseiten? Diese Frage ist schwerer zu beantworten. Es gibt auch Stimmen, die sagen, man müsse die beiden nicht voneinander abgrenzen. Besuchern sei es egal, ob sie eine Web-App nutzen oder eine Webseite besuchen. Aber für Entwickler ist es doch wichtig, sich die Unterschiede zwischen beiden klarzumachen. Mobile Web-Apps beruhen wie mobile Webseiten auf Webtechniken. Optisch erinnern sie aber an native Apps und sie zeichnen sich außerdem durch den intensiven Gebrauch von JavaScript und JavaScript-APIs aus. Zur Abgrenzung von mobiler Web-App gegenüber mobiler Webseite werden verschiedene Kriterien herangezogen:

1)Optik – Look & Feel Eine mobile Web-App vermittelt eine App-like Erfahrung. Das heißt, dass sie vom Benutzer ähnlich wie eine native App wahrgenommen wird. Typisch ist also für Web-Apps ein bestimmtes Aussehen. Üblicherweise orientieren sich Web-Apps optisch mehr an den nativen Apps als an der Desktop-Seite. Typisch sind folgende Komponenten (im Unterschied zu mobilen Webseiten):

Fixierte Toolbar oben, eine Reihe von Buttons unten.

Animierte Seitenübergänge bei der Navigation zwischen den verschiedenen Bereichen.

Typisch sind auch Elemente wie ActionSheet, das sind Meldungsfenster, die mit zusätzlichen Optionen von unten auf dem Bildschirm erscheinen, oder Ladeanzeiger.

Eberhart mobilewebapp.docx 5

2)Funktionalität Webseiten besucht man, Web-Apps nutzt man. Die Interaktion bei Webseiten ist Lesen, bei Web-Apps ist es mehr. Es gibt natürlich Ausnahmen von diesem Prinzip und im Allgemeinen geht die Tendenz im Web immer mehr in Richtung „Anwendungen“ und weg von den „reinen Webseiten“ (nicht zufällig dient HTML5 der Erstellung von Anwendungen). Deswegen hilft das Kriterium der besonderen Funktionalität bei Web-Apps, kann aber nicht zur eindeutigen Abgrenzung dienen.

3)Architektur Beim klassischen Web ist der Browser ein Thin Client, und der Webserver erledigt die Hauptarbeit. Bei Web-Apps haben wir es hingegen mit einem Fat Client zu tun, Hier macht der Browser wesentlich mehr; involviert sind Techniken wie AppCache, mit der die Webanwendung offline-fähig wird, WebStorage zur Datenspeicherung und vieles mehr – es wird also das daraus, was man treffend als Rich Internet Application bezeichnet.

4)Reichweite Apps laufen auf einer begrenzten Anzahl an Geräten, weil sie bestimmte Techniken voraussetzen. Eine Webseite kann nicht so viel leisten, weil sie für möglichst viele funktionieren muss.

Warum JavaScript?

JavaScript erlebt gerade einen regelrechten Aufschwung. In der Vergangenheit wurde die

Sprache etwas belächelt, weil sie im Wesentlichen zum „Aufhübschen“ von Webseiten

verwendet, aber nicht als „echte“ Sprache für professionelle Anwendungsentwicklung

gesehen wurde. Mit der enormen Ausbreitungsgeschwindigkeit von HTML5 dreht sich dieser

Trend: JavaScript ist auf dem Weg, sich als Sprache zur Anwendungsentwicklung und

Oberflächenprogrammierung zu etablieren.

Single Page Web-Apps

Eine spezielle Ausprägung sind „Single Page Apps“.

Eine Single Page App (SPA) ist eine Clientanwendung, die in JavaScript realisiert wird und im

Browser abläuft. Das Konzept verdankt seinen Namen der Tatsache, dass eine solche

Anwendung nur eine einzige HTML-Seite benötigt, nämlich die, über die der JavaScript-Code

in den Browser geladen wird. Die Anwendung nutzt Ajax-Mechanismen, um mit dem Server

zu kommunizieren.

Der Ansatz ist aktuell sehr populär, weil sich damit Anwendungen realisieren lassen, die zum

einen für den Benutzer auf den ersten Blick sehr ergonomisch sind, zum anderen bewährte

und bekannte Muster für die Entwicklung unterstützen. Bekannte Vertreter des Ansatzes

sind unter anderem die JavaScript-Frameworks „AngularJS“ und „Ember“.

Eberhart mobilewebapp.docx 6

(Quelle: Tilkov in: Rest und http, 2015, dpunkt-Verlag, Heidelberg, S. 264)

Bei Web-Apps wird der Client intelligenter, da man nicht alles auf den Server verlagert.

Bei Single Page Web-Apps wird beim Laden einer HTML-Seite gleich die ganze Web-App

geladen. Das ist eine einzige HTML-Seite, von der aber nur ein Teil angezeigt wird.

Im Ergebnis handelt es sich bei Single Page Web-Apps also mehr um Clientapplikationen im

Sinne der Client-Server-Programmierung als um Webapplikationen im Sinne von serverseitig

generierten Webseiten. Mobile Webapplikationen, die auf diese Weise entwickelt wurden,

integrieren sich hervorragend in Gesamtarchitekturen, bei denen das Backend über ein

RESTful API angesprochen werden kann. Optimal für das Zusammenspiel ist eine

Kommunikation auf Basis der JavaScript Object Notation (JSON). Weitere Vorteile dieser

Applikationsarchitektur sind die potenziellen Offlinefähigkeit der Clients und die Möglichkeit,

diese Applikationen mit Werkzeugen wie beispielsweise PhoneGap in native Applikationen

zu „verpacken“, die dann einerseits vollen Zugriff auf die Hardwarefunktionalitäten der

Ausführungsumgebung haben, als auch wie native Apps durch die entsprechenden

Distributionskanäle der Plattformen („App Stores“) verteilt werden können.

Oberflächenkomponenten

Eine Herausforderung bei der Implementierung einer mobilen Webapplikation ist die Bereitstellung einer gut aussehenden und intuitiv benutzbaren Oberfläche, die insbesondere die Besonderheiten mobiler Endgeräte berücksichtigt. Diese sind unter anderem die zur Verfügung stehende Bildschirmgröße und die Bedienung über Touch-Displays. Durch native Bedienkonzepte der mobilen Plattformen haben sich darüber hinaus Gestaltungsnormen etabliert, die von Desktopwebapplikationen abweichen und in einer mobilen Webapplikation adäquat adaptiert werden müssen. Dazu zählen beispielsweise:

Die Verwendung von Gesten zur Bedienung der Applikation.

Eine Aufteilung einer Seite der Applikation in „Header“, „Content“ und „Footer“.

Die Verteilung der Benutzeroberfläche auf gegebenenfalls viele kleine Seiten in Verbindung mit einer einfachen Navigation zwischen diesen Seiten. Hierfür kommen beispielsweise „Back Buttons“ im Header oder „Tab Bars“ im Footer einer Seite zum Einsatz.

Bedienelemente, die für eine Benutzung mit den Fingern gestaltet sind.

Sich einblendende Bedienelemente wie beispielsweise eine virtuelle Tastatur oder ein „Date Picker“, die dabei Bereiche der Benutzeroberfläche überdecken.

Der Einsatz von Animationen für eine ergonomische Visualisierung von Veränderungen der Benutzeroberfläche, beispielsweise beim Einblenden neuer Dialogelemente oder bei Wechseln von Seiten.

Aufgrund der geringen zur Verfügung stehenden Bildschirmgröße besteht darüber hinaus häufig der Wunsch, die Bedienelemente des Browsers, in dem die Webapplikation ausgeführt wird, so weit wie möglich auszublenden.

Eberhart mobilewebapp.docx 7

Beispiel für Eingabeelemente, die fürs das Handy optimal sind: Als Eingabeelemente für Ja/Nein-Entscheidungen haben sich Flip Toggle Switches bewährt. Diese Elemente stellen einen Schalter dar, der zwischen zwei Zuständen hin- und hergekippt werden kann. Checkboxen und Radiobuttons sind bei mehreren Auswahlmöglichkeiten geeignet. Sliders für die Werteingabe eignen sich nur, wenn der Bereich klein ist, sonst wird das Feingefühl des Benutzers überstrapaziert.

Von oben nach unten: Flip Toggle Switch, Checkboxen, Radiobuttons und Slider als fingertaugliche Eingabeelemente

Worauf man achten sollte, wenn man Web-Apps erstellt:

Organisation der Inhalte: Da wenig Platz zur Verfügung steht muss man trotzdem Details und Übersicht unter einen Hut bringen. Hilfreich sind dabei ein-/ausklappbare Listen oder Filterfunktionen. Smartphones verkleinern standardmäßig Webseiten. Bei speziellen auf mobile Geräte verbesserten Webseiten wird man die Skalierung abschalten, muss als Programmierer aber Lösungen finden, wie sich genügend Details anzeigen lassen, ohne dass der Überblick verloren geht. Kopfbereich und Navigation sollten nicht zu viel Platz einnehmen, sodass der eigentliche Inhalt direkt ohne Scrollen zu sehen ist. Praktisch sind hier ausklappbare Navigationen.

Input vom Benutzer: Für den Benutzer von Smartphones ist es wesentlich mühseliger, Texte einzugeben, als bei einem Notebook mit einer richtigen Tastatur. Deswegen sollte man den Benutzer dabei unterstützen, wo es geht.

o Eine Option aus einer Auswahlliste zu wählen, ist einfacher, als selbst etwas einzugeben. Wo immer angebracht, sind Auswahllisten, Checkboxen oder Radiobuttons gegenüber freien Textfelder vorzuziehen.

Eberhart mobilewebapp.docx 8

o Durch die richtigen Formulartypen kann man bewirken, dass gleich die passende Tastatur eingeblendet wird.

o Bei Suchfeldern sind Vorschlagslisten über Ajax praktisch, aus denen man wählen kann.

o Formulare sollte man wo möglich vereinfachen und den Benutzer nur nach den wirklich benötigten Dingen fragen.

o Komplexere Formulare teilt man besser auf mehrere Seiten auf.

Navigation über Listen ist einfacher, als etwas einzutippen.

Richtige Tastatur Dank den Formular-Input-Feldern in HTML5 wird bei Smartphones automatisch die richtige Tastatur ausgewählt. Es wäre sehr unangenehm, wenn man bei der Eingabe einer E-Mail Adresse erst umständlich nach dem @-Zeichen suchen müsste. Besser ist es, wenn die richtige Tastatur vorgeschlagen wird. Beispiel:

o E-Mail: <input type=“email“ name=“mailadresse“ id=“mailadresse“ />

o URL: < input type=“url“ name=“webadresse“ id=“webadresse“ />

Eberhart mobilewebapp.docx 9

o Telefon: <input type=“tel“ name=“telefonnummer“ id=“telnummer“ />

o Datum: <input type=“date“ name=“datum“ id=“datum“ />

Eberhart mobilewebapp.docx 10

Performance optimieren

HTTP-Requests reduzieren & optimieren Die wichtigste Methode für eine bessere Performance ist es, die HTTP-Requests zu reduzieren. Prinzipiell funktioniert der Download der Komponenten von Webseiten folgendermaßen: Der Browser fordert die Seite an und findet darin die Verweise auf externe Dateien – das können Bilder sein, Stylesheets, JavaScript-Dateien oder weitere. Der Browser fordert diese externen Ressourcen dann in der Reihenfolge an, wie sie im Quellcode stehen. Nehmen wir zum Beispiel folgenden Ausschnitt aus einem HTML-Dokument. <head> <link rel="stylesheet" href="stil.css" /> <script src="functions.js"></script> </head> <body> <img src="bild.jpg" /> </body>

Um dieses Beispiel darzustellen, fordert der Browser vier Ressourcen an, und zwar in dieser Reihenfolge:

1. HTML-Dokument 2. stil.css 3. functions.js 4. bild.jpg

Entscheidend für die Performance-Optimierung ist es, die Anzahl an HTTP-Request zu reduzieren und die Datenmenge möglichst gering zu halten. Mehrere Anfragen können parallel ablaufen; allerdings gibt es auch blockende Anfragen, d. h., bis die entsprechende Ressource heruntergeladen ist, werden keine anderen Ressourcen angefordert. Deshalb spielt auch die Reihenfolge, in der die Ressourcen aufgeführt sind, eine Rolle. Gleichzeitig ist es auch wichtig, dass man nicht ein Stylesheet mit vielen Regeln hat, die auf der aktuellen Seite nicht benötigt werden. Formatierungen, die wirklich nur auf einzelnen Seiten vorkommen, sollte man deshalb in einem separaten Stylesheet lassen. Was für CSS-Dateien gilt, gilt auch für JavaScript-Dateien: Wenn man mehrere JavaScript-Dateien hat, sollte man diese zusammenfassen. JavaScript-Code, der nicht zu Beginn benötigt wird, sollte man ans Ende stellen, d. h. vor </body>. Meistens benötigt man externe CSS- und JavaScript-Dateien, dann ist es wichtig, dass diese in der richtigen Reihenfolge angegeben sind. Die Regel lautet: zuerst die CSS-Dateien, danach die JavaScript-Dateien.

Eberhart mobilewebapp.docx 11

Besonderheiten bei mobilen Geräten

Mobile Geräte sind ein Spezialfall.

Das liegt daran, dass sie weniger leistungsfähiger sind, d. h., von CPU und Arbeitsspeicher her sind sie eher auf dem Stand von Desktop-Rechnern vor vielen Jahren. Nur die Grafik ist besser.

Mobile Geräte laufen mit Akku und werden nicht wie Desktop-Geräte ständig mit Strom versorgt. Deswegen muss eine Seite ressourcenschonend sein. Dafür empfiehlt es sich, JavaScript bewusst einzusetzen – also nur da, wo es notwendig ist, Bilder nicht vom Browser skalieren zu lassen und Dinge zu vermeiden, die dazu führen, dass die Seite neu gezeichnet/formatiert/dargestellt werden muss.

Bei mobilen Geräten ist die Latenz größer, d. h. etwa die Wartezeit, bis mit dem Herunterladen von Ressourcen begonnen werden kann. Deswegen gilt es beispielsweise auch, unnötige Redirects zu vermeiden.

Gesten: Ein mobiles Endgerät wird über ein Multitouch-Display bedient. Dafür sind

zahlreiche Gesten verfügbar, die oftmals intuitiv einsetzbar sind.

o Touch: der Touchscreen wird mit einem Finger kurz berührt.

o Swipe: Der Finger wird über den Touchscreen bewegt.

o Tap: Mit einem Finger wird einmal kurz auf den Touchscreen getippt.

o Rotate: Zwei Finger berühren den Touchscreen und es wird eine Drehung mit

den Fingern vorgenommen.

Daher sollten:

HTML-Seiten sollten 25,6 Kilobyte oder kleiner sein.

CSS- und JavaScript-Dateien sollten unter 1 Megabyte groß sein. Normalerweise sollte man natürlich wesentlich kleinere Dateien benutzen. Aber bis zu einer Größe von 1 Megabyte lohnt es sich, mehrere Dateien zusammenzufassen, um HTTP-Requests zu sparen.

Entwicklungsumgebungen

Eclipse

Microsoft Visualstudio

Aptana Studio

Adobe Dreamweaver (unterstützt jQuery Mobile ab der Version 5.5)

IntelliJ IDEA von der Firma JetBrains

Eberhart mobilewebapp.docx 12

Beispiele für Komponentenbibliotheken

jQuery Mobile hat sich zum Ziel gesetzt, eine möglichst große Zahl mobiler

Plattformen und Browser zu unterstützen. Es ist ein sogenanntes Web-Framework,

das ein Grundgerüst für die Entwicklung mobiler Web-Applikationen zur Verfügung

stellt. Es basiert auf den Technologien HTML5, CSS3 und JavaScript bzw. Ajax. Es ist

natürlich auch möglich ohne jQuery manuell Web-Apps zu entwickeln, was aber

einen größeren Aufwand erfordert.

Demoseiten findet man unter http://jquerymobie.com/demos

Meist werden die mobilen Websites über eine Subdomain „m“ aufgerufen, statt über

„www“. Weitere Sites: m.ikea.com, m.stanford.edu, m.disneyworld.disney.go.com.

Sencha Touch konzentriert sich bewusst auf WebKit-basierte Browser und

unterstützt zurzeit „nur“ ausreichend aktuelle Versionen von iOS, Android und

BlackBerry. Ferner wird bei Sencha Touch die Oberfläche einer App mit JavaScript

programmiert und nicht mit HTML deklarativ beschrieben.

Sencha Touch (http://www.sencha.com/products/touch) bietet noch mehr

Möglichkeiten als jQuery Mobile. Damit erstellte Websites sehen meist zu 100% wie

native Apps aus.

Info:

Möglichkeit jQuery Mobile in Dreamweaver zu nutzen. Mit Dreamweaver ab der Version

CS5.5 lassen sich mit einer integrierten Funktion jQuery Mobile Web-Apps erstellen.

Menü Datei / Neu / „Seite aus Beispiel“:

Eberhart mobilewebapp.docx 13

Quellen: