Teil 1: Ein Überblick über die Cross-Plattform-Programmierung

Einführung in die Cross-Plattform-Programmierung: Alle auf einen Streich
Keine Kommentare

Eine große Geräte- und Systemvielfalt ermöglicht es Nutzern, auf der Hard- und Softwareplattform ihrer Wahl zu arbeiten. Briefe werden auf dem Desktop unter Windows geschrieben und E-Mails werden auf einem Smartphone unter Android beantwortet. Die Urlaubsfotos werden auf einem iPad betrachtet. Aus Entwicklersicht gilt es, diesen Zoo aus Geräten und Systemen mittels Cross-Plattform-Programmierung in den Griff zu bekommen.

Wir haben es heute mit einer sehr großen Vielfalt an Geräten und Plattformen zu tun. Im Bereich von Desktopapplikationen wird nach wie vor meistens Microsoft Windows eingesetzt. Dabei findet man nicht nur Windows 10 auf den Geräten, sondern oft werden noch die Vorversionen verwendet, und das sicher auch noch, wenn am 14. Januar 2020 der Support für Windows 7 endet. Für spezielle Aufgaben, wie zum Beispiel Grafik- und Bildbearbeitung setzen viele Anwender hingegen macOS ein. Im Bereich des Mobile Computing teilen sich Android und iOS die Marktanteile. Auch hier haben wir es mit unterschiedlichen Versionen der beiden Betriebssysteme zu tun. Bei Android kommt eine unüberschaubare Anzahl von Geräten unterschiedlichster Hersteller hinzu.

Aus Sicht der Softwareentwicklung stellt diese Vielfalt an Geräten und Systemen eine erhebliche Herausforderung dar. Webapplikationen können einen Ausweg bieten. Eine Webapplikation kommt unter folgenden Bedingungen als Lösung in Frage: Die Möglichkeiten der Webanwendung sollten genügen, um auf die Hardware des jeweiligen Geräts zuzugreifen, parallel sollten keine großen Ansprüche an die Performance der Applikation gestellt werden. Besser in die Systeme integriert sind native Applikationen. Um jedoch native Applikationen zu erstellen, muss man sich intensiv mit der Vorgehensweise für jede einzelne Systemumgebung auseinandersetzen. Programmiersprachen, Entwicklungsumgebungen, Vorgehensweisen und Bibliotheken unterscheiden sich erheblich von System zu System. Für den einzelnen Entwickler ist es kaum möglich, auf allen Systemen gleichermaßen fit zu sein. Weiterhin ist es aufwendig, ein einziges Programm für unterschiedliche Betriebssysteme umzusetzen. Es würde bedeuten, dass man die Software für jede Systemumgebung nahezu komplett neu implementieren muss. Das wäre zeit- und kostenintensiv.

International JavaScript Conference

Effective Microservices Architecture In Node.js

by Tamar Stern (Palto Alto Networks)

React Components And How To Style Them

by Jemima Abu (Telesoftas)

API Summit 2020

API-Design? Schon erledigt! – Einführung in JSON:API

mit Thilo Frotscher (Freiberufler)

Praktischer Einstieg in Go

mit Frank Müller (Loodse GmbH)

Einen Ausweg stellt die geräte- bzw. plattformübergreifende Programmierung dar. Von geräteübergreifender Programmentwicklung spricht man, wenn Hardware unterschiedlicher Geräteklassen adressiert wird, das heißt, zum Beispiel Desktop-Rechner und Smartphone. Mit Plattformen sind heterogene Systemumgebungen, wie zum Beispiel Android und iOS auf mobilen Geräten oder Windows, Linux und macOS auf dem Desktop gemeint.

In einer fünf Teile umfassenden Artikelserie nähern wir uns dem Thema Cross-Plattform-Programmierung aus unterschiedlichen Perspektiven.

Artikelserie

  • Teil 1: Ein Überblick über die Cross-Plattform-Programmierung
  • Teil 2: Mobile Applikationen sind weiter auf dem Vormarsch
  • Teil 3: Vorgehensweisen am Beispiel von Apps für Android
  • Teil 4: Gearbeitet wird am Schreibtisch
  • Teil 5: Eine Desktop-Anwendung ist überall zu Hause

