© Dabarti CGI/Shutterstock.com
Teil 4: .exe, .app und Co.: Mit Electron werden Desktops froh

Native Integrationen auf dem Desktop


Vom einfachen Texteditor über Mailprogramme und vollwertige IDEs bis hin zu 3-D-Anwendungen lassen sich alle möglichen Anwendungsfälle mit der Kombination aus HTML5, CSS3 und JavaScript abbilden. Soll sich die Anwendung wie zu Hause fühlen, muss sie sich oftmals auch ins Betriebssystem integrieren, um dem Benutzer den besten Komfort zu ermöglichen. Mit Electron wird die Möglichkeit geschaffen, aus dem Web heraus auf die Betriebssystem-APIs zuzugreifen.

Im ersten Teil der Artikelserie haben wir uns die Grundlagen von Webanwendungen angeschaut, sprich HTML5, CSS3 und JavaScript – in Kombination mit dem Anwendungsframework Angular [1]. Die APIs von Star Wars [2] und Pokémon [3] haben unsere Anwendung mit Daten versorgt. Im zweiten Teil der Serie haben wir uns mit dem Angular CLI vertraut gemacht und wie es uns als Build-System unterstützen kann. Dazu haben wir uns Begriffe wie Tree Shaking und Ahead-of-Time Compilation detaillierter angesehen und welche Auswirkung dies auf die Performance und Anwendungsgröße hat. Im dritten Teil haben wir mithilfe von Apache Cordova [4] unsere Anwendung in einen echten nativen mobilen Container verpackt, sodass die Anwendung als native App auf mobilen Betriebssystemen wie Android oder iOS lauffähig war. Wir haben hierbei das native „Teilen“-API angesprochen, um die „Teilen“-Funktion des Betriebssystems zu benutzen. Das ermöglichte uns, unser Pokémon mit unseren Freunden via WhatsApp, Twitter, Facebook oder weiteren Anwendungen zu teilen.

Wie auch die ersten drei Teile, wird dieser Teil der Artikelserie durch eine Beispielanwendung begleitet, die auf GitHub [5] zu finden ist. Es empfiehlt sich, den Code zum Artikel zu öffnen, da im Artikel nur Ausschnitte gezeigt werden können. In diesem Teil schauen wir uns genauer an, wie wir unsere Webanwendung als echte Desktopapplikation, also als .exe oder .app, paketieren können und wie wir Zugriff auf Betriebssystem-APIs erhalten. Zudem erweitern wir das Build-System, sodass wir das Paketieren automatisieren können.

Von Atomen und Elektronen

Electron [6], ehemals Atom Shell, ist ein Open-Source-Framework, das seit 2013 von GitHub entwickelt wird. Es kombiniert zum einen Node.js [7], das uns Zugriff auf das Betriebssystem ermöglicht, und zum anderen Chromium [8], die Open-Source-Variante von Google Chrome zur Anzeige unserer Webanwendung. Auch andere Entwickler setzen auf Electron, um ihre Anwendung auf dem Desktop zur Verfügung zu stellen, bspw. Discord, Slack, Atom oder Visual Studio Code.

Ähnlich wie bei Cordova aus dem dritten Teil der Artikelserie, stellt Electron uns einen nativen Anwendungsrahmen zur Verfügung und integriert Node.js und Chromium. Abbildung 1 zeigt die Architektur von Electron.

rauber_electron_1.tif_fmt1.jpgAbb. 1: Architektur einer Electron-basierten Anwendung

Das Architekturbild zeigt auf, dass jede Electron-Anwendung aus zwei Prozessen besteht. Die Basis bildet hierbei der Node.js-Prozess (Electron Main Process). Der Main-Prozess hat zwei Aufgaben. Zum einen kann er jegliche Node. js-Module benutzen, somit auf alle Betriebssystem-APIs zugreifen und sie der Webanwendung zugänglich machen. Zum anderen kümmert sich der Prozess um das Starten des zweiten Prozesses, dem Electron Rendering Process. In dem Rendering-Prozess läuft ein Chromium-basierter Browser, natürlich ohne den typischen Anwendungsrahmen (wie z. B. die Adress- oder Favoritenleiste), aber mit vollständigen Entwicklertools (Chrome DevTools) zum Debuggen. Innerhalb dieses Prozesses wird unsere Webanwendung geladen und dargestellt.

Sprich mit mir!

Als Kommunikationsmöglichkeiten zwischen Renderingprozess und Main-Prozess bzw. Betriebssystem stehen uns mehrere Möglichkeiten zur Verfügung.

Die erste Möglichkeit ist das Benutzen der von Electron bereitgestellten APIs. Für typische, nicht GUI-bezogene Einsatzzwecke stellt Electron ein API zur Verfügung, bspw. Zugriff auf die Shell, die Zwischenablage oder den Bildschirm.

GUI-bezogene APIs stehen bei Electron nur im Main-Prozess zur Verfügung, bspw. Dialoge, Menü oder Tray. Möchten wir diese APIs im Renderingprozess benutzen, sprich in unserer Anwendung, können wir hierfür die zweite Möglichkeit, Electron remote [9], nutzen. Electron remote kommuniziert über Inter-Process Communication (IPC). Beim Benutzen von Electron remote werden wie gewohnt Objekte erzeugt und Methoden aufgerufen. Im Hintergrund überträgt Electron remote diese Informationen als Nachrichten via IPC. Dieses Vorgehen ist ähnlich zu .NET Remoting oder Java Remote Method Invocation. Bei dieser Möglichkeit können natürlich nur serialisierbare Daten übertragen werden (bspw. keine JavaScript Callbacks).

Reichen uns die ersten beiden Möglichkeiten nicht aus, können wir auf die dritte Möglichkeit zurückgreifen: die Nutzung der IPC-Schnittstelle. Via IPC können wir selbst Nachrichten vom Main-Prozess zum Renderingprozess und umgekehrt schicken. Somit haben wir volle Kontrolle und Flexibilität über Nachrichten und Daten, womit sich jegliche Use Cases implementieren lassen.

Die Päckchen richtig packen

Durch die Auslieferung von Node.js und Chromium sind die paketierten Anwendungen größer – eine leere Anwendung ist etwa 120 MB groß, je nach Zielsystem. Allerdings haben wir auf jedem Desktopsystem für unsere Anwendung sowohl die gleiche Node.js-Version als auch die gleiche Chromium-Version. Das bedeutet, wir müssen unsere Anwendung für den Desktop nur innerhalb eines Browsers testen und sind nicht von den installierten Browsern auf dem Zielgerät abhängig. Chromium sorgt dafür, dass die Anwendung auf allen Zielsystemen korrekt gerendert wird. Im Vergleich zu Cordova oder dem Hosting der Anwendung auf einem Webserver, wobei wir unsere Anwendung in verschiedenen Browsern testen müssen, ist die Entwicklung und Paketierung für Desktopsysteme angenehm einfach.

Ein weiterer Vorteil der Paketierung ist, dass Elec­tron nicht von den SDKs des Zielsystems abhängig ist. Wenn wir uns an den Build-Prozess des dritten Teils von Cordova erinnern, wurde dort erwähnt, dass man eine iOS-Anwendung nur auf macOS bauen kann und eine Windows-Anwendung nur auf Windows, da die jeweiligen SDKs ausschließlich auf den Zielplattformen existieren. Der Build-Prozess von Electron ist durch Node.js tatsächlich Cross-Plattform und benötigt keine SDKs der Zielplattform. Das bedeutet, dass auf einem macOS-System eine Windows-.exe-Datei und auf einem Windows-System eine .ap...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang