Unterschiedliche entwicklungsansätze von Multiplattform … · 2020. 4. 28. · der hybride entwicklungsansatz. Darüber hinaus gibt es weitere ansätze der Multi-plattform-entwicklung,

Marktübersicht

Unterschiedliche entwicklungsansätze von Multiplattform-anwendungen

august 2014

2 3

Unterschiedliche Entwicklungsansätze von Multiplattform-AnwendungenUnterschiedliche Entwicklungsansätze von Multiplattform-Anwendungen

1 einleitung

2 ansätze zur Multiplattform-entwicklung

2.1 Nativer entwicklungsansatz

2.2 Webbasierter entwicklungsansatz

2.3 hybrider entwicklungsansatz

2.4 Weitere entwicklungsansätze

3 autoren

4 Quellen

inhaltsverzeichnis

Die Marktübersicht einschließlich aller Bestandtteile ist urheberrechtlich geschützt und alle Rechte daran sind vorbehalten. Verwertungen der Mark-tübersicht oder von Teilen dieser Veröffentlichung sind ausschließlich nach Genehmigung unter Angabe der Quelle „Unterschiedlliche Entwicklungsan-sätze von Multiplattform-Anwednungen (eBusiness-Lotse Aachen)“ zulässig.

Die Inhalte der vorliegenden Marktübersicht geben zum Zeitpunkt der Erstel-lung den aktuellen Stand der Forschung und Entwicklung wieder. Dennoch kann für die Vollständigkeit und Richtigkeit keine Haftung übernommen werden.

Bei Fragen und Anregungen steht Ihnen gerne das Team des mobile media & communication lab zur Verfügung.

Impressum

Herausgeber:eBusiness-Lotse Aachenc/o FIR e.V. an der RWTH AachenCampus-Boulevard 5552074 Aacheninfo@ebusiness-lotse-aachen.dewww.ebusiness-lotse-aachen.de

Redaktion:mobile media & communication lab der FH AachenRafael Pisarczyk, Thomas Ritz, Ramona Wallenborn

Gestaltung und Produktion:Ramona Wallenborn

Bildnachweis:S. 4 von Contegix, S. 22 von 8Tracks, S. 24 von Kuli; alle anderen Fotos und Grafiken sind eigene Darstellungen

Stand: August 2014

………………………………………………….….……………………………………………….. s. 4

………………………………….….……………………………... s. 6

………….….…….……………………………………………………….. s. 8

…….……..………………………………………………………. s. 12

……………….….…………………………………………………….. s. 16

………………………………………………………………………… s. 20

……………………………………………….….…………………………………………………… s. 22

…………….……………………………………………………………………………………….… s. 24

Zielgruppe

Die Marktübersicht „Unterschiedliche entwicklungsansätze von Multiplattform-anwendungen“ richtet sich an it-Dienstleister, entwickler und it-abteilungen von Unternehmen, die Multiplattform anwendungen entwickeln. in dieser Marktübersicht werden verschiedene entwicklungsansätze beschrieben und ihre jeweiligen Vor- und Nachteile aufgezeigt.

4 5


Mobile Endgeräte erleichtern zahlreichen Men-schen den Alltag Mit dem wachsenden absatzmarkt für smartpho-nes steigt auch die Nachfrage nach mobilen appli-kationen (apps) rasant. im Jahr 2009 betrug die anzahl der Downloads mobiler applikationen in Deutschland rund 89 Millionen, im Jahr 2012 waren es bereits 1,7 Milliarden anwendungen. Die Zahl der smartphone-Nutzer ist ebenfalls erheblich gestiegen. Nutzten anfang 2009 lediglich 6,31 Milli-onen Deutsche ein smartphone, so lag der Wert im Oktober 2013 bereits bei 37,4 Millionen deutschen smartphone-Nutzern.

es gibt zahlreiche unterschiedliche smartphone- Modelle und Geräteklassen, die sich in hersteller, Größe und Leistung unterscheiden. eine beson-derheit bei der Umsetzung von mobilen anwendun-gen ist die sogenannte Plattform- Fragmentierung. hierbei müssen verschiedene betriebssysteme (Plattformen) wie zum beispiel iOs, android und Windows Phone berücksichtigt werden. Dies erfordert unterschiedliche kompetenzen bei der app-entwicklung sowohl im technischen als auch im gestalterischen Bereich. Häufig besteht die Not-wendigkeit, arbeiten mehrfach vornehmen zu müs-sen, weil sich bestehende Lösungen nicht ohne Weiteres auf andere Plattformen bzw. betriebssys-teme und deren Versionen übertragen lassen.

Den größten Marktanteil mobiler betriebssysteme gemessen am absatz hat derzeit android von Goo-gle mit etwa 76 Prozent. Danach folgt iOs von apple mit circa 15 Prozent Marktanteil. Während Windows von Microsoft noch 7,5 Prozent erzielt, hat blackberry einen kaum merkbaren anteil von 0,7 Prozent.

Trotz einer geläufigen Verwendung des Begrif-fes „Multiplattform“ gibt es zurzeit keine eindeutige Definition darüber. Während in der Literatur von verschiedenen Versionen einer anwendungen aus-gegangen wird, die auf unterschiedlichen Plattfor-men genutzt werden kann, so sprechen hersteller der Multiplattform-Werkzeuge davon, wenn bereits mindestens zwei Plattformen adressiert werden. Darüber hinaus variiert auch der Umfang plattform-spezischer entwicklung je nach hersteller.

App-Einfürhung und -Entwicklung in der Praxis it-Dienstleister sowie -entwickler und Manager von Unternehmen stehen bei der einführung bzw. entwicklung von mobilen Lösungen zur anbindung von diversen endgeräten wie smartphones und tablets in die eigene it-Unternehmensinfrastruk-tur vor herausforderungen. beispiele dafür sind die interne einbindung von Vertriebsmitarbeitern oder die externe ansprache von kunden über mobile endgeräte.

ein beispielhafter auszug eines Gespräches zwischen einem Geschäftsführer und it-Leiter eines mittelständischen Unternehmens:

Geschäftsführer: „Wir benötigen eine app.“ IT-Leiter: „Für welche Plattform?“

Geschäftsführer: „Wieso Plattform? Mobil!“

