Mobile Applikationen - Juni 2013 - Cross-Plattform-Entwicklung

iks Thementag
„Mobile Applikationen – Es lebe die Vielfalt?!“
18.06.2013
Möglichkeiten, Vorteile und Grenzen der
Cross-Plattform-Entwicklung
Autor:
Jan Laußmann

Seite 3 / 75iks Thementag: Mobile Applikationen - Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung
Agenda
Warum Cross-Plattform entwickeln?
Hybrid Apps in der freien Wildbahn
Aufwand für die Entwicklung von Hybrid Apps
Die 3 größten Probleme bei der Hybrid App Entwicklung lösen
Hybrid Apps und der Apple Store – gibt es Probleme?
Grenzen der Hybrid App Entwicklung
Entscheidung treffen: Native App oder Hybrid App?

Agenda

So wird App Entwicklung oft dargestellt

Aber das ist falsch!

Die Entwicklung macht den Löwenanteil aus

Und bei mehreren Plattformen…

Probleme der nativen App Entwicklung
Die App muss X mal komplett neu programmiert werden
– X mal Entwicklungskosten
– X mal Wartungskosten (Bugfixes)
Multiple Ansprechpartner
– Abstimmungsaufwand
– Einarbeitung z.B. in Backendkommunikation
Die Apps unterscheiden sich
– Qualität
– Benutzerführung
– Features
– …

Das bietet Cross-Plattform-Entwicklung

So soll das Ergebnis sein
Nur einmal programmiert
Fühlt sich an wie eine native App
Schauen wir uns mal an was eine native App ausmacht…

Native Apps
Cross-Plattform: nein
– Java (Android)
– Objective-C (iOS)
Natives Look & Feel: ja
Performance: schnell
Sichtbarkeit im App Store: ja
Platz auf dem Startbildschirm: ja

Native Apps
Offline Funktionalität: ja
Daten lokal speichern: ja
Zugriff auf Gerätesensoren: ja
– Kamera
– Geolocation
– …
Kommunikation mit anderen Anwendungen: ja
– Adressbuch
– Kalender
– …

Können Web Apps das leisten?
Cross-Plattform: ja
– HTML 5
– CSS 3
– JavaScript
Natives Look & Feel: nein
Performance: mittel
Sichtbarkeit im App Store: nein
Platz auf dem Startbildschirm: ja, aber …

Web Apps auf dem Startbildschirm

Web Apps
Offline Funktionalität: ja (HTML5 Application Cache), aber ...
Daten lokal speichern: ja via HTML5 Browser Datenbank
(Indexed DB, Web Storage oder Web SQL)
Zugriff auf Gerätesensoren: nein, bis auf Geolocation
Kommunikation mit anderen Anwendungen: nein

Überblick Native App vs. Web App
Native App Web App
Cross-Plattform nein ja
Natives Look & Feel ja nein
Performance schnell mittel
App Store ja nein
Startbildschirm ja ja, aber
Offline ja jein
Datenbank ja ja
Sensoren ja jein
Adressbuch etc. ja nein

Hybrid Apps
Hybrid Apps vereinen das Beste aus beiden Welten:
Cross-Plattform
Alle Smartphone Features nutzen

Hybrid Apps
Hybrid Apps bestehen aus:
Web App
– Cross-Plattform
Nativen Container (Verpackung) für Web App
– Alle Smartphone Features nutzen

Nativer Container
Den nativen Container kann man sich
als Spezial-Browser vorstellen
Keine URL Leiste oder ähnliches
Sondern nur der Teil des Browsers,
der die Web App anzeigt

Überblick: Native App vs. Hybrid App vs. Web App
Native App Hybrid App Web App
Cross-Plattform nein ja ja
Natives Look & Feel ja nein nein
Performance schnell mittel mittel
App Store ja ja nein
Startbildschirm ja ja ja, aber
Offline ja ja jein
Datenbank ja ja ja
Sensoren ja ja jein
Adressbuch etc. ja ja nein

Nativer Container: PhoneGap
Adobe
Open Source
Gut dokumentiert
Große Community
Android, iOS, Windows Phone, Blackberry

PhoneGap API
„Brücke“ (API) zwischen Web App und nativen Funktionen
APIs für die viele Smartphone Features wird direkt mitgeliefert
– Adressbuch
– Barcode Scanner
– Beschleunigungssensor
– U.v.m.
Kann mit eigenen APIs beliebig erweitert werden

Alternativen zu PhoneGap Nr. 1
Appcelerator / Titanium
Wird in JavaScript programmiert
Danach zu nativer App kompiliert

Alternativen zu PhoneGap Nr. 2
Mono Touch / Mono for Android
Wird in C# programmiert
Bietet eine Laufzeit Umgebung für C# Code auf Android und iOS
View ist nicht Cross-Plattform, muss für jede Plattform extra
programmiert werden

