Noch stehen Sie ganz am Anfang und vermutlich treibt Sie eine AppIdee ziemlich zügig zur Frage, auf welcher Plattform – Apples iOS oder Googles Android – Sie Ihre Idee entwickeln und umsetzen möchten. Oder aber Sie möchten eine bestehende Applikation auch auf anderen Plattformen anbieten. In beiden Fällen stellt sich dann die Folgefrage, wie eine geeignete, plattformspezifische Navigation ausschauen könnte, um Benutzern eine intuitive Bedienung zu ermöglichen. Um diese manchmal nicht ganz einfache Entscheidung treffen zu können, ist es wichtig, dass Sie die gängigsten Navigationsmodelle1 kennen. Lernen wir sie kennen:

1. Die Baumstruktur
2. Die Tab-Bar-Navigation
3. Die Blatt-für-Blatt-Navigation
4. Die Grid-Navigation
5. Die Sidebar-Navigation
6. Das Dashboard
7. Kombinierte Navigationsmodelle
8. Apps mit individueller Navigation

1.1 Die Baumstruktur

Vergleichen Sie die Baumstruktur mit dem Aufbau eines Baums, den der User bis zum Gipfel emporklettert. Immer wieder trifft er auf Astgabelungen, an denen er sich für den weiteren Weg entscheiden muss. Die Baumstruktur bietet also eine hierarchische Nutzerführung, die – meist in Listenform dargestellt – von einem Screen zum nächsten führt, bis der Zielbildschirm erreicht ist.(2) Eines ist allerdings klar: Die Baumstruktur zählt nicht unbedingt zu den spannendsten, aber sicher zu den bewährtesten Navigationsmodellen im App-Design. Sie ist eine hervorragende Wahl für eine übersichtliche Darstellung mehrerer Kategorien. Gleichwertige Informationsblöcke können hier in nach unten scrollbaren Listen aufgeführt werden, bei denen der User über die jeweiligen Listeneinträge in tiefer liegende Hierarchieebenen gelangt. Mit dem Zurück-Button der Navigations- oder der App-BarLeiste (je nach System) navigiert er hierarchisch wieder zurück.(3)

Abb. 1.1: Beispiele für eine Navigation mit Baumstruktur auf dem iPhone – Elevatr, Nachrichten, Notizen

Abb. 1.2: Android-Beispiele für eine Hauptnavigation in Form der Baumstruktur: Messenger, Koalcat’s Clear und die Android-Einstellungen

1.2 Die Tab-Bar-Navigation

Mithilfe der Tab-Bar-Navigation machen Sie die wichtigsten Navigationspunkte jederzeit für den Benutzer erreichbar, denn wie das Wörtchen Bar beschreibt, ist eine permanente Leiste am oberen oder unteren Bildschirmrand vorhanden und mit Tabs, sprich Schaltflächen, bestückt. Je nach Inhalt der App vereinen diese Tabs also grundlegende Funktionen oder Modi und sind aus jeder Ebene heraus bedienbar. Ein gutes Beispiel zeigt sich in der App Kitchen Stories, die die fünf wichtigsten Funktionen in einer Tab Bar unterbringt, nämlich Rezepte, Küchentipps, Meine Rezepte, Einkaufsliste und Grundlagen. Wenn Ihre App zu wenige gleichrangige Navigationspunkte beinhaltet, um den App-Bildschirm zu füllen, und in naher Zukunft auch keine neuen Punkte geplant sind, bietet sich eine Tab-Bar-Navigation an.(4)

Abb. 1.3: Beispiele für iPhone-Apps, die eine Tab Bar nutzen: Kitchen Stories, Musik-App, Twitter

Abb. 1.4: Beispiele für Android-Apps, die eine Tab-Bar-Navigation mit Icon oder Texttabs nutzen: Kontakte-App, Timely und Skype


Abb. 1.5: Der Mehr-Button innerhalb der Tab Bar am Beispiel der iPhone-App iTunes Store. Dieser öffnet eine Liste weiterer Navigationspunkte

1.3 Die Blatt-für-Blatt-Navigation

Abb. 1.6: Ein vereinfachtes Schema für die Blatt-für-Blatt-Navigation

Im Gegensatz zur hierarchischen Baumstruktur bietet die Blatt-für-BlattNavigation weniger verzweigte Auswahlmöglichkeiten für den User. Die flache Hierarchie lässt im Grunde nur zwei Möglichkeiten offen: nach links oder rechts. Vergleichbar ist die Blatt-für-Blatt-Navigation mit auf dem Schreibtisch aufgereihten Papierblättern, von denen immer nur eines sichtbar ist. Für Apps mit überschaubaren und vor allem gleichwertigen Inhalten ist die Blatt-für-Blatt-Navigation eine solide, einfach zu bedienende Lösung. In vielen Wetter-Apps zum Beispiel lassen sich sämtliche Städte durch bequemes Swipen, also durch Wischbewegungen mit dem Finger, durchblättern und jeweils in voller Bildschirmgröße darstellen. Die Blatt-für-Blatt-Navigation verhält sich allerdings linear, das heißt: User müssen unter Umständen ein Dutzend Wischbewegungen ausüben, um ans Ziel zu gelangen. Bewährt hat sich dieses Modell bei maximal sieben bis neun Seiten (den sogenannten Flat Pages) – je weniger, desto besser.