IT-Leiter: „android, iOs, Windows Phone, black berry oder…?“

Geschäftsführer: „Für alle! Oder nicht?“

aus diesem beispiel wird deutlich, dass kunden möglicherweise erwarten, dass alle Plattformen adressiert werden, obwohl mehr oder weniger nur für die entwicklung einer anwendung budget vor-handen ist.

1 Einleitung

6 7


2 Ansätze Multiplattform-Entwicklung

in der heutigen Zeit ist die software-entwicklung hinsichtlich zahlreicher mobiler endgeräte und betriebssysteme komplexer als einige Jahre zuvor. Die Welt der mobilen endgeräte wird immer viel-fältiger – vom smartphone über tablets bis hin zu smartWatches.

Deswegen sollte noch vor der eigentlichen imple-mentierung der app zunächst eine strategie fest-gelegt werden, in der unterschiedliche aspekte wie zum beispiel die Vision und das Geschäftsmo-dell des Unternehmens, die Produkteigenschaften und das innovationspotenzial der software hinter-legt sind. Ziel und im Fokus der entwicklung sollte jedoch immer eine zufriedenstellende User experience (deutsch: Nutzererlebnis) sein.

Noch bevor mit der software-entwicklung begon-nen wird, sollte systematisch festgelegt sein, wer der anwender der zu entwickelnden software sein wird und in welchem Umgebungskontext die anwendung eingesetzt wird. Darüber hinaus sollten unterstützende Prozesse und sogenannte Digital assets genutzt werden. Durch das „Mobile Process Landscaping“-Vorgehen können Nutzungspotenzi-ale systematisch konkretisiert und die Wirtschaft-lichkeit mobiler Prozesse bewertet werden.

Getreu dem Motto „Viele Wege führen nach rom“ gibt es hinsichtlich der mobilen software-entwick-lung ebenfalls viele unterschiedliche ansätze und Wege, die eingesetzt werden können. bei der Mul-tiplattform-entwicklung lassen sich drei bedeut-same entwicklungsansätze unterscheiden:

► der native entwicklungsansatz,

► der webbasierte entwicklungsansatz und

► der hybride entwicklungsansatz.

Darüber hinaus gibt es weitere ansätze der Multi-

plattform-entwicklung, wie zum beispiel den app Factory-ansatz, den übersetzungsansatz, den interpretationsansatz und den modellgetriebenen ansatz.

Die dazu verwendeten Werkzeuge lassen sich hin-sichtlich verschiedener aspekte differenzieren:

► architektur der app,

► erwartungskonformität,

► entwicklungsumgebung,

► systemanforderungen,

► Programmiersprache,

► entwicklungsvorgang,

► kompetenzbedarf,

► Performance,

► Distributionskanal,

► entwicklungszeit und

► Lizenzgebühren.

8 9


Kompetenzbedarf Die entwicklung nativer anwendungen bedarf einer Menge know-how hinsichtlich der Plattform, der entwicklungsumgebung sowie der Programmier-sprache.

Performance Dadurch dass keinerlei unnötige Zwischenschich-ten innerhalb der app-architektur vorhanden sind, besitzt eine native app eine gute ausführungsge-schwindigkeit. beispielsweise sind animationen prinzipiell flüssig ausführbar. Dies hängt allerdings auch stark vom entwickelten code und somit von den Fähigkeiten der entwickler zusammen ab.

Distributionskanal soll eine app veröffentlicht werden, so kann bezie-hungsweise muss diese in einigen Fällen über den store des Plattformherstellers vertrieben wer-den. Dies beinhaltet in den „Muss“-Fällen die ein-reichung der app und dem Durchlaufen eines review-Prozesses. Die app wird nach einem durchlaufenen Prozess entweder in den store auf-genommen und steht somit zum Download bereit oder sie wird unter angabe von Gründen zurückge-wiesen. Vor Wiedereinstellung müssen die ange-merkten Probleme beseitigt werden. iOs-apps wer-den im apple app store vertrieben, android-apps im Google Play store und Windows Phone-apps im Windows Phone Marketplace. Das hosting der anwendung sowie die abrechnung und bewer-tungsmöglichkeiten erfolgen dabei zentral über den store des Plattformherstellers.

Mit jedem kauf einer app oder eines app-inhalts erhält der Plattformhersteller eine Marge. Für Windows Phone- und iOs-apps gibt es keine ande-ren Distributionsmöglichkeiten, um native anwen-dungen zu veröffentlchen.

Entwicklungszeit Durch die mehrfache entwicklung der anwendun-gen, abhängig von der adressierten Zielplattform, ist die entwicklungszeit entsprechend hoch. Dies bedeutet, dass je nach strategie auch die time- to-Market (deutsch: Produkteinführungszeit) eben-falls sehr hoch ist.

Lizenzgebühren es fallen Lizenzgebühren für die entwicklung von nativen apps an.

zeugen zum Fehlerbeheben sowie einem com-piler zum erstellen der app. Für android gibt es das gleichnamige android-sDk, für apples mobi-les betriebssystem das iOs-sDk und von Micro-soft wird das Windows Phone-sDk angeboten. Für die iOs-entwicklung wird beispielsweise die Xcode iDe (integrated Development environment) benötigt, Windows Phone-anwendungen werden in Microsofts Visual studio entwickelt. Für android gibt es seit kurzem das android studio oder das unter Java-entwicklern bekannte eclipse iDe mit aDt (android Development tools)-Plugin.

Systemanforderungen Um manche dieser Werkzeuge nutzen zu können, müssen gewisse systemanforderungen erfüllt wer-den. so wird für die entwicklung von iOs-apps mit Xcode ein Mac mit installiertem Os X 10.7 betriebssystem oder höher benötigt. Die entwick-lung einer Windows Phone-app mit Visual studio benötigt hingegen einen Pc mit installiertem Windows 8 pro betriebssystem oder höher in der 64-bit-Version. eclipse und das android sDk besit-zen solche systemvoraussetzungen nicht.

Programmiersprache Für android-apps wird Java, für iOs-apps Objec-tive-c und neuerdings auch swift und für Windows Phone-apps beispielsweise c# .Net eingesetzt.

