Cross-Plattform-Programmierung für Desktopsysteme - Teil 4

Gearbeitet wird am Schreibtisch

Dr. Veikko Krypczyk

©Shutterstock / Stanislaw Mikulski

Windows, macOS und Linux sind die Systeme für den Desktop. Soll eine Anwendung auf all diesen Systemen laufen, ist Java seit langem Standard. Doch es gibt auch Alternativen. Von nativen Ansätzen bis zur Webtechnologie ist alles dabei.

In diesem Teil der Artikelserie beschäftigen wir uns mit unterschiedlichen Ansätzen, um Applikationen für den Desktop zu erstellen, die auf den relevanten Systemen Windows, Linux und macOS gleichermaßen laufen und aus einer gemeinsamen Quellcodebasis erstellt werden. Desktopapplikationen werden primär zum produktiven Arbeiten auf PCs und Notebooks eingesetzt. In vielen Bereichen wurden diese zwar in der Vergangenheit durch die deutlich flexibleren Webanwendungen abgelöst, aber es gibt nach wie vor gute Gründe, warum man sich für eine Desktopapplikation entscheiden sollte. Das sind vor allem:

  • Offlinefähigkeit: Desktopanwendungen bieten Offlinefunktionen. Wenn Sie die Textverarbeitung auf Ihren Computer heruntergeladen haben, können Sie jederzeit auf diese App zugreifen. Ihr Desktop ermöglicht es Ihnen, ohne Datenverbindung zu arbeiten. Befindet sich Ihr Dokument in einer Web-App, müssen Sie über eine Datenverbindung verfügen, um sicherzustellen, dass das Programm verfügbar ist. Aus diesem Grund erhöhen Desktopanwendungen die Produktivität.

  • Erhöhte Sicherheit: Desktopanwendungen bieten durch ihre Offlinefähigkeit eine erhöhte Sicherheit bei der Arbeit mit sensiblen Daten. Sie können Ihre LAN- oder WLAN-Verbindung trennen, wenn es notwendig ist. Mit einer Web-App sind Sie immer einem bestimmten Risiko einer Internetbedrohung (Datendiebstahl) ausgesetzt. Ihre Daten sind immer exponierter, da Sie Informationen auch nicht immer lokal speichern. Es gibt auch Programme, bei denen dieses Problem keine Rolle spielt. Bei Web Apps muss man vor dem Hintergrund der Datenschutz-Grundverordnung (DSGVO) auch den Standort des Servers klären. Viele brisante Daten dürfen den EU-Raum nicht verlassen. Sie müssen sicherstellen, dass der Betreiber bzw. Hoster der Web-App die Anforderungen der DSGVO erfüllt.

  • Arbeitsgeschwindigkeit: Die Ausführungsgeschwindigkeit hängt von der Geschwindigkeit Ihres Computers ab. Wenn Sie einen sehr schnellen Computer und eine sehr langsame Internet- oder Datenverbindung haben, hat eine Desktopanwendung einen erheblichen Vorteil. Sie nutzt den Arbeitsspeicher und die Verarbeitungsleistung Ihrer lokalen Ressourcen, um eine positive Nutzererfahrung zu erzielen. Wenn Sie mit einer Web-App arbeiten, hängen die Ergebnisse direkt von Ihrer Internetverbindung und -geschwindigkeit ab. Ist die Verbindung schlecht, spiegelt sich das auch in Ihrer Produktivität wider. In besonderen Anwendungsszenarien kann sich dieses Bild allerdings drehen. Ist die Geschwindigkeit der Internetverbindung nicht mehr der Flaschenhals, dann kann man über eine Webapplikation aufgrund der potenten Hardware in der Cloud eine größere Rechenpower nutzen.

  • Langfristig meist günstiger: Wenn Sie eine Desktopanwendung kaufen (Lizenz), haben Sie normalerweise erst einmal höhere Kosten als beim Kauf einer Web-App oder eines Abonnements. Doch wenn Sie die Kosten über die Laufzeit des Programms vergleichen, sind die einmaligen Kosten in der Regel günstiger als die laufenden Zahlungen.

  • Unabhängigkeit von Dritten: Desktopanwendungen erfordern keine Unterstützung von Dritten für ihre Verfügbarkeit. Solange das Gerät ordnungsgemäß funktioniert, können Sie jederzeit auf Ihre Daten zugreifen. Das verhält sich anders, wenn Sie mit Web-Apps arbeiten. Ist der Server aus irgendeinem Grund nicht verfügbar, haben Sie keinen Zugriff auf die gewünschten Informationen. Entscheiden Sie sich dagegen für eine Desktop-App, sind Sie nicht gezwungen, den Handlungen unbekannter Dritter zu vertrauen, um die Integrität Ihrer Dateien zu schützen. Andererseits ist man für die Bereitschaft und Aktualität der Desktopanwendung auch stets selbst verantwortlich.

  • Kein Upgradezwang: Desktopanwendungen zwingen Sie nicht zu einem Upgrade. Webanwendungen können Sie dagegen ohne Ihre Zustimmung zu Upgrades zwingen, da das Teil des automatischen Aktualisierungsprozesses ist. Wenn das Programm nach dem Update nicht wie gewünscht funktioniert, haben Sie ein Problem.

  • Uneingeschränkter Hardwarezugriff: Sie haben keine Einschränkungen beim Zugriff auf die Hardware des Systems und bei der Ansteuerung von spezifischen Ein- und Ausgabegeräten. Es ist i. d. R. eine vollständige und direkte Nutzung der Systemressourcen möglich.