Abb. 1.7: In den iPhone-Apps Wetter, Regenschirm und Tipps navigieren User mit horizontalen Wischbewegungen durch die Blatt-fürBlatt-Navigation

Wenn Ihnen die Blatt-für-Blatt-Navigation zwar gefällt, sie aber nicht infrage kommt, weil Sie zehn oder mehr Flat Pages verwenden müssten, ist die Grid-Navigation im nächsten Abschnitt eine gute Alternative.

1.4 Die Grid-Navigation

Die Grid- oder auch Rasternavigation bietet Ihnen eine hervorragende Möglichkeit der Darstellung homogener Inhalte, beispielsweise für Bildergalerien. Für den User ergibt sich ein übersichtliches Gesamtbild vieler Navigationspunkte, die rasterförmig und durchaus auch nach unten hin scrollbar in Erscheinung treten und dadurch beliebig erweitert werden können.(5) Wie bereits erwähnt ist die Grid-Navigation eine wunderbare Alternative zur Blatt-für-Blatt-Navigation, aber auch zur Baumstruktur, die ebenfalls auf gleichgewichtete Inhalte setzt und durch vertikales Scrollen bedient werden kann. Im Hauptunterschied zur Baumstruktur stellt die Grid-Navigation Bilder (auf sogenannten Cards oder Karten) – und keine Textelemente – in den Vordergrund, um Inhalte zu differenzieren. Fix in ihrer Breite (ein- oder zweispaltig), aber variabel in der Höhe, können Inhalte unterschiedlich gewichtet werden. Die Grid-Navigation konnte sich überwiegend in Android-Apps etablieren und findet nur sporadischen Einsatz in iPhone-Apps.

Abb. 1.8: iPhone-Apps wie die von Google, Heyday und Expedia stellen den mit Bildern gefüllten, nach unten scrollbaren Inhalt in den Vordergrund.

Abb. 1.9: Android-Apps wie Google, Pinterest und Google+ nutzen eine nach unten scrollbare, ein- bzw. zweispaltige Grid-Ansicht

1.5 Die Sidebar-Navigation

Spätestens seit der durch Facebook eingeführten Sidebar-Navigation6 zählt diese zum gängigen Repertoire an Modellen, die Ihnen für Ihre App zur Verfügung stehen. Der Clou an dieser Navigation ist, dass sie zunächst überhaupt nicht sichtbar ist, sondern erst durch eine Useraktion erscheint. Durch Betätigung des links oben platzierten, sogenannten Hamburgerbuttons (Abbildung 1.12) schiebt sich der dargestellte Inhalt aus dem Screen heraus nach rechts, um Platz für eine scrollbare, mit beliebig vielen Navigationspunkten gefüllte Liste zu bereiten. Die sehr komfortable und durch namhafte Apps wie Gmail oder Spotify etablierte Bedienmöglichkeit macht auch die nachträgliche Implementierung neuer Navigationspunkte leicht möglich. Mit Aufkommen der Sidebar-Navigation haben sich auch einige Synonyme etabliert, von denen Sie zukünftig vielleicht noch hören und lesen werden. Es handelt sich also nicht um Wissenslücken, wenn Ihnen Hamburgermenü, Navigation Drawer oder versteckte Navigation über den Weg laufen, sie alle meinen das Gleiche: die Sidebar-Navigation.

Abb. 1.10: iPhone-Apps mit Sidebar-Navigation: YouTube, Google+ und Zalando

Abb. 1.11: Auch die Android-Apps Kalender, Hotel Tonight und Google Maps setzen auf Sidebar-Navigation


Abb. 1.12: Gut zu wissen: Der Hamburgerbutton heißt deswegen so, weil er genau wie ein Burger aus drei Teilen besteht: Brötchen – Patty – Brötchen

Abb. 1.13: Die AutoScout24-App für iOS umgeht das Problem erschwerter Auffindbarkeit, indem die versteckte Navigation unmittelbar nach dem Start angezeigt wird.

So klappt’s auch mit der iOS-Sidebar-Navigation

Obwohl die Sidebar-Navigation in den Human Interface Guidelines weder Erwähnung noch Definition erfährt, akzeptiert Apple deren Einsatz – ein Ablehnungsgrund für Ihre App sind Hamburger und versteckte Navigation also nicht. Ein möglicher Grund für das Scheitern einer App allerdings schon – denn dort, wo es an Regeln fehlt, regiert das Chaos. Lassen Sie uns einen kleinen Ausflug unternehmen und uns einige Beispiele anschauen, wie Sie eine Sidebar-Navigation in iOS besser nicht umsetzen, wenn schmackhafte Hamburger nicht zu wässrigen Suppen verkümmern sollen. Natürlich werfen wir im Anschluss auch einen Blick auf den Big Mac unter den Sidebar-Navigationen – und zwar in der iOS-App von Instapaper.

Überraschung: Navi erwartet, Overlay geliefert

Die iOS-App Zite ist eine hervorragende App, um Blognews zu verfolgen. Verwirrend ist allerdings, dass sich hinter dem Hamburgericon, der in Userköpfen nun mal als eindeutiger Navigationsstart verankert ist, ein halbtransparentes Listen-Overlay auftut. Und Schreck lass nach, was macht denn die Tab Bar da unten? Wir wollten doch navigieren!

Abb. 1.14: Die iOS-App Zite stiftet Verwirrung nach Betätigung des Hamburgericons.

Zweimal anschnallen bitte: die Doppelmoppel-Navigation

Anders als Zite versteckt die airberlin-App hinter dem Hamburgericon tatsächlich eine Sidebar-Navigation. Das ist schon einmal beruhigend. Allerdings findet sich dort in den ersten vier Navigationspunkten nichts, was es nicht auch schon auf der Startseite gegeben hätte. Ob die Abflugzeiten hier andere sind? Die Sidebar-Navigation ist hier eigentlich überflüssig und vielleicht hätte man besser auf eine Tab Bar oder die Baumstruktur gesetzt.

Abb. 1.15: Die iOS-App vor Air Berlin ist in Sachen Sidebar-Navigation kein Vorbild

Herr Ober, einen Kabelsalat bitte!

Ganz unten im Nährwertbereich befinden wir uns mit der Navigation von Flipp. Zum einen hat das Hamburgericon eine völlig andere Funktion, denn statt zu navigieren, können User hier filtern, und zum anderen wechselt die Bezeichnung des Hamburgericons je nach Auswahl. Entsprechend dem Usergusto schmeckt der Hamburger also nach Auto, T-Shirt oder Kabeln. Ein Filtericon wäre hier sicherlich besser platziert gewesen.

Abb. 1.16: Flipp nutzt das Hamburgericon als Filterfunktion. Keine sehr gute Idee

Fehlgeleitet: Navigationsbutton in Yahoo News Digest

Die iOS-App Yahoo News Digest ist klasse, die Funktion des Hamburgerbuttons aber ein Desaster. Rechts oben platziert, beherbergt der Button keine Navigation, sondern einen halb transparenten, animierten Countdown bis zum nächsten Newsfeed. Über die Gestirnsymbole unterhalb können News vergangener Tage betrachtet werden. Mit der erwarteten Navigation in Listenform hat das alles aber herzlich wenig gemeinsam.

QuizUp: Raten Sie mal, wie ich funktioniere!

Nun gut, zumindest bringt der Hamburgerbutton von QuizUp eine Sidebar-Navigation zum Vorschein. Allerdings ist das Icon rechts oben platziert und an üblicher Stelle – nämlich links oben – befindet sich stattdessen ein Zurück-Button, der wiederum auf der ersten Navigationsebene den ersten Punkt der Sidebar öffnet, also stets den Startbildschirm. Das stiftet bei Usern sicherlich Verwirrung und steht dem intuitiven Einsatz der App etwas im Wege.

Abb. 1.17: Yahoo News Digest führt die Sidebar-Navigation ad absurdum

Abb. 1.18: Die kniffligste Frage von QuisUp für iOS lautet: Wie funktioniert meine Navigation? Antwort: seltsam

Instapaper – der Big Mac unter den Hamburgerbuttons

Stellvertretend für AutoScout24, Booking.com oder auch Headspace liefert die iOS-App Instapaper ein Positivbeispiel dafür, wie Hamburgericons und Sidebar-Navigation eingesetzt werden sollten, um intuitive Bedienung zu ermöglichen. Der Button befindet sich stets links oben und öffnet bei Betätigung eine Navigation in Listenform, und das ohne Filter, App Bars oder andere Haare in der Suppe. Auch der zuletzt besuchte Screen ist teilweise noch sichtbar und schafft Orientierung. Der Button ist unverfremdet, eindeutig und völlig klar in seiner Funktionsweise. Hier schmeckt der Hamburger noch so, wie man ihn als User kennen und lieben gelernt hat.

Abb. 1.19: In Instapaper findet sich ein abschließendes, positives Beispiel für eine Sidebar-Navigation im iOS-System

Ist die Sidebar-Navigation für meine App geeignet?

Sicher, die Sidebar-Navigation ist ziemlich trendy. Und auch der Gedanke, Facebook habe durch deren Einführung eine breite Userbasis geschaffen, die intuitiv mit dieser Art der Navigation zurechtkommt, ist nicht ganz von der Hand zu weisen. Dennoch sollten Sie sich die folgenden Fragen stellen, bevor Sie eine Sidebar-Navigation implementieren.

• Passt die Sidebar-Navigation zu meinen Inhalten oder wird die App dadurch nur künstlich aufgebläht? Sind vielleicht gleichgewichtete Inhalte nicht doch besser in einer Grid- oder Baumstruktur aufgehoben?
• Ist die Sidebar als primäre Navigationsart sinnvoll oder rein kosmetischer Natur, mit der lediglich Navigationspunkte versteckt werden sollen?
• Beinhaltet meine Navigation möglicherweise so viele Inhalte, dass User die Sidebar mehr als drei Mal herunterscrollen müssen, um an alle Inhalte zu gelangen?
• Ist meine Zielgruppe mit der Sidebar-Navigation vertraut oder handelt es sich möglicherweise um User, die üblicherweise keine Berührungspunkte mit Facebook und Co. haben?

Und übrigens: Facebook ist inzwischen längst zur Tab-Bar-Navigation zurückgekehrt, gilt aber als Begründer der Sidebar-Navigation und führte sie seinerzeit für ihre iOS-App ein.

1.6 Das Dashboard