Entwicklungsvorgang Während der entwicklung werden die Werkzeuge des Plattformherstellers genutzt, um eine app für die entsprechende Plattform zu entwickeln. abhän-gig von der anzahl der adressierten Plattformen muss die gleiche app mehrfach für die jeweiligen Zielplattformen entwickelt werden. Zur Gestaltung der Oberflächen können während der Entwicklung vorhandene Oberflächendesigns verwendet wer-den. Diese beinhalten vordefinierte Steuerelemente im plattformspezifischen Stil. Unter Zuhilfenahme der jeweiligen styleguides lässt sich so eine erwar-tungskonforme Oberfläche für die Anwendung gestalten. Die entwicklung der Funktionalität erfolgt in der jeweiligen Programmiersprache unter Ver-wendung der angebotenen schnittstellen des sDks. hierdurch können alle angebotenen Funkti-onalitäten der Plattform genutzt werden. Das heißt, es kann auf kameras, die sensorik sowie adress-bücher etc. zugegriffen werden. Dies trägt ebenfalls zu einer erwartungskonformen anwendung bei.

setzt. trotz unterschiedlicher herangehensweisen bezeichnet man die resultierenden apps als nativ.

Erwartungskonformität einen weiteren Unterschied bilden die unterschiedlichen interaktionsparadigmen der einzelnen Platt-formen. so haben android-anwendungen die drei Standard-Schaltflächen „Back, Home und Recents“ in der sogenannten „Naviagtion bar“. iOs hingegen hat nur einen „home“-button, mit welchem zum beisoiel die app minimiert oder die taskliste geöff-net werden kann. Des Weiteren besitzt jede Platt-form ihren eigenen individuellen stil und unter-scheidet sich in der anzahl, der Vielfalt und dem aussehen der steuerelemente von den anderen Plattformen. Solche plattformspezifischen Eigen-schaften sind in den entsprechenden styleguides der Plattformen beschrieben. Diese sind bei der Umsetzung der apps zu beachten, um das Look & Feel (deutsch: anmutung) der Plattform sowie eine hohe erwartungskonformität zu erhalten.

Entwicklungsumgebung bedingt durch die zu verwendenden Werkzeuge gestalten sich die entwicklungsprozesse je nach Plattform unterschiedlich. Um eine native anwen-dung für die entsprechenden Plattformen zu ent-wickeln, wird je nach Zielplattform eine eigene entwicklungsumgebung benötigt. Diese besteht sowohl aus dem angebotenen software Develop-ment kit (kurz sDk; Werkzeugsammlung zum erstellen einer software) mit Programmierbiblio- theken als auch einem editor zum erstellen der Benutzeroberflächen, einem Code-Editor zum schreiben der Funktionalität, Debugging-Werk-

Der native entwicklungsansatz hat im bereich der mobilen anwendungsentwicklung eine doppelte Bedeutung. Häufig wird der vom Plattformherstel-ler vorgesehene ansatz zur entwicklung von Dritt- anwendungen für die Plattform als nativer entwick-lungsansatz verstanden. eine weitere bedeutung ist die hardwarenahe entwicklung von Dritt-anwendungen für ein bestimmtes Gerät. im Weiteren soll die geläufigere Definition der beiden, der Platt-form-ansatz, verwendet werden.

Die native Entwicklung ist, wie zuvor in der Defini-tion beschrieben, maßgeblich von den Vorgaben des Plattformherstellers (z. b. apple, Google oder Microsoft) abhängig. Dies liegt sowohl an der Platt-form an sich als auch an der zur ausführung nöti-gen architektur der anwendungen. Die Plattformen und die entwicklungsprozesse unterscheiden sich von denen der anderen Plattformhersteller, wie im Nachfolgenden verdeutlicht wird.

Architektur der App Der aufbau einer app, die auf apples betriebssystem iOs ausgeführt wird, ist anders aufgebaut als eine anwendung, die auf Googles android läuft. Während die iOs-anwendung am ende der ent-wicklung in Maschinen-code (geräteverständliche anweisungen) übersetzt wird und dadurch direkt auf dem Gerät ausgeführt werden kann, erfolgt die übersetzung einer android- oder Windows Pho-ne-anwendung zunächst in eine maschinenunab-hängige Zwischensprache, die später durch eine virtuelle Maschine auf dem Mobilgerät ausge-führt wird. Letztere ist eine weitere instanz, welche die Zwischensprache in maschinenverständliche anweisungen während der app-ausführung über-

2.1 Nativer entwicklungsansatz

Obj-C Java C#

10 11


Vorteile der nativen Entwicklung sind:

► hohes Potential das Look & Feel der Plattform zu erhalten sowie die erwartungskonformität zu erfüllen

► Zugriff auf jegliche im sDk angebotene Funktionalität

► Gute Performance

► Vermarktung über Distributionskanal der Platt-formstores inkl. bewertungssystem, hosting und accounting durch den store selbst

Nachteile der nativen Entwicklung sind:

► Niedrige Plattformreichweite

► Mehraufwand in der Gestaltung, entwicklung und Pflege. Im schlimmsten Fall x-fach, wobei x die anzahl der Zielplattformen darstellt. Daraus resultiert eine erhöhte time-to-Market. code und Oberflächen sind nicht auf weitere Plattfor-men übertragbar

► erfordert kompetenzen in den bereichen ver-schiedener Programmiersprachen, der platt-formspezifischen Gestaltung und der verschie-denen Werkzeuge

► Lizenzgebühren

► Margen für die Plattformhersteller für verkaufte apps oder app-inhalte

► review-Prozess und restriktionen durch die Plattformhersteller

Beispielhafte Werkzeuge

android studio

Netbeans

Visual studio

eclipse

Xcode

12 13


ansatz. Gegebenenfalls kann bereits auf bestehen-des Wissen aus dem bereich der Web-entwicklung aufgebaut werden.

Performance Die Performance von Webanwendungen ist ten-denziell schlechter als bei beispielsweise einer nati-ven Lösung. Dies hat zwei Gründe. erstens müs-sen die ressourcen von einem entfernten server auf das Gerät übertragen werden. hierbei kommt es stark auf die vorhandene Verbindungsgeschwin-digkeit an, ob die anwendung überhaupt gestartet werden kann und inwieweit es zu Verzögerungen kommt. Zweitens kann es durch den interpretati-onsvorgang bei der ausführung des clientseitigen codes je nach Menge des Quellcodes zu erhöhten ausführungszeiten kommen.