In diesem ersten Teil verschaffen wir uns zunächst einen Überblick über die Geräte und Systeme. Vom Smartphone bis hin zu Geräten mit leinwandgroßen Bildschirmen ist die Gerätevielfalt heute riesig. In den folgenden beiden Teilen geht es um die Programmierung von Apps für Android und iOS, und zwar aus einer einzigen Quellcodebasis. Wenn Sie dabei an Xamarin denken, dann ist das richtig, aber es gibt noch eine Reihe weiterer Ansätze, die wir in Teil 2 der Artikelserie im Überblick vorstellen und uns dann in Teil 3 an einigen konkreten Beispielen ansehen. Systemvielfalt herrscht nicht nur im mobilen Bereich, sondern auch auf dem Desktop. Java war lange Zeit dominierend darin, Applikationen herzustellen, die auf Windows, macOS und Linux gleichermaßen laufen. Auch hier sind die Ansätze heute vielfältiger. Im Teil 4 stellen wir diese Möglichkeiten vor und blicken im fünften und letzten Teil der Serie in die Praxis. Insgesamt ergibt sich so ein umfassender Überblick über den heutigen Stand der Cross-Plattform-Programmierung. So viel steht bereits fest: Die Technik hat hier wesentliche Fortschritte gemacht.

Der Nutzer im Fokus

Software wird für die Anwender erstellt. Diese wollen damit Probleme lösen (Textverarbeitung, Datenbanken), Spaß haben (Spiele) oder die Kommunikation vereinfachen (Chat, E-Mail) usw. Das bedeutet, dass man alle Aspekte des Nutzerverhaltens erforschen muss. Aus technischer Hinsicht ist zu klären, mit welchen Geräten und Betriebssystemen die Anwender arbeiten möchten. Heute hat man es grob mit drei entscheidenden Gerätekategorien zu tun: Desktop, Smartphone und Tablet. Mobile Systeme dominieren dabei. Das Smartphone hat man stets bei sich und kann damit jederzeit auf Apps und das Internet zugreifen.

Im Tagesverlauf ändert sich die Präferenz der Gerätekategorie. Am frühen Morgen dominiert die Nutzung des Smartphones. Hier können E-Mails und soziale Netzwerke auf neue Nachrichten überprüft werden. Aber auch über den gesamten Tagesverlauf hinweg ist das Smartphone ein Begleiter des modernen Anwenders. Für ein produktives Arbeiten setzt man nach wie vor auf größere Bildschirme und leistungsfähigere Hardware. Zu den typischen Bürozeiten wird daher hauptsächlich an Desktopgeräten gearbeitet. In den Abendstunden liegt der Höhepunkt der Nutzung bei den Tablet-PCs. Moderne Tablets sind leistungsfähig und bieten eine annehmbare Bildschirmgröße für die individuelle Unterhaltung, zum Beispiel zum Video schauen oder zum Surfen im Internet, gemütlich im heimischen Wohnzimmer.

Wir lernen daraus, dass man aus Entwicklersicht vor dem Treffen von Entscheidungen unbedingt Nutzerpräferenzen genau analysieren muss. Welche Geräte und Betriebssysteme sind zu unterstützen und was muss die Anwendung dafür spezifisch können?

Geräte- und plattformübergreifende Anwendungen

Plattformübergreifende Ansätze (Cross Platform) verfolgen das Ziel, aus einem Quellcode simultan eine Applikation für alle Zielsysteme gleichzeitig zu erstellen. Mit anderen Worten: „Write once, run anywhere“.

Ebenso wichtig ist es, dass sich die Applikationen in die Zielsysteme möglichst gut integrieren. Die Anwendungen dürfen dabei nicht wie Fremdkörper wirken. Wie kommt es zu solchen Problemen? Die Ursachen liegen i. d. R. im unterschiedlichen Aufbau der Benutzeroberflächen. Die Betriebssysteme unterscheiden sich hier in vielen Punkten, u. a. im Design und in der Art und Weise der Bedienung. Die Anwendungen sehen zwar auf allen Systemen ähnlich aus, aber sie passen nicht zu den Vorgaben der Zielplattform. Die Nutzer haben dann möglicherweise Probleme, die App zu bedienen bzw. gefällt ihnen das Design der Anwendung nicht, da sie etwas anderes gewohnt sind. Zeitgemäße Ansätze müssen daher die Besonderheiten der jeweiligen Systemumgebung berücksichtigen.

Die technische Perspektive: der Desktop