Artikelserie

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

Teil 2: Mobile Apps sind weiter auf dem Vormarsch

Teil 3: Vorgehen am Beispiel von Apps für Android und iOS

Teil 4: Cross-Plattform-Programmierung für Desktopsysteme

Teil 5: Eine Desktopanwendung ist überall zu Hause

Das dominierende Betriebssystem für den Desktop ist seit vielen Jahren Microsoft Windows. Doch gibt es auch einen Anteil von Nutzern, die unter anderen Betriebssystemen arbeiten (Abb. 1).

Abb. 1: Marktanteile der Desktopbetriebssysteme [1]

Abb. 1: Marktanteile der Desktopbetriebssysteme [1]

Soll die Desktopapplikation auf unterschiedlichen Systemen laufen, dann sollten die Anwendungen aus einer gemeinsamen Quellcodebasis generiert werden. Die am häufigsten eingesetzte Variante sind Java-Applikationen. Doch es gibt auch eine Reihe von Alternativen.

User Interface als Engpass

Warum tut man sich immer relativ schwer mit der Cross-Plattform-Programmierung im Bereich der Desktopapplikationen? Die Antwort ist einfach: Insbesondere die recht großen Unterschiede der Systeme bei der Ansprache der grafischen Benutzeroberflächen führen gewissermaßen zu einem Engpass. Neben unterschiedlichen technischen Herangehensweisen gibt es unterschiedliche Controls, verschiedene Designrichtlinien usw. Eine Applikation, die auf allen Systemen läuft, muss diese Unterschiede berücksichtigen bzw. sich auf den kleinsten gemeinsamen Nenner beschränken. Möchte man native Applikationen erstellen, muss das Werkzeug in der Lage sein, aus einer allgemeinen Beschreibung der Benutzeroberfläche automatisch die passende Transformation in das Zielsystem abzuleiten.


Aktuell können wir das zum Beispiel an der Entwicklung von .NET verfolgen. .NET Core (künftig .NET 5.0) ist plattformübergreifend verfügbar [2]. Man kann es auf allen gängigen Systemen einsetzen. Möchte man jedoch grafische Desktopapplikationen erstellen, ist man schon deutlich eingeschränkter. Der folgende Absatz beleuchtet die aktuellen Möglichkeiten, um Desktopapplikationen mit Microsoft-Technologien zu erstellen, die über das Windows-System hinausreichen.

.NET Core als Basis

.NET Core steht für alle wichtigen Plattformen bereit [3]. Für die grafische Oberfläche stehen dabei bekanntermaßen die Systeme Windows Forms (WinForms), Windows Presentation Foundation (WPF) und die Universal Windows Platform (UWP) zur Verfügung. Microsoft migriert Windows Forms und WPF zurzeit vom großen .NET Framework über den Zwischenschritt .NET Core zur neuen Plattform .NET. Zusammen mit der UWP soll das Ganze in die WinUI-3.0-Plattform münden. Damit sind wir jedoch auf Windows-Systeme beschränkt, was das User Interface betrifft. Möchten Sie andere Systeme nutzen, können Sie Xamarin verwenden. Damit kann man nicht nur Apps für iOS und Android erstellen, sondern auch Applikationen für macOS, also für den Desktop (diese werden von Apple ebenfalls als Apps bezeichnet). Für Linux kann man auf diese Weise keine Anwendungen erstellen. Dazu müsste man auf Avalonia [4] ausweichen. Mit dieser Bibliothek kann man grafische Benutzeroberflächen für Windows, Linux und macOS erstellen. Der Ansatz ist deklarativ und verwendet einen XAML-Dialekt.