Distributionskanal ist der entwicklungsprozess durchlaufen und die anwendung bereit zur Veröffentlichung, kann bei dem webbasierten ansatz die app auf einem gemieteten Webserver bereitgestellt werden. im einfachsten Fall wird hier lediglich speicherplatz sowie eine UrL zum aufrufen der mobilen anwen-dung/Webseite benötigt. Je nach anwendung kön-nen aber auch weitere elemente wie PhP, ein Datenbanksystem etc. benötigt werden.

einmal auf einen Webserver hochgeladen muss lediglich die UrL zur entsprechenden mobilen Webseite verbreitet werden. Der Umweg über einen app-store ist hier nicht gegeben.

Entwicklungszeit Die Nutzung der Webstandards htML5, css3 und Javascript kann – sofern kompetenzen im entwicklerteam vorhanden sind – zu einer reduzie-rung der entwicklungszeit im Vergleich zur nativen Entwicklung führen. Ebenfalls kann bei der Pflege der Anwendung profitiert werden, da lediglich eine einzige Code-Basis gepflegt werden muss. Sollten allerdings Unterschiede zwischen den Plattformen vorhanden sein, welche beispielsweise die Platt-formspezifika imitieren, so ist dies mit einem Mehr-aufwand und einer höheren entwicklungszeit der Oberflächen verbunden.

Lizenzgebühren es fallen keine Lizenzgebühren für die entwicklung von webbasierten apps an.

Programmiersprache Die webbasierte anwendung wird mittels Webstan-dard-technologien wie htML5, css3 und Java-script erstellt. htML5 dient dabei der strukturie-rung einer app und css3 der Gestaltung, während Javascript für die anwendungslogik genutzt wird.

Entwicklungsvorgang Der erstellungsprozess ähnelt dem erstellungs-prozesses von typischen Webseiten für Desktops unter berücksichtigung der mobilen besonderhei-ten wie z. b. variierenden bildschirmgrößen. Die Gestaltung der Web-anwendung kann, sofern im editor vorhanden, einfach per WYsiWYG-Design (What You see is What You Get) oder per code erfolgen. Dem entwickler beziehungsweise Gestal-ter stehen dabei vielerlei benutzerschnittstellen per Web-standards zur Verfügung. hierdurch kön-nen konsistente benutzerschnittstellen über alle adressierbaren Plattformen hinweg erstellt werden. Diese sind allerdings auch als standardbedienele-mente zu erkennen. Plattformspezifische Steuer- elemente können nur nachgebildet werden. hier-für gibt es bereits einige Vorlagen und bibliotheken, die genutzt werden können. Zu beachten ist, dass jede adressierte Plattform dann ihre eigene Gestal-tung erhalten müsste, um eine gewisse erwar-tungskonformität zu erfüllen. Dies bedeutet aber auch einen gewissen Mehraufwand im rahmen der App-Entwicklung und -Pflege. Die Entwicklung der anwendungslogik erfolgt in Javascript. Der Zugriff auf Gerätefunktionalitäten ist auf die im htML5 definierten Schnittstellen beschränkt, wodurch nicht jede Funktionalität mittels des webbasierten ent-wicklungsansatzes umgesetzt werden kann.

bei diesem ansatz wird zwar davon gesprochen, dass Web-standards konsistent genutzt und dem-entsprechend durch einmaliges entwickeln nahezu alle Geräte bzw. Plattformen abgedeckt werden, allerdings gestaltet sich die realität wie bei den browsern im Desktop-bereich etwas anders. so haben zwar viele der mobilen browser in ihrer engine eine htML5-standard-implementierung, allerdings fällt die implementierung je nach brow-ser und Version unterschiedlich aus. Das heißt, dass nicht alle Funktionen des standards zwangs-läufig vorhanden sind. Dies muss während der Umsetzung beachtet werden.

Kompetenzbedarf Der kompetenzbedarf fällt für webbsaierte anwen-dungen deutlich geringer aus als bei der entwick-lung von apps für mehrere Plattformen mit nativem

zu gestalten, andererseits muss mit einem nega-tiven Einfluss auf die User Experience gerechnet werden. Dies liegt daran, dass Plattform-Spezifika wie der typische stil einer Plattform nicht vorhan-den sind. ein plattformtypisches Look & Feel ist deswegen kaum möglich, wodurch die erwartungs-konformität nur eingeschränkt gegeben ist.

Durch die Nutzung von plattformspezifischen Designs bzw. durch imitierung dieser kann aller-dings ein gewisser Grad an erwartungskonformität erreicht werden. ebenfalls ist es mittels des „Full-screen“-Modus sowie des Lesezeichen auf dem „home-screen“ möglich, den eindruck einer nati-ven app zu erwecken.

Entwicklungsumgebung Für den entwicklungsprozess können typische Quellcode-editoren wie adobe Dreamweaver, htML editor Phase, aptana studio etc. sowie weitere integrierte entwicklungsumgebungen (kurz: iDes) mit entsprechenden erweiterungen genutzt werden. eine Verwendung von bestimmten iDes ist, wie im Falle der nativen entwicklung, nicht notwendig.

Systemanforderungen Durch die freie auswahl der verwendeten Werk-zeuge ist es nicht notwendig, bestimmte systemvo-raussetzungen, wie den besitz eines Mac mit ins-talliertem Os X, zu erfüllen.

trotz vieler Unterschiede zwischen den Plattformen besitzt jede Plattform einen mobilen Web-browser. Diese Gemeinsamkeit macht sich der webbasierte entwicklungsansatz zu Nutzen, indem anwendun-gen mit Web-technologien erstellt und im mobilen Web-browser ausgeführt werden. Durch die gerin-gen Voraussetzungen hinsichtlich der ausführung einer Web-app (ein htML5-fähiger Web-browser) besitzt der webbasierte ansatz eine hohe Platt-formreichweite.

