4. Android 45%
Nokia 33%
BlackBerry 5%
Apple iOS 3%
Other 14%
GERMANY
MEXICO
CHINARUSSIA AUSTRALIA
UK SPAIN
TURKEYNIGERIAINDONESIA
BRAZIL
FRANCE
JAPAN
INDIA
USA
Apple iOS 52%
Android 39%
BlackBerry 5%
Windows 2%
Other 2%
Android Apple iOS BlackBerry Nokia
Samsung Windows Other
Apple iOS 42%
Android 29%
BlackBerry 17%
Nokia 5%
Other 7%
Android 60%
Apple iOS 14%
Nokia 11%
Windows 4%
Other 11%
Android 52%
Apple iOS 28%
Nokia 10%
Windows 4%
Other 6%
Android
Apple iOS
Windows
Other
63%
32%
2%
3%
Apple iOS
Android
Windows
Other
48%
44%
4%
4%
Android
Apple iOS
Windows
Other
72%
24%
2%
2%
Nokia 36%
Android 33%
Samsung 14%
Other 17%
Android 63%
Apple iOS 21%
Nokia 4%
Other 12%
Apple iOS
Android
Windows
Other
64%
33%
2%
1%
Android 59%
Apple iOS 21%
Nokia 7%
Windows 6%
Other 7%
Nokia 51%
Android 18%
Samsung 2%
BlackBerry 2%
Other 27%
Android 68%
Apple iOS 18%
Nokia 8%
Windows 4%
Other 2%
Apple iOS 61%
Android 38%
Other 1%
MOBILE
OPERATING SYSTEM
MARKET SHARE
JANUARY 2014
Data Source: http://gs.statcounter.com/
Published Under a Creative Commons Attribution 3.0 Unported License
You are free to copy, distribute and transmit the work and to adapt the work
providing is it attributed to www.icrossing.co.uk
http://connect.icrossing.co.uk/
WORLDWIDE MARKET SHARE SINCE 2011
50%
2011 2012 2013 2014
40%
30%
20%
10%
0%
4
6. Native Mobile Apps Runtime
Mobile App
Mobile OS
Services
Nativer Code
6
Input
Graphik
Sensoren
API
7. Vergleich mobile Plattformen
Mobile OS iOS Android Windows Phone
Abstammung OS X Linux Windows NT
Programmiersprache Objective-C, Swift Java C#/C++,VB
Entwicklungsumgebung Xcode Eclipse, Android
SDK
Visual Studio
Store App Store Google Play
Store
Windows Phone Store
Unterstützte Geräte iPhone, iPad Breite Palette an
Geräten
Breite Palette an Geräten
Multitasking Pseudo / Simuliert Echt Pseudo / Simuliert
Browser Mobile Safari Google Chrome Internet Explorer
Widgets / Grafikobjekte In
Benachrichtigungszentrale
Ja Nein
Cloud / Services Unterstützung iCloud Google Sync,
Google Drive
Sky Drive
7
8. Zusammenfassung der aktuellen
Situation mobile Plattformen
• Geräteeigenschaften wie Bildschirmgröße, Eingabemöglichkeiten und
Anzeigenmöglichkeiten können sich stark zwischen Herstellern unterscheiden
• Es gibt zwei Plattformen die den Markt für Smarte Endgeräte dominieren: iOS
und Android
• Andere Plattformen führen ein Nischendasein, können aber in bestimmten
Märkten dennoch eine Rolle spielen, insbesondere Windows und Blackberry
• Die von den Plattformherstellern zur Verfügung gestellten Werkzeuge sind sehr
inkompatibel und Apps können mit diesen Werkzeugen nur für die eigene
Plattform erstellt werden
• Es ist unwahrscheinlich, dass sich die Situation in den nächsten Jahren ändert
8
9. Problemstellung
• Eine mobile App muß konsistente User Experience
bieten und sich auf unterschiedlichen Plattformen
und Geräten gleich verhalten
• Die Kosten für Entwicklung und Wartung sollen
minimiert werden
9
10. Analysephase
Vor der Softwareentwicklung müssen die Anforderungen
an die App sehr genau unter folgenden Gesichtspunkten
analysiert werden:
• Welche Plattformen und Geräte sollen unterstützt
werden?
• Welche Anforderungen existieren im Bezug auf
Geräteressourcen?
• Welche Anforderungen bestehen im Hinblick auf UI
Performance und Look&Feel?
10
11. Bewertungskriterien für
Architekturansätze
Ansatz Beurteilung
Anzahl
Plattformen
Wie viele unterschiedliche Plattformen werden unterstützt? +/0/-
Lernkurve für
Entwickler
Wie aufwendig ist es, den Ansatz zu beherrschen? +/0/-
Werkzeugunterst
ützung
Wie viel Unterstützung durch Werkzeuge gibt es?
Integration in existierende Werkzeuge?
+/0/-
Homogenität Wie viel plattformspezifischer Code muss entwickelt werden? +/0/-
Native GUI
Elemente
Wie gut können native GUI Elemente angesprochen werden? +/0/-
UI
Geschwindigkeit
Wie flüssig lässt sich das UI bedienen? +/0/-
Zugriff auf
mobile OS
Ressourcen
Wie gut und auf wie viele verschiedene Betriebssystemressourcen kann zugegriffen
werden?
+/0/-
Sichtbarkeit im
App Store
Ist die Lösung im App Store sichtbar? +/0/-
11
14. Idee
• Jedes mobile Endgeräte hat einen Browser mit HTML5
Unterstützung integriert
• Programmiersprachen und Umgebungen (HTML5/
CSS3/JavaScript) sind weit verbreitet und
standardisiert
• Wird normalerweise mit Javascript Bibliothek verknüpft,
die für mobile Anwendungen ausgelegt ist: jQuery
mobile, Kendoo UI mobile, Sencha touch, ionic
• Breites Angebot an Entwicklungsumgebungen
14
16. Eigenschaften
16
HTML5 Beurteilung
Anzahl
Plattformen
wird von den meisten Endgeräten unterstützt
+
Lernkurve für
Entwickler
gering für Webentwickler
+
Werkzeugunter-
stützung
sehr gut, breite Palette an Werkzeugen
+
Homogenität
Da HTML5 Implementierungsstand zwischen Browsern unterschiedlich ist, muss im
source code vor Benutzung von fraglichen features ein Überprüfung stattfinden.
Gute Rollunterstützung (e.g. moderner) +
Native GUI
Elemente
Nicht unterstützt, können durch Styling simuliert werden, doch ist der Unterschied
„fühlbar“ -
UI
Geschwindigkeit
Abhängig von JavaScript Framework, im Allgemeinen aber spürbar langsamer als
native Komponenten -
Zugriff auf
mobile OS
Ressourcen
Sehr limitiert (siehe HTML5 Standard) und abhängig von der HTML5
Implementierung des Browsers -
Sichtbarkeit im
App Store
Keine Sichtbarkeit im App Store, keine Monetarisierung durch App/In-App Käufe
-
17. Empfehlung
• Wenn keine Präsenz im App-Store notwendig ist
• Zur Zeit nur für einfache Anwendungen ohne
besondere Anforderungen an Usability und
Zugriff auf OS Ressourcen empfehlenswert
17
19. Idee
• Native WebKit-Komponente dient als Basis einer App
• HTML/CSS/Javascript werden als Teil einer App lokal
auf dem Mobilgerät abgelegt und vom WebKit
interpretiert
• OS Ressourcen, die nicht über den Webcontainer
erreichbar sind, können über Plug-ins via Javascript
aufgerufen werden
• Fehlende Funktionen können durch eigene Plugins
ergänzt werden
19
20. Hybride Apps
20
Mobile App
Mobile OS
Services
Input
Graphik
Sensoren
WebApp Plug-ins
HTML
Rendering
Engine
(WebView)
JavaScript/
HTML/CSS
Camera
Compass
Contacts
Notification
21. Bemerkungen
• PhoneGap / Apache Cordova mit Abstand
bekanntestes Produkt
• Standard-Plugins für: Battery, Camera, Capture,
Console, Contacts, Device, Device Motion, File, File
transfer, Geolocation, Globalization, Inappbrowser,
Media, Network information, Notification, Splashscreen
• Viele 3rd Party Plugins verfügbar
• Plugin bestehen aus einer Implementierung in nativen
Code und einem Javascript Teil
21
23. Eigenschaften
23
Hybrid App Beurteilung
Anzahl
Plattformen
wird von den meisten Endgeräten unterstützt, Plug-ins evtl. nur für eingeschränkte
Anzahl von Plattformen +
Lernkurve für
Entwickler
gering für Webentwickler +
Werkzeugunter-
stützung
sehr gut, breite Palette an Werkzeugen +
Homogenität
Unterschiede in den Browser Implementierungen werden gut durch frameworks
abstrahiert. +
Native GUI
Elemente
Nicht unterstützt, können durch Styling simuliert werden, doch ist der Unterschied
„fühlbar“ -
UI
Geschwindigkeit
Abhängig von JavaScript Framework, im Allgemeinen aber spürbar langsamer als
native Komponenten -
Zugriff auf
mobile OS
Ressourcen
Für die meisten Ressourcen gibt es Plug-ins, aber Zugriff manchmal nur
eingeschränkt möglich oder kein Plug-in vorhanden +
Sichtbarkeit im
App Store
Sichtbar im App Store +
24. Empfehlung
• Wenn App über AppStore verfügbar sein soll
• Wenn UI Performance und nativer Look&Feel
nicht wichtig sind
• Wenn Zugriff auf mobile OS Ressourcen über
Plugins unterstützt wird
24
26. Idee
• JavaScript als Programmiersprache, aber in einem
Container, der auf native UI Elemente zugreift
• Titanium SDK/Appcelerator bekanntestes Produkt
• Es muss in den meisten Fällen
plattformspezifischer Code entwickelt werden
• Eigener Compiler und Laufzeitumgebung
notwendig
26
28. Eigenschaften
28
Interpretierte Apps Beurteilung
Anzahl
Plattformen
wird von den meisten Endgeräten unterstützt, Plug-ins evtl. nur für eingeschränkte
Anzahl von Plattformen 0
Lernkurve für
Entwickler
gering für javascript, aber bibliotheken müssen gelernt werden 0
Werkzeugunter-
stützung
im Allgemeinen gut +
Homogenität Im Code muss zwischen den verschiedenen OS unterschieden werden 0
Native GUI
Elemente
Native UI Elemente können angesprochen werden, wenn mapping vorhanden +
UI
Geschwindigkeit
Da native UI Elemente verwendet werden, ist die Performance besser als beim
browserbasierten Ansatz, im Allgemeinen gut, allerdings kann die Verwendung von
javascript und notwendige Interpretation zur Laufzeit in bestimmten Fällen zu
Performanceproblemen führen
0
Zugriff auf
mobile OS
Ressourcen
Zugriff auf native Ressourcen geschieht über javascript wrapper +
Sichtbarkeit im
App Store
Sichtbar im App Store +
29. Empfehlung
• Wenn App über AppStore verfügbar sein soll
• Wenn UI Performance und nativer Look&Feel wichtig sind
• Wenn Zugriff auf mobile OS Ressourcen von der Plattform
unterstützt wird
• Technologie auf jeden Fall im Auge behalten, neue
Implementierungen basieren auf dem Ansatz sind in
Vorbereitung: ReactJS mobile von Facebook und
NativeScript von Telerik.
29
31. Idee
• Xamarin zur Zeit der einzige ernsthafte Anbieter (kommerziell)
• Benutzt bekannte Programmiersprache (C#) und übersetzt sie
in nativen Code der Zielplattformen
• Stammt vom Mono Projekt ab (C# auf linux)
• Sehr reichhaltige und ausgereifte Werkzeugpalette
• UI Code wird mit plattformspezifischen Bibliotheken entwickelt,
der restliche Code ist plattformunabhängig (MvvmCross)
• Zugriff auf OS Ressourcen wird über native Bindings hergestellt
31
32. Cross Compiler
App
UI Layer
Platform Specific Code
Business Logic Layer / Domain
Model
Data / Service Access Layer
32
Mobile OS
Services
Input
Graphik
Sensoren
Plattform
unabhängig
Plattform
abhängig
33. Eigenschaften
33
Cross Compiler Beurteilung
Anzahl
Plattformen
Für Android und iOS erhältlich, Windows nicht notwendig 0
Lernkurve für
Entwickler
gering für C# Entwickler aber höher für Webentwickler 0
Werkzeugunter-
stützung
sehr gut, breite Palette an Werkzeugen +
Homogenität
Es muss plattformspezifischer Code für das UI entwickelt werden, solange nicht
Xamarin Forms benutzt wird 0
Native GUI
Elemente
Sehr gute Unterstützung +
UI
Geschwindigkeit
Vergleichbar zur nativen Entwicklung +
Zugriff auf
mobile OS
Ressourcen
Bindings für Native OS Ressourcen sind sehr vollständig vorhanden +
Sichtbarkeit im
App Store
Sichtbar im App Store +
34. Empfehlung
• Wenn App über AppStore verfügbar sein soll
• Wenn UI Performance und nativer Look&Feel
wichtig sind
• Wenn bereits C# Know-how vorhanden ist
34
35. Qualitätssicherung
• Qualitätssicherung ist integraler Teil des Entwicklungsprozesses,
auch bei Cross-Plattform-Entwicklung
• App muss auf allen Zielplattformen getestet werden
• Mit steigender Anzahl Plattformen wird Automatisierung wichtiger
• Risikobasiertes, manuelles Testen ist unerlässlich für:
• UI Performance und Look&Feel
• Gerätefunktionen
• Konsistenz
35
36. • Appium (www.appium.io)
• Appcelerator Test (ww.appcelerator.com/
functionaltest/)
• Calabash (calaba.sh)
36
Testwerkzeuge für Cross-
Plattform Test-Automatisierung
37. Device-Clouds
Device-Clouds stellen eine große Anzahl an
Kombinationen von physischen Geräten und
Betriebssystemen zum automatisierten Testen in einer
Cloud-Umgebung bereit
• Xamarin Test Cloud
(xamarin.com/test-cloud)
• Soasta TouchTest
Mobile Device Cloud
(www.soasta.com/products/touchtest-private-
device-cloud)
37
39. Zusammenfassung der
Eigenschaften der Grundarchitektur
39
HTML5 Hybrid App Interpretierte Apps Cross Compiler
Anzahl Plattformen + + 0 0
Lernkurve für
Entwickler + + 0 0
Werkzeugunterstützung + + + +
Homogenität + + 0 0
Native GUI Elemente - - + +
UI Geschwindigkeit - - 0 +
Zugriff auf mobile OS
Ressourcen - + + +
Sichtbarkeit im App
Store - + + +
40. Schlußfolgerung
• Vor der Softwareentwicklung müssen die Anforderungen an die Zielplattformen
der App sehr genau analysiert werden.
• Bei der Auswahl des Architekturansatzes und des Produktes nach den
ausgearbeiteten Kriterien und Empfehlungen vorgehen.
• Prototypen und/oder Entwicklung eines Piloten ist in den meisten Fällen
notwendig, insbesondere wenn noch geringe Erfahrungen mit dem
Architekturansatz gemacht wurden.
• Die heute zur Verfügung stehenden Ansätze können in den meisten Fällen die
zugrundeliegende Plattform nicht komplett abstrahieren. Es muss bis zu einem
gewissen Grad ein separater Code entwickelt werden.
• Wenn kein passendes Modell gefunden wird, kann dies ein Hinweis sein, dass
Cross-Plattform mit den existierenden Werkzeugen keine Alternative ist und
separate native Entwicklungen vorzuziehen sind.
40
41. Ressourcen (1/2)
Vergleich von Architekturansätzen:
• Cross-Platform Mobile Development: PhoneGap vs Xamarin,
Justin Shield, 03.05.2014 (http://www.justinshield.com/2014/05/
cross-platform-mobile-development-phonegap-vs-xamarin/)
• Cross-Platform Mobile Development, Peter Friese, 2012 (http://
de.slideshare.net/peterfriese/cross-platform-mobile-
development-11239246#)
• Titanum versus PhoneGap (HTML5), AppWerft Hamburg, 2015,
http://hamburger-appwerft.de/titanium-hyperloop/titanium-html5/
• PropertyCross (http://PropertyCross.com)
41
42. Ressourcen (2/2)
PhoneGap
• Cross-Plattform-Apps mit PhoneGap entwicklen, Marcus Ross, 13.08.2013 (http://
www.heise.de/developer/artikel/Cross-Plattform-Apps-mit-PhoneGap-entwickeln-1934535.html)
• Cross-platform Entwicklung mit PhoneGap und Ionic, Aaron Wyder, 29.10.2014 (http://
blog.zuehlke.com/cross-platform-entwicklung-mit-phonegap-und-ionic/)
Appcelerator/Titanium
• Four Ways to Build A Mobile Application, Part 4: Appcelerator Titanum, Peter Traeg,
20.03.2014, (http://www.smashingmagazine.com/2014/03/10/4-ways-build-mobile-application-
part4-appcelerator-titanium/)
Xamarin
• Xamarin Homepage (xamarin.com)
• Native mobile Apps für iOS und Android mit Xamarin, Oliver Brack, 27.05.2013 (http://
blog.zuehlke.com/native-mobile-apps-fur-ios-und-android-mit-xamarin/)
42