Java

Java gilt gewissermaßen als Standard, wenn es darum geht, plattformübergreifende Anwendungen zu programmieren. Ein Java-Programm wird nach dem in Abbildung 2 gezeigten Prinzip erstellt.

Abb. 2: Vom Quellcode zum ausführbaren Programm [5]

Abb. 2: Vom Quellcode zum ausführbaren Programm [5]

Java-Quellcode kann mit einem beliebigen Texteditor oder, wie in der Praxis üblich, mit einer umfassenden und komfortablen IDE erstellt werden. Der Compiler erzeugt den sogenannten Zwischencode (Java-Bytecode), der später in der jeweiligen virtuellen Maschine auf dem Zielbetriebssystem ausgeführt wird. Java-Programme laufen nicht nativ auf dem Rechner, sondern werden stets in einer Art Sandbox ausgeführt. Diese Sandbox, Java Virtual Machine genannt, kümmert sich um die plattformspezifische Umsetzung. Die konkrete Umsetzung auf der Zielplattform, z. B. die grafische Benutzeroberfläche (UI), erledigt die JVM. Allerdings muss man diese Aussage einschränken, denn komplexe Programme, die systemspezifische Funktionen nutzen, bedürfen dennoch an der einen oder anderen Stelle der expliziten Anpassung an das Zielbetriebssystem. Das gilt jedoch für jeden Ansatz der Cross-Plattform-Programmierung. Bei der Wahl der Entwicklungsumgebung ist man nicht eingeschränkt. Bekannte, unter allen üblichen Betriebssystemen lauffähige Werkzeuge sind zum Beispiel: Eclipse, IntelliJ und NetBeans.

Die Java-Plattform bietet eine große Zahl von Bausteinen, die man zu dem gewünschten User Interface zusammenfügen kann. Dabei folgt der Aufbau dem Baukastenprinzip. Vorgefertigte Komponenten werden miteinander verschachtelt und kombiniert. Die Komponenten sind dabei einzelne Klassen, die Bestandteil einer umfassenden Klassenbibliothek sind. Die Klassen für die Komponenten des User Interface gehören zu den Paketen java.awt und javax.swing. Das Abstract Window Toolkit (AWT) ist so ausgelegt, dass alle Elemente der Oberfläche durch das Betriebssystem zur Verfügung gestellt werden. Damit ist AWT durch den kleinsten gemeinsamen Nenner aller Betriebssysteme beschränkt. Man bezeichnet diese Vorgehensweise als Peer-Ansatz, weil die AWT-Komponenten alle Aktionen an plattformspezifische GUI-Objekte (Peers) weiterreichen. Auf unterschiedlichen Betriebssystemen sehen daher Java-Anwendungen, die auf der Basis von AWT erstellt werden, unterschiedlich aus. AWT-Komponenten werden als schwergewichtig (heavyweight) bezeichnet. Die Swing-Klassen basieren auf einem anderen Ansatz. Sie sind fast alle selbst in Java programmiert, damit leichtgewichtig (lightweight) und benutzen nur dort, wo es notwendig ist (Top-Level-Container), plattformspezifische Funktionen. Das Design kann unabhängig vom Betriebssystem gestaltet werden, und es ist sogar eine Anpassung zur Laufzeit möglich. Programme auf der Basis von Swing sehen daher auf allen Betriebssystemen gleich aus.

Deutlich mehr visuellen Glanz verspricht die Bibliothek JavaFX. Sie ist seit einigen Versionen Bestandteil des JDK und muss nicht erst extra installiert werden. Abbildung 3 zeigt, wie sich JavaFX in die Architektur einer Java-Anwendung integriert.

Abb. 3: Architektur von JavaFX [6]

Abb. 3: Architektur von JavaFX [6]