Architektur der App Der Web-browser dient für die Web-apps als Präsentationsmedium. Mittels einer UrL wird wie gewohnt eine Verbindung zu einem server herge-stellt und die gewünschte ressource aufgerufen. im einfachsten Fall wird lediglich eine htML-Web-seite von einem Webserver aufgerufen, welche innerhalb des browsers auf dem Mobilgerät darge-stellt wird. Mittels der skriptsprache Javascript ist es zudem möglich, clientseitigen code vom server zum mobilen Gerät, also dem browser, zu über-tragen. hierzu gehören interaktionsmöglichkeiten, die über einfache Verlinkungen hinausgehen sowie berechnungen auf dem Gerät.

Erwartungskonformität in der Web-entwicklung gibt es ein bestehendes set an standard-steuerelementen. Durch dieses standard-set ist es einserseits zwar möglich, kon-sistente Oberflächen über alle Plattformen hinweg

2.2 Webbasierter entwicklungsansatz

14 15


Vorteile der webbasierten Entwicklung sind:

► hohe Plattformreichweite

► kurze time-to-Market

► benötigt nur kompetenzen im bereich der Web-technologien

► keine Lizenzgebühren, die an Plattformherstel-ler gezahlt werden müssen

► keine Margen für Dritte für verkaufte apps oder app-inhalte

► kein review-Prozess oder restriktionen der Plattformhersteller

► aktualisierungsvorgang kann schnell durchge-führt werden

Nachteile der webbasierten Entwicklung sind:

► Look & Feel der Plattformen kann nur beschränkt imitiert werden

► Performanceeinbußen durch Verbindungsge-schwindigkeit und interpretationsaufwand

► User experience kann durch die mögliche Performance-einbußen und eventuell nicht- konsistentes aussehen leiden

► kein auftreten im app store

► sehr beschränkter Zugriff auf Gerätefunktiona-litäten

► Eigenorganisation des Hostings, Zahlungsflus-ses etc.

Beispielhafte Frameworks

Jo – Javascript Framework

sencha touch

Beispielhafte Editoren

aptana studio

Notepad

jQuery Mobile

Dreamweaver

Phase

16 17


bindungsverlusten. allerdings leidet die Perfor-mance durch den interpretationsaufwand des Java-script-Quellcodes.

Distributionskanal ist die hybride app entwickelt und soll veröffent-licht werden, greift aufgrund der app-architektur der Distributionsvorgang des nativen entwicklungs-ansatzes. so wird die app nach der Finalisierung beim hersteller eingereicht und durchläuft je nach Zielplattform einen review-Prozess, welcher über die aufnahme in den entsprechenden store ent-scheidet. Dies geschieht sowohl beim erstmaligen einstellen der anwendung als auch beim einstellen von aktualisierungen und kann eine gewisse Zeit in anspruch nehmen.

ist die anwendung angenommen, übernimmt der store das entsprechende hosting und die abrech-nungen. Zudem ist die app über den store zentral auffindbar. Darüber hinaus sind Bewertungsfunkti-onen vorhanden. Wird eine app oder ein app-inhalt gekauft, so werden auch hier Margen an den Platt-formhersteller gezahlt.

Entwicklungszeit Die entwicklungszeit kann sich durch den Web- anteil im Vergleich zur nativen entwicklung ver-ringern. Je mehr Gerätefunktionalitäten integriert werden sollen und je mehr davon nicht anderwei-tig beziehbar sind (z. b. aus vorhandenen biblio-theken, Frameworks etc.), desto mehr native Funk-tionen und Javascript-Nativ-brücken müssen entwickelt werden. Diese entwicklungen erhöhen die entwicklungszeit erheblich. Die entwicklungs-zeit sowie time-to-Market hängen damit maßgeb-lich von dem Verhältnis zwischen Web- und nativen Part ab.

Lizenzgebühren es fallen Lizenzgebühren für die entwicklung von hybriden apps an.

Programmiersprache als Programmiersprachen kommen sowohl die nativen Programmiersprachen als auch die Web-technologien zum einsatz. so werden in jedem Fall die Web-technologien htML5, css3 und Javascript für den Web-teil benötigt. Je nach Ziel-plattformen bedarf es auch Objective-c für iOs-apps, Java für android-apps und c# .Net für Windows Phone-apps als Programmiersprachen.

Entwicklungsvorgang Das entwicklungsvorgehen bildet eine Mischung aus dem Vorgehen des nativen und webbasier-ten entwicklungsansatzes. Je nach Verhältnis zwischen nativem und Web-Part setzen sich die schwerpunkte im jeweiligen entwicklungsansatz zusammen.

eine einfache Variante ist die entwicklung von Oberflächen und der Geschäftslogik mittels Web-technologien. hierbei liegt der schwerpunkt im webbasierten entwicklungsansatz. Der native bereich beschränkt sich auf die bereitstellung der Darstellungskomponente in Form einer WebView.

soll hingegen die Möglichkeit bestehen, auf Gerä-tefunktionen zuzugreifen und/oder soll die Gestal-tung plattformspezifisch erfolgen, so verschiebt sich der schwerpunkt auf die native entwicklung. Zudem wird es erforderlich, die jeweiligen schnitt-stellen zwischen Web-teil und nativem teil (samt Javascript-Nativ-brücken) zu implementieren. Für typische anwendungsfälle gibt es bereits diverse bibliotheken. Für weniger typische Fälle muss dies im Zweifel selbst implementiert werden.

Kompetenzbedarf Der kompetenzbedarf liegt über dem des reinen webbasierten entwicklungsansatzes, da bei die-sem ansatz sowohl Web-entwicklung als auch die native entwicklung bekannt sein müssen. Das know-how zur nativen entwicklung muss in ein-fachen Fällen gar nicht so weit ausgeprägt sein. Wichtig ist, dass die basics der jeweiligen Zielplatt-form sowie das Werkzeug bekannt sind und mit diesen entwickelt werden kann. Je nachdem wel-che weiteren Funktionalitäten der Plattform bzw. des Gerätes genutzt werden sollen, wird entspre-chendes know-how erforderlich.

Performance Eine hybride Anwendung selbst ist offline ausführ-bar und leidet somit nicht wie die Web-app unter der Verbindungsgeschwindigkeit bzw. den Ver-

lung kann eine hohe erwartungskonformität bezüg-lich der Plattform erreicht werden. Dies ist aller-dings mit einem höheren aufwand verbunden.