Bekanntheitsgrad: Hybrid App Frameworks
Quelle: Google Trends

PhoneGap Contributors
Adobe
IBM
Microsoft
Blackberry
HP/Palm
Salesforce

Agenda

Wikipedia (PhoneGap)

Wikipedia
Mit PhoneGap entwickelt
10 – 50 Millionen Installationen (Android)
Android
https://play.google.com/store/apps/details?id=org.wikipedia
iOS
https://itunes.apple.com/us/app/wikipedia-mobile/id324715238
BlackBerry
http://appworld.blackberry.com/webstore/content/105171/

HealthTap

HealthTap
1 – 5 Millionen Installationen (Android)
Android
https://play.google.com/store/apps/details?id=com.healthtap.userhtexpress
iOS
http://itunes.apple.com/us/app/healthtap-find-doctors-free/id466079030

Untappd

Untappd
100.000 – 500.000 Installationen (Android)
Android
https://play.google.com/store/apps/details?id=com.untappdllc.app
iOS
http://itunes.apple.com/us/app/untappd/id449141888
BackBerry
http://appworld.blackberry.com/webstore/content/21866709/
Windows Phone 8
http://www.windowsphone.com/en-us/store/app/untappd/2b72bcab-ae88-4134-9f19-dd47e77cd64a

http://phonegap.com/app/

Agenda

Wo bietet Cross-Plattform-Entwicklung Vorteile?
Hier kann man sparen
– App Entwicklung
– Wartung / Bugfixes
– Neue Features / Updates
 Immer dort wo programmiert wird
Das ist von der Entwicklungsmethode unabhängig
– Planung
– Tests
– Rollout
 Immer dort wo nicht programmiert wird

Höherer Aufwand als Nativ bei:
Interface Gestaltung
– Android und iOS nehmen hier dem Entwickler viel Arbeit ab
– Mobile CSS Frameworks stecken noch in den Kinderschuhen
 Deshalb ist es aufwändiger gute User Interfaces mit HTML/
CSS zu gestalten als mit Android oder iOS
Performance Tuning
– Bei nativer Entwicklung vernachlässigbar
– Bei Cross-Plattform-Entwicklung dringend notwendig!

Grobe Schätzung - Daumenregel
X = Aufwand 1 Native App
– Läuft auf 1ner Plattform
X * 1.5 = Aufwand Hybrid App
– Läuft auf allen Plattformen

Beispiel 1 für Daumenregel (Aufwand Entwicklung)
Native App für Android und iOS
– 1 * Aufwand X für Android
– 1 * Aufwand X für iOS
– Gesamtaufwand = 2X
Dieselbe App als Hybrid App
– 1 * 1.5-facher Aufwand
– Läuft auf Android und iOS
– Gesamtaufwand: 1.5X
Sparpotenzial: 25%
– Oder andersherum: nativ ist 33% teurer

Beispiel 2 für Daumenregel (Aufwand Entwicklung)
Native App für Android, iOS und Blackberry
– 1 * Aufwand X für Android
– 1 * Aufwand X für iOS
– 1 * Aufwand X für Blackberry App
– Gesamtaufwand = 3X
Dieselbe App als Hybrid App
– 1 * 1.5-facher Aufwand
– Läuft auf Android, iOS und als Blackberry App
– Gesamtaufwand: 1.5X
Sparpotenzial: 50%
– Oder andersherum: nativ ist 100% teurer

Benötigte Entwickler-Skills
Für die Web App
– JavaScript
– HTML
– CSS
Für den nativen Container
– Cross-Plattform Frameworks (z.B. PhoneGap)
– Java (Android)
– Objective-C (iOS)

Code Metriken
Beispiel Servicepoint App
Cross-Plattform Code: ~95%
Nativer Code: ~5%

Entwicklungs-Plattformen für Hybrid Apps
iOS
– Mac mit OS X und Xcode / AppCode
Windows Phone
– PC mit Windows und Visual Studio
Android
– Entwicklung überall möglich
Alternative: PhoneGap Cloud Build

Agenda

Problem 1: feststehender Header / Footer

Problem 1: feststehender Header / Footer
CSS Support für feststehende Elemente ist auf alten Geräten
nicht vorhanden
Mit JavaScript permanente Elemente neu zu positionieren führt
zu flackern der Elemente und trägen Anwendungen
Diverse Bugs bei CSS / JavaScript Lösungen
– Fixierte Elemente scrollen doch mit
– Fixierte Elemente verschwinden
– Eingabefelder schieben sich über fixierte Elemente
– Tabben in Eingabefeldern funktioniert nicht richtig