Auf unterster Ebene befindet sich erwartungsgemäß die Java Virtual Machine (JVM). Bei Prism handelt es sich um eine Rendering Engine für Grafiken. Diese greift auf die Grafikhardware des Rechners zurück. Unter den Betriebssystemen macOS und Linux wird mit Hilfe von OpenGL gerendert. Unter Windows wird Direct3D verwendet. Gibt es keine Unterstützung durch die Hardware beim Rendering, so wird auf Java2D zurückgegriffen. Das Glass Windowing Toolkit stellt Low-Level-Betriebssystemroutinen zur Verfügung. Dazu gehören die Fenster- und die Ereignisverwaltung. Die Media Engine bietet Unterstützung für Audio und Video. Die Web Engine ermöglicht das Einbetten von Webinhalten. Alle genannten Elemente von JavaFX werden über das Quantum Toolkit miteinander verknüpft. Dem Programmierer wird ein JavaFX API zur Verfügung gestellt. Darüber erfolgt die gesamte Kommunikation.

RAD Studio, Delphi, C++-Builder mit FireMonkey

RAD Studio [7] hatten wir bereits im zweiten Teil der Serie erwähnt, wo es um das Erstellen von nativen Apps für iOS und Android ging. Traditionell ist die integrierte Entwicklungsumgebung jedoch dafür prädestiniert, Desktopapplikationen für Microsoft-Windows-Betriebssysteme zu erstellen. Durch den Einsatz des Framework FireMonkey ist es möglich, auch Applikationen zu erstellen, die unmittelbar auf Windows, macOS und Linux-Distributionen ausgeführt werden können. Zu RAD Studio gehören Delphi und C++-Builder. In Delphi arbeitet man mit einer modernen und weiterentwickelten Version von Object Pascal. Beim C++ Builder arbeitet der Programmierer mit den aktuellen Sprachfeatures von C++. RAD Studio erzeugt native Applikationen, die auf den Zielsystemen ohne die Abhängigkeiten von weiteren Systembibliotheken laufen. Während der Entwicklung wird das User Interface mit Hilfe eines grafischen Designers aus Komponenten erstellt. Verschiedene Layoutcontainer ermöglichen es, die Elemente des User Interface relativ zueinander zu positionieren und damit die Anforderungen der unterschiedlichsten Geräteklassen bezüglich Bildschirmauflösung und -größe gemeinsam zu erfüllen. FireMonkey ermöglicht eine moderne Gestaltung des User Interface, auch 3D-Darstellungen werden unterstützt. Zur Entkopplung der Präsentations- von der Datenhaltungsschicht dienen sogenannte Live Bindings. Auf diese Weise können Elemente des User Interface an die Daten- oder Modellschicht gekoppelt werden, ohne dass dazu Quellcode geschrieben werden müsste. Der Designer erlaubt eine direkte Vorschau der definierten Screens. Soll für mehrere Gerätetypen entwickelt werden, so gibt es die Möglichkeit der geräteübergreifenden Vorschau. Damit kann die Gestaltung der Benutzerschnittstelle erheblich beschleunigt werden. Welche Plattformen man unterstützen möchte, legt man bei der Installation fest (Abb. 4).

Abb. 4: Auswahl der Zielplattformen bei RAD Studio

Abb. 4: Auswahl der Zielplattformen bei RAD Studio

Die Entwicklung der Applikation erfolgt dann unter Microsoft Windows. Die Zielplattform kann direkt in der Entwicklungsumgebung erstellt werden. Um Apps für macOS zu erstellen, benötigt man den Zugriff auf Xcode und einen Mac. Linux und macOS können direkt aus der Entwicklungsumgebung angesprochen werden. Auf beiden Zielsystemen wird dazu der sogenannte PAServer (Platform Assistent Server) installiert, der die Fernsteuerung von Linux bzw. macOS erlaubt (Abb. 5).

Abb. 5: Systemumgebung, um Cross-Plattform-Anwendungen mit RAD Studio zu erstellen

Abb. 5: Systemumgebung, um Cross-Plattform-Anwendungen mit RAD Studio zu erstellen