Entwicklungsumgebung Die entwicklung für die jeweiligen teilberei-che erfolgt jeweils wie im nativen und webbasier-ten ansatz bereits beschrieben. Dazu werden zum einen die Werkzeuge der nativen entwick-lung benötigt. Dies bedeutet, dass beispiels-weise für eine hybride iOs-app auch das entspre-chende iOs-sDk sowie Xcode, für eine hybride android-app das android-sDk sowie eclipse mit aDt-Plugin oder android studio und für eine hybride Windows Phone-app entsprechend Windows Phone-sDk und Visual studio vorhan-den sein müssen. Zudem werden gegebenenfalls htML-editoren oder erweiterungen für die beste-henden IDEs benötigt, um den Web-Part effizient implementieren zu können.

Anforderungen und Voraussetzungen Da ein teil der app nativ entwickelt wird und deswegen entsprechende sDks sowie iDes ver-wendet werden müssen, gelten auch hier wie in der nativen entwicklung bestimmte Voraussetzun-gen. so ist der besitz eines Mac mit installiertem Os X 10.7 oder höher Version für die entwicklung von iOs-anwendungen und ein Pc mit installiertem Windows 8 Pro betriebssystem in der 64-bit- Version für die Windows Phone-entwicklung nötig.

Der hybride entwicklungsansatz ist ein kompro-miss zwischen dem nativen und webbasierten ent-wicklungsansatz. Ziel des hybriden ansatzes ist es, die negativen aspekte des nativen oder webbasier-ten ansatzes durch (positive) aspekte des jeweils anderen ansatzes auszugleichen. Mit dem hybri-den entwicklungsansatz können Webanwendun-gen offline verfügbar gemacht sowie um Geräte-funktionen erweitert werden.

Architektur der App eine hybride anwendung besteht sowohl aus einem nativen als auch aus einem Web-teil. Der native teil entspricht einer containeranwendung, die im einfachsten Fall lediglich eine WebView beinhaltet. hierbei handelt es sich um eine kom-ponente, die ähnlich wie der Webbrowser Webin-halte darstellen kann. in der WebView-komponente wird dann die eigentliche anwendung ausgeführt. Dazu muss mit dieser komponente lediglich die entsprechende ressource (z. b. der startbildschirm als htML5-Datei) aufgerufen werden. Die htML- Dateien liegen mit allen weiteren ressourcen wie den CSS- und JavaScript-Dateien sowie Grafiken der anwendung bei.

Erwartungskonformität bei einer konsistenten Gestaltung mittels Web-technologien ist das Look & Feel der Plattform sowie die erwartungskonformität nicht unmittelbar gegeben. Die anmutung könnte imitiert werden. bei der Oberflächengestaltung mittels nativer Entwick-

2.3 hybrider entwicklungsansatz

Web-view

Web-view

Web-view

18 19


Vorteile der hybriden Entwicklung sind:

► hohe Plattformreichweite

► kann eine kurze time-to-Market haben

► bessere Performance als Web-apps aufgrund fehlender Verzögerungen

► Notwendigkeit für eine bestehende internet- verbindung im Vergleich zu Web-apps nicht gegeben

► Potential zum erhalt der erwartungskonformität gegeben

► Vermarktung über Distributionskanal der Platt-formstores inkl. bewertungssystem, hosting und accounting durch den store selbst

► Zugriff auf alle Gerätefunktionalitäten

Nachteile der hybriden Entwicklung sind:

► schlechtere Performance als bei nativen apps aufgrund des interpretierten Parts

► Die Flexibilität der Webanwendung, welche lediglich auf einen Webserver bereitgestellt werden mussten, entfällt

► benötigt sowohl kompetenzen im bereich der Web-technologien als auch der nativen ent-wicklung

► Lizenzgebühren an, die an Plattformhersteller gezahlt werden müssen

► beim Verkauf von apps oder app-inhalten müssen Margen an die Plattformhersteller gezahlt werden

► review-Prozesse müssen durchlaufen werden hinsichtlich der restriktionen der Plattformher-steller

► User experience kann durch die mögliche Per-formance-einbußen und eventuell nicht-konsis-tentes aussehen leiden

► Performance-einbußen durch den interpretationsaufwand

Beispielhafte Werkzeuge

PhoneGap

Mosync

titanium

20 21


Der übersetzungsansatz ähnelt dem des modelge-triebenen ansatz oder der weiteren programmati-schen ansätze (nativ, hybrid, webbasiert, interpre-tiert) insofern, dass apps für alle Plattformen aus einer einzigen codebasis erstellt werden, indem die codebasis in die verschiedenen Zielsprachen übersetzt wird.

Durch diese ansätze verspricht man sich insbeson-dere aufwände zu reduzieren sowie kompetenz- defizite ausgleichen zu können.

ein weiterer ansatz ist die interpretation von code auf der Zielplattform mittels einer interpretierenden einheit. eine Variante dessen stellt der webbasierte ansatz mittels Webbrowser dar. Die Form der inter-pretation kann dabei auf mehrere Weisen erreicht werden. Die erste Form besteht dabei aus einem Paket, welches sowohl die app, als auch den inter-preter selbst, beinhaltet. ein anderer ansatz ist die bereitstellung einer app-übergreifenden „virtuellen Maschine“, dies ist allerdings nicht überall möglich. Diese virtuelle Maschine agiert als Laufzeitumge-bung, welche bytecode verarbeitet. Der bytecode ist dabei eine plattformunabhängige Zwischenspra-che zwischen der höheren Programmiersprache und dem Maschinencode, welche wiederum platt-formunabhängig ausgeführt wird. Die aufgabe des interpreters bzw. der VM liegt dabei in der Vermitt-lung der jeweiligen Funktionsaufrufe zwischen der gegebenen Laufzeitumgebung und dem betriebs-system während der Laufzeit.

Weitere entwicklungsansätze wie der „Do it yourself“-ansatz, übersetzungsansätze mittels cross-compiler oder aber auch ein modelgetrieber ansatz resultieren in einen der bereits beschriebe-nen app-architekturen. so können beispielsweise native, webbasierte, hybride oder interpretierte apps erstellt werden, welche die entsprechen-den Vor- wie auch Nachteile der jeweiligen archi-tekturen haben können. inwieweit dies der Fall ist, hängt allerdings von der Qualität und dem Funkti-onsumfang der Werkzeuge ab, welche diese weite-ren entwicklungsansätze verfolgen. Das Ziel dieser ansätze ist es, auf verschiedene Weisen zeitspa-rend zu resultaten auf möglichst allen Plattformen zu kommen.