Bereits 2010 erschien eine unter dem Namen Dashboard bekannte Navigationsart. Auf einem Dashboard werden mindestens zwei, höchstens sechs Navigationspunkte abgebildet, die jeweils durch ein Icon und einen kurzen Text ausgezeichnet werden. Dadurch finden sämtliche Funktionen und Menüs übersichtlich direkt auf dem Startbildschirm ihren Platz. Bis auf die Reihenfolge, in der sie erscheinen, sind die Inhalte des Dashboards allerdings gleichwertig, was es erschwert, einen Fokus zu setzen oder Hauptanwendungen hervorzuheben. Das Dashboard-Modell eignet sich aus diesem Grund nicht für alle Apps und gilt mittlerweile als veraltet.

Abb. 1.20: Die iPhone-Apps Kompakt, Dots und Lufthansa verfügen über eine Dashboard-Navigation

1.7 Kombinierte Navigationsmodelle

Sechs Navigationsarten haben Sie bereits kennengelernt. Und jede für sich bietet ganz eigene Möglichkeiten, um die Inhalte Ihrer App benutzerfreundlich und vor allem zugänglich zu gestalten. Das Schönste daran ist aber, dass Sie sich überhaupt nicht auf eines dieser Modelle festlegen müssen, denn auch Kombinationen aus mehreren Navigationsarten sind möglich und können durchaus sinnvoll sein. Es spricht zum Beispiel nichts dagegen, die Tab Bar als primäre Navigation zu nutzen, über die User zu einer Galerie gelangen, die letztlich über eine sekundäre – beispielsweise die Grid-Navigation – bedient wird.9


Abb. 1.21: iPhone-Apps wie Uhr, Health und Spiele kombinieren eine Tab Bar mit der Baumstruktur

Abb. 1.22: In der Android-App vom Tumblr werden Tab Bar und Grid-Ansicht wunderbar kombiniert, während Etsy Sidebars mit Grid-Navigation und bei der Kontakte-App Sidebar mit Tab Bar verschmelzen

1.8 Apps mit individueller Navigation

Fühlen Sie sich durch die vorgestellten Navigationsmodelle in Ihrer gestalterischen Freiheit eingeschränkt oder benötigt Ihre App vielleicht gar keine Navigation im engeren Sinne? Manchmal kann eine individuell gestaltete Navigation der beste Ansatz sein, zum Beispiel für Apps, die gar keine tiefe Navigationsstruktur benötigen, weil einfach zu wenige Inhalte vorhanden sind. Ein Taschenrechner beispielsweise braucht kaum Navigationsmöglichkeiten und orientiert sich an seinem realen Vorbild. Kalender oder Spiele greifen meist ebenfalls auf eine individuelle Lösung zurück und sorgen so ganz nebenbei für einen hohen Wiederkennungswert. So individuell Ihre Navigation ist, so durchdacht sollte allerdings auch die Nutzerführung in Ihrer App sein. Ständige Testläufe kosten Zeit, sind aber unvermeidbar, wenn Sie sicherstellen möchten, dass Benutzer die Orientierung behalten. Schließlich befinden Sie sich mit einer individuellen Navigation abseits der Guidelines und schicken Benutzer auf unbekanntes Terrain – was nur dann gut ist, wenn sie besser als eine Standardnavigation ist.

Abb. 1.23: iPhones-Apps wie Kompass, Rechner und Weightbot lassen sich in keine herkömmliche Navigationsart einordnen

Abb. 1.24: Minion Rush, Muzei und die Rechner-App für Android setzen ebenfalls auf eine individuelle Navigation

1.9 Die passendste Navigationsart auswählen

Zu diesem Zeitpunkt wissen Sie, welche Navigationsmodelle Sie in Ihrer App grundsätzlich nutzen können, doch wie finden Sie heraus, welches Modell nun am besten geeignet ist? Der Entscheidungsbaum in Abbildung 1.26 soll Ihnen dabei helfen, die richtige Wahl Ihres Navigationsmodells zu treffen. Greifen Sie vor dem ersten Blick auf den Entscheidungsbaum beherzt zu Stift und Papier, um die wichtigsten Inhaltspunkte Ihrer App zunächst aufzulisten. Im Anschluss empfiehlt sich die Erstellung einer Screenübersicht, auf der Sie alle angedachten App-Seiten mit deren Inhalten einmal grob skizzieren und untereinander verbinden. Häufig liegt das geeignetste Navigationsmodell sprichwörtlich auf der Hand – und manchmal noch nicht ganz.

Abb. 1.25: Für die Android-App Currency Converter kommt nur eine individuelle Navigation infrage

Abb. 1.26: Diese Übersicht hilft Ihnen bei der Entscheidung für eine Navigationsart in Ihrer Android-App

In den meisten Fällen sind Navigationsarten, die Sie zunächst auf iOS oder Android umgesetzt haben, auch auf der entsprechend anderen Plattform problemlos umsetzbar. Einige Apps, wie beispielsweise Fancy, nutzen für iOS und Android aber von vorneherein unterschiedliche Navigationsarten, um die Vorteile der jeweiligen Plattformen auszuschöpfen.

Abb. 1.27: Fancy nutzt eine Tab Bar für das iPhone, aber eine Sidebar-Navigation in der Android-App

Navigationsarten, die nicht zu den Standardelementen eines Systems zählen, können Sie mit Mehraufwand natürlich trotzdem implementieren. Anhand von Tabelle 1.1 sehen Sie, welche der vorgestellten Navigationsarten als Standardelement für welches System festgelegt wurden.

Tabelle 1.1: Die Standardnavigationsarten der jeweiligen Betriebssysteme sind mit einem x markiert.