Bereits während der Designzeit der Programmoberfläche wird dem Entwickler bei der Auswahl der betreffenden Steuerelemente interaktiv angezeigt, ob diese für die Zielplattform zur Verfügung stehen. Der komponentenbasierte Ansatz beschränkt sich nicht auf die Umsetzung des User Interface, sondern umfasst auch weitere Elemente der Applikation, sogenannte nichtvisuelle Controls. Auf diese Weise ist es möglich, typische Aufgaben einer Desktopanwendung mit wenigen Mausklicks zu integrieren. Dazu gehören zum Beispiel die komponentenbasierte Anbindung von Datenbanken oder die Steuerung von Hardwareschnittstellen.

Qt

Das Framework Qt [8] darf in diesem Überblick nicht fehlen. Das umfassende Framework bietet Werkzeuge, um plattformübergreifend Benutzeroberflächen zu erstellen. Qt beinhaltet mit QML eine eigene Auszeichnungssprache, die das Erstellen der Oberflächen vereinfacht. Das Framework kann sehr gut mit anderen Programmiersprachen, zum Beispiel Python oder Java, verwendet werden. Qt ist mittlerweile stark modular aufgebaut, wodurch das System flexibel einsatzbar ist. Wichtige Module sind zum Beispiel: Qt Core (Kernklassen), Qt GUI (Basisklassen für das UI), Qt QML (Framework und Typen für die Auszeichnungssprache QML), Qt Quick Dialogs (Systemdialoge) usw. Qt bietet eine eigene integrierte Entwicklungsumgebung, den Qt Creator. Dieser enthält u. a. den Qt Designer, um die grafischen Oberflächen mit Hilfe der Qt Widgets zu erstellen. Einen Überblick über die Qt-Klassenbibliothek gibt Abbildung 6.

Abb. 6: Qt-Klassenbibliothek [9]

Abb. 6: Qt-Klassenbibliothek [9]

Bei der Gestaltung der Benutzeroberfläche bietet Qt zwei unterschiedliche Möglichkeiten. Einerseits steht mit dem Qt Designer ein WYSIWYG-Editor zur Verfügung, der eng an die Qt Widgets geknüpft ist. Andererseits ist mit Qt Quick eine Alternative auswählbar, die die Entwicklung mit der Sprache QML ermöglicht. Prägend für den Ansatz von Qt ist das Signal-Slot-Konzept. Bei einem Signal handelt es sich um eine Nachricht, die ein Objekt sendet, sobald ein bestimmtes Ereignis eintritt. Ein Slot wiederum ist eine Funktion, die mit einem Signal verknüpft wird. Diese Funktion wird dann ausgeführt, wenn sie das Signal erhält. Es ist einerseits möglich, ein Signal mit mehreren Slots zu verknüpfen, sodass mehrere Funktionen als Folge eines Ereignisses gestartet werden. Andererseits kann ein Slot durch mehrere Signale ausgelöst werden, d. h., dieselbe Funktion wird durch unterschiedliche Ereignisse aufgerufen. Das System KDE Plasma (Desktopumgebung für Linux) ist wohl eines der bekanntesten Softwareprojekte, die mit Hilfe von Qt realisiert werden.

Electron und Co.

Nun sehen wir uns Technologien und Vorgehensweisen an, um eine Webapplikation für den Desktop zum Laufen zu bringen. Bei NW.js [10] handelt es sich um ein Framework zur Erstellung von Desktopanwendungen in HTML, CSS und JavaScript. Der Hintergrund: Die Webapplikationen werden mit der Browser-Engine WebKit kombiniert. Dadurch können Anwendungsfenster erstellt werden, die die Webapplikation auf dem Zielsystem darstellen können. Darüber hinaus kann man über WebKit auf native Betriebssystemfunktionen zugreifen. Mit Hilfe von NW.js kann man die Webapplikation dann zu einer Desktopanwendung verpacken (Packaging). Dabei gibt man das Zielsystem, zum Beispiel Windows oder macOS, vor.