Erfreulicherweise hat sich eine Reihe von Ansätzen der Cross-Plattform-Programmierung etabliert. Beginnen wir mit den Desktopanwendungen. Dabei wird der Markt durch verschiedene Versionen des Windows-Betriebssystems von Microsoft dominiert. Im Sinne einer Cross-Plattform-Strategie müssen wir auch macOS und diverse Linux-Distributionen unterstützen. Für den Anwender fühlt sich das Erscheinungsbild einer Desktopanwendung meist vertraut an, da es optisch immer gleich aussieht: Es gibt eine Menüleiste, die Installation ist meistens noch lokal auf dem Rechner, die Anwenderin und der Anwender haben weitgehenden Zugriff auf das Dateisystem und die Hardware. Die visuelle Kontinuität ist jedoch oberflächlich, unter der Haube haben auch hier Innovationen stattgefunden, auf die wir an dieser Stelle nicht weiter eingehen können. Zu nennen sind in diesem Zusammenhang auf jeden Fall:

  • Integration verbessern: In kleinen und mittleren Unternehmen (KMU) besteht bezüglich der Software oft eine heterogene IT-Landschaft aus verschiedensten Insellösungen. Oft werden die Systeme rudimentär über Schnittstellen (APIs) miteinander verknüpft. Es existiert keine einheitliche Datenbasis. Zum Beispiel werden Daten in einem ERP-System und in der CRM-Software gleichermaßen geführt. Eine Synchronisierung von Daten ist oftmals nicht oder nur eingeschränkt möglich. Neue Desktopanwendungen sollten nach Möglichkeit nicht zu einer Vergrößerung der Einzellösungen führen, sondern idealerweise zu einer verbesserten Systemintegration beitragen.
  • Modularität vergrößern: Die Zeiten monolithischer, allumfassender Applikationen sind schon lange vorbei. Moderne Desktopanwendungen sollten unbedingt modular aufgebaut werden, sodass der Funktionsumfang problemlos erweitert oder verringert werden kann. Insbesondere bei Software-as-a-Service-(SaaS-)Anwendungen können Module jederzeit hinzu- und abbestellt werden. Das moderne Anwendungssystem passt sich so immer den jeweiligen Unternehmensanforderungen an bzw. kann es auf dem Wege der Konfiguration sehr leicht an diese angepasst werden. Auch Microservices sind durch Desktopanwendungen, zum Beispiel in Form von REST Interfaces, nutzbar.
  • Schnittstellen anbieten: Auch wenn moderne Anwendungen bereits einen großen Funktionsumfang modularisiert abdecken, dürfen Schnittstellen (APIs) natürlich nicht fehlen. Damit können einzelne Funktionen von außen genutzt werden bzw. ist eine Steuerung der Anwendung durch externe Dienste möglich. Schnittstellen erhöhen die Flexibilität.
  • Skalierbarkeit vorbereiten: Die quantitative Leistungsfähigkeit einer Anwendung muss sich veränderlichen Wünschen und Bedürfnissen anpassen können. Die verwalteten Ressourcen müssen mit einem möglicherweise wachsenden Bedarf des Unternehmens skalieren.
  • Datenschutz und Datensicherheit berücksichtigen: Das Anwendungssystem muss so gestaltet sein, dass die Anforderungen an den Datenschutz und die Datensicherheit leicht erfüllt werden können. Beispielsweise sollte ein (temporäres) Speichern von Daten auf dem lokalen PC nach Möglichkeit vermieden werden.
  • Usability verbessern: Desktopanwendungen werden meist für das intensive Arbeiten im Büro konzipiert. Dennoch müssen auch hier die heute üblichen hohen Anforderungen an die Nutzerfreundlichkeit berücksichtigt werden. Auch ein Buchhaltungssystem sollte optisch ansprechend gestaltet sein. Es muss die nächsten Aktionen des Anwenders abstrahieren und diesen bestmöglich bei seinen< Aufgaben unterstützen.