Quellen
1     Vgl. Josh Clark: „Tapworthy. Designing Great iPhone Apps“, O’Reilly 2010, S. 101–115; https://www.google.com/design/spec/patterns/navigation.html#navigationcombined-patterns
2     https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/ MobileHIG/Navigation.html#//apple_ref/doc/uid/TP40006556-CH53-SW1
3     Vgl. Josh Clark: „Tapworthy. Designing Great iPhone Apps“, O’Reilly 2010, S. 110
4     https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/ MobileHIG/Bars.html und https://www.google.com/design/spec/components/tabs.html#
5     https://www.google.com/design/spec/components/grid-lists.html#
6     https://www.google.com/design/spec/patterns/navigation-drawer.html
7     https://www.google.com/design/spec/patterns/navigation-drawer.html#navigationdrawer-behavior
8     http://mobilbranche.de/2015/02/ios-sidebar-navigation
9     Vgl. Josh Clark: „Tapworthy. Designing Great iPhone Apps“, O’Reilly 2010, S. 114
10   Die Blatt-für-Blatt-Navigation findet in Android-Apps kaum noch Verwendung, auf eine Darstellung in dieser Abbildung wurde daher verzichtet.

The post Leseprobe: Besseres Mobile-App-Design appeared first on MobileTechCon.

Entwickler, deren Hauptaufgabe darin liegen sollte, herausragende App-Frontends und eine flüssige User Experience zu realisieren, investieren den größten Teil ihrer Zeit damit, die Integration mit dem Backend zu implementieren. Verstärkt wird das Problem noch dadurch, dass dieselbe Lösung oft auf verschiedenen Plattformen wie iOS, Android und vielleicht auch noch Windows laufen soll. Es werden mehrfach, teilweise von verschiedenen Entwicklern, die gleichen Integrationsfragestellungen gelöst. Dabei besteht die Gefahr, dass Themen wie Sicherheit, Qualität und funktionale Aspekte darunter leiden. Die klassische Unternehmens-IT, die nicht auf die neuen Anforderungen hinsichtlich Flexibilität und schneller Anpassbarkeit vorbereitet war, leidet darunter, dass Fachbereiche notgedrungen in U-Boot-Projekten und mit einer Schatten-IT eigene Lösungen bauen, um nicht bei der Time-to-Market ins Hintertreffen zu geraten. Richtlinien und Anforderungen aus der offiziellen IT bleiben dabei auch gerne mal auf der Strecke, was zu noch komplexeren und teilweise nicht wartbaren und nicht unterstützten oder gar unsicheren Systemen führt. Besonders problematisch wird es dann, wenn sie auch noch wichtige Kernprozesse des Unternehmens abbilden.

Diese offensichtlichen Ineffizienzen kann nur durch die Zusammenarbeit unterschiedlicher Stakeholder ausgeräumt werden. Tabelle 1 gibt einen Überblick über die beteiligten Stakeholder und ihre teilweise konkurrierenden Anforderungen. Die dort aufgelisteten Punkte können nicht für jede neue Entwicklung oder jedes neue Vorhaben frisch adressiert werden. Man benötigt eine Plattform (Mobile Enterprise Application Platform, kurz MEAP). Für die Einführung einer MEAP sprechen insbesondere folgende Kriterien:

• Mehrere Apps
• Unterschiedliche Entwicklungsansätze für Mobile
• Hohe Fragmentierung (Plattformen, Endgeräte)
• Diverse Backend-Systeme (nicht dediziert für Mobile)
• Viele Entwickler
• Parallele Bereitstellung unterschiedlicher Versionen

Tabelle 1: Die beteiligten Stakeholder haben im Kontext Enterprise Mobility teilweise konkurrierende Anforderungen

MBaaS? Was ist das?

Die Begriffe MEAP und MBaaS (Mobile Backend as a Service) werden oft vermischt und sind nicht 100 Prozent voneinander abgegrenzt. Die Unterscheidung liegt für uns insbesondere bei der Berücksichtigung von Cloud-Aspekten. Während MEAP schon ein etwas älterer Begriff ist, der auch der traditionellen Enterprise-Entwicklung entstammt, sind MBaaS von Anfang an auf Skalierbarkeit, Containerisierung und Self-Service-Aspekten ausgerichtet.

MBaaS unterstützt aus unserer Sicht einen agile Ansatz, um Unternehmens-Apps zu entwickeln, zu deployen und zu integrieren. Dabei spielt es keine Rolle, ob es sich um native, hybride oder mobile Web-Apps handelt. Ein MBaaS stellt Steuerungs- und Kontrollmöglichkeiten von Sicherheitsaspekten und Unternehmensrichtlinien bei der Integration mit Unternehmenssystemen bereit. Deployments werden idealerweise auf Public-, Private- und Hybrid-Clouds ermöglicht.

Do it yourself!

Einige der bereits genannten Anforderungen lassen sich recht elegant mit modernen Open-Source-Werkzeugen und -Technologien selbst umsetzen. Dies bietet sich insbesondere dann an, wenn nur wenige Apps mit einem kleinen Entwicklerkreis, der diese Technologien kennt, entwickelt werden soll. Dabei bieten sich oftmals folgenden Bausteine an:

• SSL-Offloading, Load Balancing und Bereitstellung von statischen Inhalten: nginx
• Identity- und Access-Management (z. B. LDAP, OAuth2): Keycloak
• API-Gateway und Integrationspunkt für Apps (hoch skalierbar, für kurzlaufende Prozesse): Node.js, Vert.x oder Akka
• Plattformübergreifende Push Notifications: AeroGear UnifiedPush Server
• Cache (verteilt): Redis, Infinispan
• Persistenz (NoSQL/relational): MongoDB oder PostgreSQL
• Containerisierung, Deployment: Docker
• Typischerweise kommen noch weitere Elemente wie Analytics, Crash Logging und App-Verteilung (Private/Enterprise Stores) hinzu. Diese Anforderungen lassen sich mit SaaS-Angeboten wie Google Analytics, HockeyApp und Crashlytics gut abdecken. Der gesamte Stack kann sowohl On-Premise als auch auf PaaS-Lösungen wie OpenShift oder Amazon AWS betrieben werden. Dadurch sind auch komplexe Skalierungsanforderungen im produktiven Einsatz möglich.

Zu beachten ist, dass ein solcher Do-it-yourself-MBaaS nicht darauf ausgelegt ist, langlaufende Prozesse oder Fachlogik abzubilden, sondern nur eine einfache und optimierte Integration von mobilen Endgeräten gewährleisten und spezielle Anforderungen wie Offlineverfügbarkeit, Übertragungseffizienz und Toleranz hinsichtlich instabiler Netzwerkverbindungen umsetzen soll. Für eine Integration in die Unternehmens-IT empfehlen sich weiterhin etablierte Mechanismen wie ein Enterprise Service Bus – oft vorhanden – oder ein Message Broker.

Bei dem skizzierten Technologiestack gibt es jedoch auch Nachteile. Das erforderliche Know-how für die einzelnen Komponenten und das reibungslose Zusammenspiel derselben ist umfangreich und einem stetigen Wandel unterzogen. Im Fehlerfall sind verantwortliche Bausteine nicht immer einfach zu identifizieren. Die Komplexität des Gesamtsystems erfordert daher eine hohe Leidenschaft des Entwicklungsteams. Daher lohnt sich der Blick auf Alternativen, die einen Großteil der Komplexität in einem Produkt bündeln und dadurch einfacher zu beherrschen sind.

MBaaS: Red Hat Mobile Application Platform

Die Red Hat Mobile Application Platform (RHMAP) nutzt viele Basistechnologien, die auch in einer Do-it-yourself-Lösung verwendet werden. Im Kern basiert RHMAP auf Best-of-Breed- und Open-Source-Technologien. Das Zusammenspiel der Bausteine durchläuft eine umfangreiche Qualitätssicherung, und Red Hat bietet für den professionellen Einsatz unterschiedliche SLAs. Zusätzlich sind noch viele weiterer Dienste vorhanden. Insbesondere die Administration und Strukturierung von Mobile-Projekten ist einfacher (Abb. 1 und 2). Abbildung 2 verdeutlicht den grundsätzlichen Aufbau eines Projekts in der RHMAP.

  Abb. 1: Das RHMAP-Dashboard zeigt gebündelt die verschiedenen Funktionen der Plattform

Abb. 2: Die Projektansicht in RHMAP ist klar gegliedert und übersichtlich

Mit der Plattform lassen sich verschiedene Apps konfigurieren. Die Cloud-Apps (Node.js) stellen Integrationsschnittstellen der Apps mit Backend-Diensten zur Verfügung. Diese Cloud-Apps enthalten typische Aufbereitungen und Optimierungen für mobile Clients. Die MBaaS-Services (Node.js) sind Integrationskomponenten, die in verschiedenen Projekten wiederverwendet werden können. Jede Komponente ist in einem eigenen Git Repository abgebildet. Neben der grafischen Oberfläche (Browser) gibt es auch ein Command-Line-Tool (FHC) mit dem vollen Funktionsumfang. Hiermit ist eine Integration in bestehende Entwicklungsprozesse und Praktiken einfach zu realisieren.

Die Hauptbestandteile der RHMAP lassen sich in sechs Unterpunkte gliedern: Collaboration, Bring-your-own-Tools, Backend-Integration, Security und Authentifizierung, Codeless Development und Cloud und On-Premise Deployment:

• Zum Thema Collaboration unterstützt die Plattform verteilte Teams und Teamrollen. Sie bietet Mobile-Application-Lifecycle-Management und einen Git-basierten Workflow für die Entwicklung.
• Unter dem Motto Bring-your-own-Tools unterstützt die Plattform native SDKs (iOS, Android, Windows Phone), Apache Cordova, HTML5 und Appcelerator sowie Xamarin, Sencha, Ionic, Backbone.js, AngularJS und Ember.js. Lokale Entwicklung sowie Entwicklung im gehosteten Service (Cloud) ist möglich; die Nutzung des eigenen Build-Systems oder Verwendung der integrierten Cloud-basierten Build-Farm ebenso.
• Für die einfache, leichtgewichtige, sichere und skalierbare Integration von Backend-Systemen auf Basis von Node.js mit Bereitstellung von Diensten wie Data Storage, Data Management, Notifications und Analytics gibt es wiederverwendbare Microservices und APIs. Die bidirektionale Datensynchronisierung erfolgt mit dem Data Sync Framework für Offlinefunktionalität.
• Zum Thema Sicherheit ist eine optionale Verschlüsselung von lokal gecachten Daten mit HTTPS möglich. Die Plattform unterstützt Unternehmensrichtlinien für die Integration von Backend-Systemen mittels VPN und DMZ sowie eine Nutzerauthentifizierung und -authorisierung.
• Für Codeless Development gibt es Drag-and-Drop-Formulargenerierung, erweiterbare Templates und Beispiele.
• Bei Cloud und On-Premise Deployment hilft die Cloud-agnostische Architektur für unterschiedliche Deployment-Szenarien wie öffentliche, mandantenfähige Clouds (AWS, Rackspace, HP Cloud), private, dedizierte und managed Clouds und hybride Clouds (Anwendungs- und Integrationscode in unterschiedlichen Clouds).