Sehr oft wird im Moment das Framework Electron [11] erwähnt. Auch Electron erlaubt es, aus Webapplikationen entsprechende Desktopanwendungen zu erstellen. Bekannte, mit Electron erstellte Applikationen sind die Codeeditoren Atom und Visual Studio Code. Auf der Website findet sich eine umfassende Liste von Applikationen, die mit Electron programmiert wurden. Der technische Ansatz ähnelt dem von NW.js, auch hier wird mit WebKit gearbeitet. Doch gibt es einen wichtigen Unterschied zwischen NW.js und Electron. In NW.js teilen sich Node.js und WebKit einen einzelnen JavaScript-Kontext. Dagegen werden in Electron mehrere Kontexte verwendet, einer für den Hintergrundprozess, der die Anwendung steuert, und jeweils ein Kontext für das Anwendungsfenster. Es gibt also i. d. R. mehrere Renderingprozesse. In NW.js ist der Einstiegspunkt eine HTML-Datei, in Electron ist es eine JavaScript-Datei. Abbildung 7 illustriert, wie aus den einzelnen Dateien des Webprojekts (HTML, CSS, JavaScript) und einer Konfigurationsdatei (package.json) mit Hilfe von NW.js durch Packaging eine Desktopanwendung für das gewünschte System generiert wird.

Abb. 7: Der Packaging-Prozess von NW.js im Überblick [12]

Abb. 7: Der Packaging-Prozess von NW.js im Überblick [12]

Im Vergleich dazu sehen Sie in Abbildung 8 die Zusammenarbeit der einzelnen Komponenten, insbesondere der Renderingprozesse, bei einer Electron-App.

Abb. 8: Die Electron-Architektur [13]; IPC: Inter-Process Communication

Abb. 8: Die Electron-Architektur [13]; IPC: Inter-Process Communication

Weitere Ansätze

Weitere Möglichkeiten bestehen in hochintegrierten Tools, mit denen man Applikationen für die unterschiedlichsten Systeme auf primär grafischem Weg bzw. durch umfassende Toolunterstützung erstellen kann. Dazu gehören zum Beispiel: 8th [14]; B4J [15], ähnlich Visual Basic; Kivy [16], ein Open-Source-Python-GUI-Framework; Haxe [17] und Xojo [18]. Diese Tools sind i. d. R. auf eine bestimmte Art von Applikationstyp, zum Beispiel Businessanwendungen, ausgerichtet, und man versucht den Erstellungsprozess durch umfassende Werkzeugunterstützung weiter zu vereinfachen.

Auswahlkriterien

Welcher Ansatz ist in einem konkreten Fall geeignet? Wie immer kommt es auf die Ziele und Voraussetzungen an. Java-Applikationen sind Standard und im Businessumfeld gut etabliert. Ein riesiger Fundus an Bibliotheken, Werkzeugen und Lösungsansätzen steht zur Verfügung. Es entstehen jedoch keine nativen Applikationen. Das ist wiederum bei RAD Studio der Fall. Dort haben wir es mit einer stark komponentenbasierten Entwicklungsumgebung zu tun, die den Entwicklungsprozess erheblich beschleunigt. Ein anderer Aspekt ist das Betriebssystem, das primär zu unterstützen ist, und/oder die weiteren Systeme, zum Beispiel Android oder iOS, für die ebenfalls Applikationen bereitzustellen sind. Mit Qt und RAD Studio kann man sehr gut den Desktop sowie die mobile Welt bedienen. Geht die Entwicklung in Richtung Webapplikationen bzw. sollen Ansätze aus der Webprogrammierung zum Einsatz kommen, dann kann man zum Beispiel Frameworks wie Electron auf ihre Eignung prüfen.

Fazit und Ausblick

Desktopapplikationen werden für die Betriebssysteme Windows, macOS und Linux-Distributionen erstellt. Am besten geschieht das aus einem Quellcode heraus. Der Artikel hat Ihnen einige typische Varianten vorgestellt. Mit Electron und Co. kommen die Webapplikationen gewissermaßen wieder auf den Desktop zurück. Im kommenden und abschließenden Teil der Artikelserie wollen wir den einen oder anderen Ansatz in der Praxis ausprobieren.

Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://larinet.com

Links & Literatur

Verwandte Themen:

Geschrieben von
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk studierte und promovierte in Betriebswirtschaftslehre mit dem Schwerpunkt Wirtschaftsinformatik. Er ist Entwickler und Fachautor. Aktuell beschäftigt er sich mit der App-Programmierung für Windows Phone und Android.
Kommentare

1
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Bughunter Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Bughunter
Gast
Bughunter

„Deutlich mehr visuellen Glanz verspricht die Bibliothek JavaFX. Sie ist seit einigen Versionen Bestandteil des JDK und muss nicht erst extra installiert werden.“
Aus welchem Jahrhundert stammt denn dieser Artikel? Hat da jemand die Entwicklungen der letzten Jahre vewrschlafen?