Lösung: native Header / Footer
Nativen Header / Footer mit Cross-Plattform App kombinieren
– Nativer Header / Footer ist fixiert
– Gesamte Cross-Plattform App scrolled dazwischen
Zwar nur 95% Cross-Plattform
Aber man bekommt dafür natives Look & Feel geschenkt
– Sieht wie eine native App aus
– Das Scrollen fühlt sich nativ an

Cross-Plattform App mit nativem Header

Native Look & Feel
Hybrid App
(Android) (iOS)
Native Apps
(Android) (iOS)

Einschub vor Problem 2: Single Tap

Einschub vor Problem 2: Double Tap

Problem 2: Klickverzögerung
Wenn in einem mobilen Browser getapped wird, wartet
der Browser ca. 400ms ob ein zweiter Tap folgt (Double Tap)
Wenn ein zweiter Tap folgt zoomed der Browser auf diese Stelle
Wenn kein zweiter Tap folgt feuert der Browser ein Click Event
 Die App fühlt sich ungewohnt träge an

Lösung: Den ersten Tap direkt als Click interpretieren
Auch Hybrid Apps sollen sich..
– …nicht wie mobile Websites anfühlen (was sie technisch sind),
– …sondern wie native Apps
Also: Direkt der erste Tap muss als Klick interpretiert werden
– Ohne Wartezeit
Das gibt PhoneGap nicht direkt her
Doch es gibt passende JavaScript Libraries
– z.B. „fastclick“ von der Financial Times
https://github.com/ftlabs/fastclick

Problem 3: Animationen
Bei der klassischen Webentwicklung werden Animationen
mit JavaScript realisiert
Smartphones sind aber leistungsschwächer als Desktop PCs
 Animationen sehen ruckelig aus

Problem 3: Animationen weglassen?
Animationen sind nicht nur für Spiele wichtig
Animationen bei Business Anwendungen:
– Seitenwechsel
– Tooltips einblenden
– …
 Auf Animationen kann man nicht einfach verzichten

Lösung: CSS3
CSS3 Animationen sind hardwarebeschleunigt
Computer / Smartphones
– Hauptprozessor (CPU)
– Grafikkarte (GPU)
JavaScript Animationen: allgemeiner Hauptprozessor
CSS3 Animationen: spezialisierte Grafikkarte
 Bringt 2-3 fache Beschleunigung

Agenda

Hybrid Apps und der Apple Store
PhoneGap:
„Apple hat eine technische Überprüfung durchgeführt und PhoneGap
Apps verstoßen nicht gegen die AGB des Apple Stores“
Aber Hybrid Apps wurde schon die Freigabe im Apple Store
verweigert!
Wie passt das zusammen?

Gründe für Ablehnung
Verstoß gegen:
Human Interface Guidelines: Reconsider Web-Based Designs:
– Focus your app
– Design for touch
– Let people scroll
Apple’s App Store Review Guidelines
– Apps that are […] simply web sites bundled as Apps [...] may be
rejected.
– Apps that are simply web clippings, content aggregators, or a
collection of links, may be rejected.

Hybrid Apps und der Apple Store - Fazit
Hybrid Apps dürfen in den Apple Store
Für Hybrid Apps gelten dieselben Bedingungen wie
für native Apps
 Man darf es sich nicht zu einfach machen
 Eine App muss Mehrwert bieten

Agenda

Grenzen der Cross-Plattform-Entwicklung
Das größte Problem ist die Performance
Auf guten Smartphones sind Hybrid Apps kaum von nativen
Apps zu unterscheiden
Aber auf alten, leistungsschwachen Geräten sind Hybrid Apps
relativ langsam
 In der Regel alle 2 Jahre ein neues Smartphone

Grenzen der Cross-Plattform-Entwicklung
Native Look & Feel
Beispiel Checkboxen
– Android
– iOS
 Für Cross-Plattform muss ein Kompromiss gefunden werden

Agenda

Hybrid Apps
– Wirtschaftlich sinnvoll
– Technisch machbar
 Wird deshalb in Zukunft im Focus liegen
Native Apps
– Nur eine Plattform
– Kein Kompromiss bei native Look & Feel möglich
– Aufwändigere Animationen (Spiele)

Weiterführende Literatur
PhoneGap
http://w ww.phonegap.com

Mobile Applikationen - Juni 2013 - Cross-Plattform-Entwicklung

Weitere ähnliche Inhalte

Was ist angesagt?

Ähnlich wie Mobile Applikationen - Juni 2013 - Cross-Plattform-Entwicklung

Mehr von IKS Gesellschaft für Informations- und Kommunikationssysteme mbH

Mobile Applikationen - Juni 2013 - Cross-Plattform-Entwicklung