Abbildung 3 gibt einen Überblick über die Hauptbestandteile der RHMAP.

Abb. 3: Die Hauptbestandteile einer RHMAP in der Übersicht

Die RHMAP basiert mit FeedHenry auf einer etablierten MEAP und hat in vielen Projekten ihre Praxistauglichkeit bewiesen. FeedHenry war jedoch eine reine SaaS-Lösung, und erst mit der Akquisition durch Red Hat wird ein On-Premise-Modell unterstützt. Im Gegensatz zu anderen Red-Hat-Produkten gibt es zum heutigen Stand noch kein Community-Upstream-(Open-Source-)Projekt. Aktuell wird daran gearbeitet, offene rechtliche Themen bezüglich der ursprünglich in FeedHenry verwendeten Komponenten abzuarbeiten, daher gibt es derzeit keine öffentlich verfügbaren Zeitpläne für eine Open-Source-Version. Mit FeedHenry steht jedoch schon der Name des Upstreamprojekts fest.

Für uns ist die RHMAP eine gute Alternative zu den bisherigen Do-it-yourself-Ansätzen. Im Vergleich zu Wettbewerbern macht die RHMAP einen sehr reifen und kompletteren Eindruck, der sich hoffentlich mit den nächsten Versionen weiter festigt.

The post Mobile Backend as a Service: Entwicklung und Integration beschleunigen appeared first on MobileTechCon.

Offiziell soll Swift zwar Objective-C nicht ersetzen, wird von OS-X- und iOS-Entwicklern aber gut angenommen – und ist langsam, aber sicher dabei, Objective-C zu überflügeln. Ein Grund dafür ist die Kombination von Leistung und Effizienz kompilierter Sprachen mit der Einfachheit und Interaktivität gängiger Skriptsprachen.

Seit der Veröffentlichung Ende 2014 arbeitet Apples Entwickler-Team an der Weiterentwicklung der sowohl in der OS-X- als auch der der iOS-Entwicklung zum Einsatz kommenden Programmiersprache.

Swift wird Open Source

Im Sommer 2015 folgte dann der Paukenschlag, denn Apple hatte verkündet, Swift künftig auch Open Source zur Verfügung zu stellen. Ein Versprechen, dass dann im Dezember 2015 wahr gemacht wurde:  Der Quellcode von Apples Programmiersprache liegt seitdem unter der Apache-2.0-Lizenz offen. Entwickler haben damit die Möglichkeit, Swift frei zu verwenden und zu modifizieren – auch für kommerzielle Projekte. Der Code steht auf GitHub zur Verfügung und unterstützt neben allen bekannten Apple-Plattformen, wie OS X, iOS, watchOS und tvOS, auch Linux und Ubuntu. Zu den verfügbaren Komponenten gehören der Swift Compiler, drei Core Libraries, der Package Manager, LLDB Debugger und REPL sowie Build Tools. Gleichzeitig hat Apple die Webseite Swift.org gestartet, die ausführliche Informationen über die Entwicklung mit Swift als Open-Source-Sprache bereitstellt. Zusätzlich finden sich dort technische Dokumentationen und Tutorials, Links zum Herunterladen des Swift-Quellcodes und Community-Richtlinien.

We are excited by this new chapter in the story of Swift. After Apple unveiled the Swift programming language, it quickly became one of the fastest growing languages in history. Swift makes it easy to write software that is incredibly fast and safe by design. Now that Swift is open source, you can help make the best general purpose programming language available everywhere.

Wie man unter anderem ein API mithilfe von Swift baut und wie man dieses auf dem Server zum Laufen bringt, erklärt Tom Harvey (Ve Interactive) in seiner Session „Swift on the Server“ auf der MobileTech Conference im September.

Apple erhofft sich seinerseits durch die Offenlegung, dass die Community zu neuen Funktionen und zur Optimierung von Swift beitragen wird – und natürlich, dass Swift auch auf anderen Plattformen Einzug hält.

Swift 2.2

Im März 2016 erschien Swift 2.2 mit einer Reihe neuer Features und Verbesserungen, darüber hinaus wurden Änderungen an der Standardbibliothek der Sprache vorgenommen und einzelne Sprachmerkmale als deprecated eingestuft. Damit wurde bereits der Weg zur neuen Major-Version geebnet. Die Änderungen in Swift 2.2 reichen von einfachen Bugfixes bis hin zu Änderungen an der Standardbibliothek der Sprache.

So stehenden Swift-Nutzern erstmals Operatoren für Tupel-Vergleiche zur Verfügung. Mit der Ausnahme von inout, var und let können zudem nun alle Schlüsselwörter als Parametername verwendet werden; darüber hinaus hält in Swift 2.2 neben neuen Constraints für AnySequence.init mit #if swift auch eine neue Build-Konfigurationsoption Einzug in die Sprache.