Gerade das Thema User Interface Design ist bei der Cross-Plattform-Programmierung zu beachten. Auch wenn sich die modernen Oberflächen der Systeme Windows, macOS und Linux in vielen Punkten gleichen, gibt es dennoch eine Reihe von Unterschieden. Ein Richtig oder Falsch gibt es beim Design nicht. Jedoch gibt es durchaus gelungene und weniger gelungene Entwürfe der Benutzeroberflächen. Was angemessen ist, dazu gibt es keine klare Definition. Vielmehr werden etablierte Designmuster durch Gebrauch und häufige Verwendung herausgebildet. Dazu gesellen sich Trends. Blicken wir zu den Großen der Branche. Abgucken ist hier nicht nur erlaubt, sondern ausdrücklich empfohlen. Dafür gibt es die folgenden Gründe:

  • Designstandards werden hauptsächlich durch Benutzerakzeptanz begründet. Die großen Applikationen, zum Beispiel Microsoft Office, SAP usw. erreichen durch ihren hohen Verbreitungsgrad eine Vielzahl von Benutzern und haben damit im übertragenen Sinn auch die Möglichkeit, Standards zu definieren. Das Bedienungskonzept dieser Anwendungen ist den Nutzern vertraut. Es muss sehr gute Gründe geben, mit der eigenen Software davon abzuweichen. Der Nutzer erwartet bei Programmen aus ähnlichen Segmenten eine Wiedererkennung bei der Benutzerführung. Das soll Sie nicht davon abhalten, eigene innovative Wege zu beschreiten. Für Routineabläufe, wie beispielsweise eine Dateiauswahl oder eine Datumsangabe, sollte allerdings auf etablierte Dialogelemente des jeweiligen Betriebssystems zurückgegriffen werden, denn dessen Handhabung ist den Anwendern vertraut.
  • Der Praxisvergleich mit aktuellen Versionen etablierter Software zeigt schnell, ob das für die eigene Anwendung gewählte Design den aktuellen Anforderungen genügt. Zum Zeitpunkt der Entwicklung sollte man auf eine aktuelle Technologie setzen und kann somit erreichen, dass die Anwendung auch noch nach zwei bis drei Entwicklungszyklen auf den dann aktuellen Versionen der Betriebssysteme zum Einsatz kommen kann.

Orientierung geben die sogenannten Designrichtlinien der Hersteller der Betriebssysteme. Diese finden sich zum Beispiel für Microsoft Windows im Windows Developer Center. Beachten Sie, dass Microsoft im Moment noch die Systeme klassische Windows-Desktopapplikation und Apps für die Universelle Windows Platform (UWP) trennt. Für die UWP finden sich die Richtlinien ebenfalls im Windows Developer Center. Da aber Apps für die UWP kein Mittel für eine Cross-Plattform-Programmierung sind, können sie hier außen vor bleiben. Kommen wir zu den anderen Systemen. Für macOS finden sich die als Human Interface Guideline bezeichneten Designhinweise. Die meisten macOS-Apps werden mit Komponenten aus dem AppKit erstellt, einem Programmierframework, das gemeinsame Oberflächenelemente definiert. Dieses Framework ermöglicht es, den Apps ein einheitliches Erscheinungsbild zu verleihen und gleichzeitig ein hohes Maß an Anpassungsmöglichkeiten zu bieten. Dabei handelt es sich um die folgenden AppKit-Elemente:

  • Windows and Views
  • Menus, Buttons
  • Fields and Labels
  • Selectors
  • Indicators
  • Touch Bar Controls and Views

Das AppKit definiert nicht nur das User Interface, sondern auch dessen Funktionen. Über dieses Framework kann Ihre App beispielsweise auf Gesten auf dem Trackpad reagieren und Funktionen wie Zeichnen mit einem Pen, Barrierefreiheit und Drucken aktivieren.

Auch für Linux gibt es Hinweise zur Gestaltung der Benutzeroberflächen. Hinzu kommt, dass in Linux unterschiedliche Window Manager eingesetzt werden. Für die großen, d. h. besonders häufig eingesetzten Window Manager, wie zum Beispiel KWin von KDE oder Window Manager, die auf Gnome beruhen, gibt es wie bei den anderen Systemen auch entsprechende Richtlinien zur Gestaltung der Benutzeroberflächen. Die KDE Human Interface Guidelines finden wir zum Beispiel hier. Die Designvision von KDE konzentriert sich auf zwei Attribute:

  • Standardmäßig einfach: KDE-Software soll angenehm zu erleben und einfach zu bedienen sein. KDE mahnt die Entwickler, sich auf das Wesentliche zu konzentrieren: „Entfernen oder minimieren Sie Elemente, die für die Haupt- oder Hauptaufgabe nicht entscheidend sind [sic] und zeigen Sie zusätzliche Informationen oder optionale Funktionen nur bei Bedarf an.“ Ebenso sollte man Entwurfsmuster aus anderen Anwendungen wiederverwenden (Prinzip: „Ich weiß, wie das geht!“)
  • Leistungsstark bei Bedarf: Mit der KDE-Software sollen Benutzer kreativ und effizient produktiv sein können. Die Software soll stets ein Problem lösen. Machen Sie dem Benutzer deutlich, welche Bedürfnisse angesprochen werden, und geben Sie diesem stets die Kontrolle, d. h., es sollte immer klar sein, was getan werden kann und was gerade passiert. Der Benutzer sollte sich niemals dem Werkzeug ausgeliefert fühlen. Verwenden Sie sinnvolle Standardeinstellungen, aber erwägen Sie optionale Funktionen und Anpassungsoptionen, die die primäre Aufgabe nicht beeinträchtigen.