so bietet der DiY-ansatz meist über einen Webser-vice die Möglichkeit, anhand eines baukastens die gewünschte app zusammenzuklicken. so kann aus einer Palette an vordefinierten Designs, Menüs und Funktionen gewählt und schrittweise die eigene app erstellt werden.

Der modelgetriebene ansatz verspricht, ohne oder mit wenig Feinabstimmung aus den erstell-ten, abstrakten Modellen, welche die resultierende app beschreiben, entsprechenden Quellcode oder direkt die app für die gewünschten Plattformen zu generieren.

2.4 Weitere entwicklungsansätze

22 23


3 Autoren

rafael Pisarczyk absol-vierte 2012 das informa-tikstudium im Master- studiengang information systems engineering an der Fh aachen. er forscht seit seinem abschluss im rahmen des Projektes kompUeterchen4kMU mit seinen kollegen im m2c-lab der Fh aachen an Möglichkeiten, die Diszip- linen Usability und soft-

ware engineering für die entwicklung von mobilen anwendungen zu verbinden. Zurzeit beschäftigt er sich für dieses Projekt mit den aspekten der Multi- plattform-entwicklung.

Prof. Dr.-ing. thomas ritz arbeitete nach seinem stu-dium der informatik zunächst als wissenschaft-licher Mitarbeiter für die Universität stuttgart und später beim Fraunhofer institut für arbeitswirtschaft und Organisation. Dort baute er maßgeblich das Fraunhofer iaO m-Lab mit auf. 2004 wurde er an die Fh aachen berufen. seine

Forschungs- und beratungstätigkeiten konzentrie-ren sich auf mobile Unternehmenssoftware und benutzerzentrierte Methoden zur entwicklung sol-cher systeme. Das von Prof. ritz geleitete mobile media & communication lab (m2c-lab) an der Fh aachen beschäftigt sich mit innovativen Fragestel-lungen rund um mobile und internetbasierte infor-mationssysteme.

ramona Wallenborn studierte communication and Multimedia Design an der Fh aachen und hogeschool Zuyd in Maastricht. seit abschluss des bachelor-studiums 2010 arbeitet sie als wissenschaftliche Mitarbeiterin für das mobile media & commu-nication lab (m2c-lab) der Fh aachen. Dort unter-

stützt sie die Organisation von Projekten im bereich (e)Mobilität und Mass customization und ist in diesen bereichen mit der entwicklung innova-tiver konzepte, der erstellung von business Models sowie der Mensch-Maschine-schnittstelle für mobile informationssysteme vertraut. seit 2012 studiert sie berufsbegleitend den Masterstudien-gang Marketing and communications an der FOM in Düsseldorf.

24 25


4 Quellen

► 8tracks (2014): the Writer‘s Journey. UrL: htt-p://8tracks.imgix.net/i/002/006/100/fountain-pen-on-paper-3665.jpg?q=65&sharp=15&vib=10&f-m=jpg&fit=crop. Abruf am 23.04.2014.

► android (2014): android Design. UrL: http://developer.android.com/design/style/index.html. abruf am 22.05.2014.

► android studio (2014): Getting started with and-roid studio. UrL: http://developer.android.com/sdk/installing/studio.html. abruf am 22.05.2014.

► apple (2014): Designing for iOs 7. UrL: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobilehiG/index.html. abruf am 22.05.2014.

► aptana (2014): aptana studio 3. UrL: http://aptana.com/. abruf am 22.05.2014.

► bishop, J./horspool, N. (2006): cross-Platform Development – software that Lasts. in: compu-ter. Volume 39. issue 10. ieee. seite 26-35.

► charland, andre/Leroux, brian (2011): Mobile application development: web vs. native. in: communications of the acM. Volume 54. issue 5. Mai 2011. seite 49-53.

► contegix (2014): by 2017 connected devices will outnumber people. UrL: http://www.cont-egix.com/by-2017-connected-devices-will-out-number-people/. abruf am 23.04.2014.

► Doolittle, Joseph/Moohan, aideen/simpson, John/soanes, ian (2012): building a Mobile application Development Framework. it@intel White Paper cloud computing and compute continuum august 2012.

► Dreamweaver (2014): Dreamweaver cc. UrL: http://www.adobe.com/de/products/dreamwea-ver.html. abruf am 22.05.2014.

► eclipse (2014): eclipüse articles, tutori-als, Demos, books and More. UrL: http://wiki.eclipse.org/eclipse_articles,_tutori-als,_Demos,_books,_and_More. abruf am 22.05.2014.

► Feldmann, thorsten/solmecke, christian/tager, Jürgen (2013): Mobile apps – rechtsfragen und rechtliche rahmenbedingungen. De Gruyter. berlin 2013.

► Franke, Florian/ippen, Johannes (2012): apps mit htML5 und css3 – für iPad, iPhone und android. Galileo Press, bonn 2012.

► Friberg, Philipp (2013): Web-apps mit jQuery Mobile – Mobile Multiplattform-entwicklung mit htML5 und Javascript. heidelberg. 2013.

► Gagern, stefan von (2012): cross-Plattform entwicklung: eine app für alle?. UrL: https://www.developergarden.com/de/blog/artikel/article/cross-plattform-entwicklung-eine-app-fu-er-alle/. abruf am 22.05.2014.

► heise (2014): studie: htML5 ist in der Multip-lattform-entwicklung gesetzt. UrL: http://heise.de/-2111598, abruf am 22.05.2014.

► heitkötter, henning/hanschke, sebas-tian/Majchrzak, tim a. (2012): comparing cross-platform Development approaches for Mobile applications. in: 8th international confe-rence on Web information systems and techno-logies (Webist) 2012. seite 299-311.

► hering, Dirk/ruch, tobias/teich, alexan-der/springer, thomas (2012): Mehr als nur Geschmacksache. apps plattformübergreifend entwickeln. iX. 7/2012. seite 108-113.