Des Weiteren wurden mit Swift 2.2 mehrere Sprachmerkmale als deprecated eingestuft und somit aufs sprichwörtliche Abstellgleis gestellt. Dieses Schicksal hat u. a. die Operatoren ++ und –, die bereits mit Swift 3.0 endgültig entfernt werden, ereilt. Auch für die aus C bekannten For-Schleifen hat offenbar schon bald das letzte Stündlein geschlagen, gleiches gilt für die var-Parameter, die aufgrund ihrer geringen Nützlichkeit und der Verwechslungsgefahr mit inout zu deprecated-Kandidaten wurden.

Swift 2.3

Swift in Version 2.3 wurde am 12. Juni 2016 veröffentlicht (https://swift.org/blog/swift-2-3/) und ist lediglich ein Minor Update von Swift 2.2. Der Hauptunterschied der Versionen liegt darin, dass Swift 2.3 dafür vorgesehen ist, mit Apples macOS 10.12, iOS 10, watchOS 3 und den tvOS 10 SDKs zusammengeführt zu werden. Darüber hinaus werden mit Version 2.3 die entsprechende LLVM- und Clang-Versionen aktualisiert, damit sie zu denen im Swift 3 Compiler passen.

Swift 3.0 Release-Prozess

Swift 3.0 ist die kommende Major-Version der Programmiersprache. Sie soll, so erklärt Ted Kremenek in einem Blogpost, fundamentale Änderungen der Sprache selbst sowie der Swift-Standard-Library enthalten – und dementsprechend nicht abwärtskompatibel zur aktuellen Swift-Version 2.2 bzw. 2.3 sein.

Außerdem ist Swift 3.0 das erste Release, das mit dem neuen Swift Package Manager daherkommt. Zwar befindet sich der noch in einer frühen Entwicklungsphase, unterstützt aber bereits die Entwicklung und Distribution von Cross-Plattform-Swift-Packages. Ebenso umfasst die neue Version auch die Swift Core Libraries.

Für den Release-Prozess sind eine Reihe Developer Previews vorgesehen, die „qualified and converged builds of Swift 3“ zur Verfügung stellen sollen. User können so mithilfe von möglichst stabilen Swift-Binaries, die rund alle vier bis sechs Wochen erscheinen sollen, die neue Version testen und mögliche Bugs melden.

Alle Sprach- und API-Änderungen für Swift 3.0 durchlaufen den Swift-Evolution-Prozess; über Source-breaking-Änderungen an der Sprache soll zudem auf einer Fall-zu-Fall-Basis entschieden werden. Aktuell steht der erste Developer-Preview-Branch swift-3.0-preview-1-branch zur Verfügung; sobald der letzte Preview-Branch erstellt wird, soll Swift 3.0 als „GM“ erklärt werden.

Mehr Informationen zum Release-Prozess und den einzelnen Entwicklungs-Branches für Swift 3.0 fasst der zugehörige Blogpost zusammen. Eine Übersicht über die bereits implementierten Änderungen steht auf GitHub zur Verfügung.

ABI-Stabilität wird erst mal verschoben

ABI-Stabilität sollte eines der größten Ziele für die neue Major-Version von Swift sein. Mitte Mai 2016 gab Swift-Erfinder Chris Lattner in der Swift Evolution Mailing List bekannt, dass dieses Feature erst mal verschoben wird. Grund dafür ist laut Lattner, dass einige Features, die für das Erreichen der ABI-Stabilität nötig sind, nicht rechtzeitig vervollständigt werden können:

it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release – including some of the most important generics features needed in order to lock down the ABI of the standard library.

Die ABI-Stabilität sollte, so erklärt Sergio De Simone, eigentlich dazu dienen, dass mit zukünftigen Versionen von Swift kompilierte Applikationen und Libraries mit Binärcode interagieren können, der mit Swift 3.0 kompiliert wurde. In anderen Worten: die ABI-Stabilität garantiert nicht nur ein gewisses Maß an Binär-Kompatibilität, sondern ermöglicht auch, dass die Swift-Standard-Library nicht länger mit Binaries ausgespielt werden muss. Außerdem können Third-Parties so leichter Binär-Libraries verteilen.

Preview 1 von Swift 3.0 veröffentlicht

Die erste Entwickler-Preview der Version 3.0 von Swift erschien am 13. Juni 2016. Diese vergleichsweise stabile Version von Apples quelloffener Sprache wird wie angekündigt eine „source-breaking“ Veröffentlichung und demnach nicht abwärtskompatibel zu Swift 2.2 bzw. 2.3 sein.

Doch nicht nur deswegen sollte der Migration Guide konsultiert werden: Viele syntaktische Verfeinerungen und eine Menge an Veränderungen – vor allem den Import von Objective-C-APIs betreffend – können ebenfalls eine Herausforderung darstellen. Hilfreich dürfte es außerdem sein, sich einen Überblick über die aktualisierte Dokumentation und die neu implementierten Swift Evolution Proposals zu verschaffen. Eine Übersicht darüber bietet der oben genannte Ankündigungspost im Swift-Blog.

Die Developer Preview 1 steht seit Mitte Juni 2016 als Teil der Xcode 8 Beta 1 sowie für Ubuntu 14.04 bzw. 15.10 zum Download bereit.

The post Swift appeared first on MobileTechCon.