Für auf Gnome basierende Window Manager findet man die Richtlinien hier. Hier wird u. a. sehr genau die Verwendung der einzelnen Steuerelemente beschrieben.

Bei einer plattformübergreifenden Programmierung geht es darum, wie gut es gelingt, die Features des jeweiligen Zielsystems durch eine generische Programmierschnittstelle abzubilden. Dabei kann man zwei grundsätzliche Ansätze unterscheiden. Entweder wird das native System der Zielplattform verwendet, oder das verwendete Grafiksystem stellt eigene Komponenten bereit. Wird das native Grafiksystem der Zielplattform eingesetzt, ist logischerweise die Systemintegration höher als beim Einsatz einer generischen Grafikbibliothek.

Ein aktuell sehr präsentes Thema im Bereich der Anpassung von Bürosoftware und damit auch von Desktopapplikationen ist die fehlerfreie Ansteuerung von hochauflösenden Bildschirmen. Die Entwicklung der Hardware hat gerade (zur Freude unserer Augen) erhebliche Fortschritte gemacht. Auflösungen in Full HD (1 920 x 1 080 Pixel) sind heute absoluter Standard. Neuere Monitore bieten noch weit mehr Auflösung und damit auch eine höhere Pixeldichte. Ältere Programme haben mit der grafischen Anzeige auf diesen hochauflösenden Geräten gelegentlich Probleme, zum Beispiel der folgenden Art:

  • Einzelne Elemente wie Anwendungen, Taskleiste, Symbole, Symbolleisten, Text und Dialogfelder werden unscharf angezeigt.
  • Einige Elemente sind im Vergleich zum restlichen Desktop zu groß oder zu klein.
  • Der Text in Anwendungen oder auf der Benutzeroberfläche wird verschwommen angezeigt.

Obwohl diese Probleme bei Verwendung eines einzelnen Monitors möglich sind, treten sie häufiger auf, wenn Sie mehrere Monitore mit unterschiedlicher Bildschirmauflösung verwenden (Abb. 1).

Das Problem ist dabei, dass die historisch eingesetzten grafikbasierten Frameworks, die zur Anzeige der Steuerelemente der Benutzeroberfläche dienen, für eine verlustfreie vektorbasierte Skalierung nicht vorgesehen waren. Das war beim Einsatz früherer Hardware auch nicht notwendig, waren Bildschirmgrößen und Auflösungen zwischen den Systemen doch weitgehend vergleichbar. Anwender von Microsoft Windows kennen dieses Problem, wenn sie ältere Win32-Applikationen auf einem hochauflösenden System mit einem hohen Skalierungsfaktor (teilweise mit einem Faktor von größer als 250) ausführen. Entweder ist die Schrift unscharf und einzelne Elemente zerstören das Layout der Oberfläche, oder die Schrift wird unleserlich klein bei einer Skalierung um die 100 Prozent. Die Freude über den neuen Monitor ist dann schnell getrübt. Erfreulich: Neuere Anwendungen haben unter Windows 10 kein Problem mehr mit der korrekten Darstellung.

Neuere Grafiksysteme skalieren vektorbasiert, d. h. verlustfrei. Die Darstellung erfolgt in allen Auflösungen und Skalierungsfaktoren korrekt. Das Problem tritt unter Windows daher bei Apps für die UWP nicht auf. Es ist aber auf allen Systemen präsent. Für Windows werden Probleme und Lösungsansätze beispielsweise auf den Supportseiten von Microsoft beschrieben, für Linux auf der Seite Linux-Community.

Halten wir fest: Bei der Programmierung von Cross-Plattform-Desktopanwendungen braucht es einen Extrablick auf die Möglichkeiten der App und der Hardware, mit hochauflösenden Displays umzugehen. Der Weg geht in Richtung 2K- und 4K- Bildschirmen in den Büros, aber vorerst müssen Anwendungen auch geringere Auflösungen weiterhin unterstützen. Setzt man beispielsweise auf Qt als Framework für die Anwendungen, dann können die Hinweise in der Qt-Dokumentation zu High-DPI-Displays hilfreich sein.