► huy, Ngu Phuc/van thanh, Do (2012): Develo-ping apps for mobile phones. in 2012 7th inter-national conference on computing and conver-gence technology (iccct). ieee. Dezember 2012. seite 907-912.

26 27


► statista (2014a): anzahl der Downloads mobi-ler apps in Deutschland in den Jahren 2009 bis 2012 und Prognose für 2014 (in Millionen). UrL: http://de.statista.com/statistik/daten/stu-die/168038/umfrage/anzahl-der-downloads-mo-biler-apps-in-deutschland-seit-2009/, abruf am 120.08.2014.

► statista (2014b): Marktanteile der mobilen betriebssysteme am absatz von smartphone in Deutschland von januar 2012 bis Februar 2014. UrL: http://de.statista.com/statistik/daten/stu-die/225381/umfrage/marktanteile-der-betriebs-systeme-am-smartphone-absatz-in-deutsch-land-zeitreihe/. abruf am 23.04.2014.

► techterms (2013): Platform. UrL: http://www.techterms.com/definition/platform. Abruf am 22.04.2014.

► titanium (2014): titanium Mobile Development environment. UrL: http://www.appcelerator.com/titanium/. abruf am 22.05.2014.

► tittel, Jan/baumann, Jochen (2013): apps für iOs entwickeln – am beispiel einer realen app. hanser. München 2013.

► Visual studio (2014): Visual studio. UrL: http://www.visualstudio.com/. abruf am 22.05.2014.

► Werler, sebastian (2012): einer für alle – best Practices für die cross-Plattform-app-entwick-lung. iX Developer. März 2012. seite 126-131.

► Xcode (2014): Xcode – the complete toolset for building great apps. UrL: https://developer.apple.com/Xcode/. abruf am 22.05.2014.

► Olson, scott/hunter, John/horgen, ben/Goers, kenny (2012): Professional cross-Platform Mobile Development in c#. John Wiley & sons, Inc. Erstauflage.

► Phase 5 (2014): Phase 5 <htML-editor>. UrL: http://www.phase5.info/. abruf am 22.05.2014.

► PhoneGap (2014): PhoneGap. UrL: http://pho-negap.com/. abruf am 22.05.2014.

► Pisarczyk, rafael (2013): ansätze der entwick-lung von Multiplattform-anwendungen. UrL: http://www.ebusiness-lotse-aachen.de/sites/default/files/mediathek/Ansa%CC%88tze%20zur%20Multiplattform-Entwicklung.pdf. Abruf am 22.05.2014.

► ritz, thomas (2013): Multiplattformentwick-lung für mobile informationssysteme – eine strategische Perspektive. UrL: http://www.ebusiness-lotse-aachen.de/sites/default/files/mediathek/Strategische%20Perspektive%20zur%20Multiplattform-Entwicklung.pdf. Abruf am 22.05.2014.

► ross, Markus (2013): Phone Gap – Mobile cross-Plattform-entwicklung mit apache cor-dova & co. dpunkt.verlag.

► sencha touch (2014): sencha touch. UrL: http://www.sencha.com/products/touch/. abruf am 22.05.2014.

► sin, D./Lawson, e./kannoorpatti, k. (2012): Mobile Web apps - the Non-programmer‘s alternative to Native applications. in 2012 5th international conference on human system interactions (hsi). ieee. Juni 2012. seite 8-15.

► springer, sebastian (2012): systemunabhän-gige Web-apps mit htML5, css 3 und Java-script. iX Developer. März 2012. seite 132-136.

► ibM corporation (2012): Native, web or hyb-rid mobile-app development. ibM, april 2012.UrL: ftp://ftp.software.ibm.com/software/sg/WsW14182UseN.pdf. abruf am 24.09.2012.

► Jo (2014): Jo app. UrL: http://joapp.com/. abruf am 22.05.2014.

► jQuery mobile (2014): jQuery mobile. UrL: http://jquerymobile.com/. abruf am 22.05.2014.

► köhler, andré/Gruhn, Volker (o.D.): Mobile Pro-cess Landscaping am beispiel von betriebs-prozessen in der assekuranz. UrL: http://lips.informatik.uni-leipzig.de/files/Khler2004Mobile-ProcessLandscapingambeispielvonVertriebs-prozessen.pdf. abruf am 23.04.2014.

► kuli (2011): buchausstellungen. UrL: http://kuli-buch.at/wp-content/uploads/2012/11/kunden_buecher.jpg. abruf am 23.04.2014.

► Microsoft (2014): Design principles. UrL: https://dev.windowsphone.com/en-us/design/principles. abruf am 22.05.2014.

► Mosync (2013): app development made easy. UrL: http://www.mosync.com/. abruf am 22.05.2014.

► Neowin (2012): taking Windows 8 into the enterprise: the good, th bad, and the Modern Ui. UrL: http://www.neowin.net/news/taking-windows-8-into-the-enterprise-the-good-the-bad-and-the-modern-ui. abruf am 23.04.2014.

► Netbeans (2014): Netbeans iDe – the smarter and Faster Way to code. UrL: https://netbeans.org/. abruf am 22.05.2014.

► Notepad++ (2011): Notepad++. UrL: http://notepad-plus-plus.org/. UrL: http://notepad-plus-plus.org/. abruf am 22.05.2014.

28

Unterschiedliche Entwicklungsansätze von Multiplattform-Anwendungen

Das eKompetenz-Netzwerk für Unternehmen

Die Förderinitiative ist teil des Förderschwerpunkts „Mittelstand-Digital – ikt-anwendungen in der Wirt-schaft“. Zu „Mittelstand-Digital“ gehören ferner die Förderinitiativen „estandards: Geschäftsprozesse standardisieren, erfolg sichern“ (16 Förderprojekte) und „einfach intuitiv – Usability für den Mittelstand“ (13 Förderprojekte). Unter www.mittelstand-digital.de können Unterneh-men sich über die aktivitäten der ebusiness-Lotsen informieren, auf die kontaktadressen der regiona-len ansprechpartner sowie aktuelle Veranstaltungs-termine zugreifen oder auch Publikationen einse-hen und für sich herunterladen.

Documents

Unterschiedliche entwicklungsansätze von Multiplattform … · 2020. 4. 28. · der hybride entwicklungsansatz. Darüber hinaus gibt es weitere ansätze der Multi-plattform-entwicklung,