Die technische Perspektive: Mobile-Apps

Sind Fragen des Designs bereits unter Desktopanwendungen wichtig, so sind diese hier unabdingbar. Mobile Apps müssen ihre Nutzer nicht nur funktionell, sondern auch vom Design her begeistern. Zwei Hauptpunkte sind essenziell:

  • Geringe Bildschirmgröße: Aufgrund ihrer Mobilität besitzen Smartphones verhältnismäßig kleine Bildschirme. Dementsprechend wenig Raum bleibt für die Darstellung von Inhalten und Interaktionselementen.
  • Anderer Nutzungskontext: Mobile Geräte werden häufig an Orten verwendet, an denen die Lichtverhältnisse deutlich schlechter sind als im Arbeits- oder Wohnzimmer. Je nach Umgebung wird der Nutzer während der Anwendung mit weiteren Störquellen konfrontiert, zum Beispiel mit akustischen Beeinträchtigungen oder schlechter Netzabdeckung.

Konkret geht es bei der plattformübergreifenden Entwicklung von Apps für mobile Systeme um die Unterstützung von Android und iOS. Es sollte gelingen, dass sich das User Interface auf beiden Systemen nativ und damit natürlich anfühlt. Trotz vieler Gemeinsamkeiten gibt es auch deutliche Unterschiede (Tabelle 1).

Android iOS
Lizenz Open Source Closed, mit Open-Source-Komponenten
konfigurierbar umfassend eingeschränkt
Unterstützte Sprachen 100+ 34
Dateitransfer USB-Port, Android File Transfer Desktop App; Fotos auch ohne App verwendet iTunes, Fotos auch über USB ohne App
Verfügbarkeit Smartphone und Tablets unterschiedlichster Hersteller iPod Touch, iPhone, iPad, Apple TV
Calls and Messaging Google Messaging, 3rd Party Apps (z. B. Facebook Messenger, WhatsApp, Google Duo, Discord und Skype) iMessage, FaceTime, 3rd Party Apps (z. B. Google Hangouts, Facebook Messenger, WhatsApp und Google Duo)
Internet Browser Google Chrome, andere Browser sind verfügbar; jeder kann als Standardbrowser definiert werden Safari, andere Browser sind verfügbar, können aber nicht als Standardbrowser definiert werden
App Store Google Play Store Apple App Store
Sprachsteuerung Google Assistant Siri
Maps Google Maps Apple Maps; Google Maps ist verfügbar, aber nicht als Standard konfigurierbar
Open Source Kernel, UI und einige Apps Kernel ist nicht Open Source
Cloud Service native Integration von Google Drive Storage native Integration der iCloud

Tabelle 1: Wichtige Merkmale der mobilen Betriebssysteme Android und iOS

Auch für mobile Systeme gibt es Designrichtlinien. Für Android findet man diese auf den Developer-Seiten von Android in der Dokumentation im Bereich Design & Quality. Der Ansatz beruht auf dem sogenannten Material Design, das übrigens auch für iOS verfügbar ist. Ob man Material Design dort einsetzen sollte, ist eine andere Frage. Die von Apple herausgegebenen Guidelines für iOS finden sich in den Human Interface Guidelines von Apple und sind damit maßgebend. Grundsätzlich gilt auch im Bereich der mobilen Systeme: Nativ erscheinenden Oberflächen ist stets der Vorzug zu geben. Einige Nutzer, die dieselbe App auf verschiedenen Geräten mit beiden Systemen verwenden, mögen erfreut sein, wenn eine Android-App sich ein wenig wie iOS anfühlt oder umgekehrt. Die meisten Nutzer dürfte es aber eher verwirren, denn sie sind in ihrem gewohnten System zu Hause.

Fazit

Cross-Platform-Entwicklung muss mit den unterschiedlichen Bedingungen auf den Zielsystemen zurechtkommen. In der kommenden Ausgabe des Windows Developer wird es konkret: Welche Ansätze gibt es, um iOS und Android mit einem Schlag in den Griff zu bekommen? Xamarin aus dem Hause Microsoft ist uns allen bekannt. Aber zu XAML und C# gibt es inzwischen Alternativen. Seien Sie gespannt

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -