Aus Linux-Magazin 02/2018

Framework für universelle Desktop-Apps

© generalfmv, 123RF

Ordert der Chef eine Desktop-App für den internen Gebrauch, fehlt dem gestressten IT-ler oft die Zeit, sich langwierig in C++/Qt, Java oder Python und das zugehörige Application Packaging reinzufuchsen. Wirft er den Code in Githubs Teilchenbeschleuniger Electron, darf er auf schnellere Erfolge hoffen.

Bei der Open-Source-Software Electron [1], so verspricht Hersteller Github, übernimmt das Framework selbst den harten Teil der Arbeit: Es paketiert etwa die vom Entwickler programmierte Software als eine installierbare App für Linux, Windows und OS X. Dazu verpackt Electron die Anwendung zusammen mit weiteren Dateien in Plattform-spezifischen Paketformaten, unter Linux etwa Deb oder RPM. Mit ins Paket legt das Framework zudem die Binärdateien seiner Laufzeitumgebung, die Rendering- und Javascript-Engine von Chromium [2] sowie die Javascript-basierte Programmierumgebung Node [3].

Die mit Electron erzeugten Apps bestehen aus HTML, CSS sowie Javascript und unterscheiden sich in Sachen Erscheinung, Bedienbarkeit und beim Funktionsumfang kaum von herkömmlichen Desktop-Apps. Der Clou: Die Anwendungen aktualisieren sich auch selbsttätig. Automatische Updates ziehen sie über einen Update-Server aus bekannten Quellen, wie einem Github-Repository.

Electrons Entstehungsgeschichte

An Electron arbeitet Github seit 2013, es trug zunächst den Namen Atom Shell und war ein Closed-Source-Projekt. Ab Mai 2014 erschien das Framework unter der MIT-Lizenz, ein Jahr später benannte Github es in Electron um. Version 1.0.0 kam 2016 heraus, ab diesem Jahr erhielten die Apps auch Zugang zu den App-Stores von OS X und Windows.

Der Artikel behandelt in seinem ersten Teil zunächst die grundlegende Funktionsweise und das Packen von Electron-Applikationen anhand einer Boilerplate-App aus dem Node-Package »electron-forge«. Ein zweiter Teil demonstriert in einer zukünftigen Ausgabe die systemnahe Programmierung unter Electron anhand einer Beispiel-App.

Kühner Entwurf

Eine Electron-App funktioniert wie eine Webapp – jedoch in der reduzierten Browserumgebung, die Abbildung 1 skizziert. Die Komponenten von Chromium führen die Webapp aus (oben rechts im Bild). Javascript-Bibliotheken wie Bootstrap [4], React [5], Angular [6] oder Jquery [7] tragen ihren Teil zum Gesamtwerk bei.

Abbildung 1: Der Main-Prozess ersetzt den Browserkernel als frei programmierbares Gerüst mit Systemanbindung.

Abbildung 1: Der Main-Prozess ersetzt den Browserkernel als frei programmierbares Gerüst mit Systemanbindung.

Electron-Apps punkten gegenüber herkömmlichen Webapps mit einem weiteren Vorteil: Browser-spezifische Unterschiede spielen keine Rolle, denn die universelle App läuft auf allen System stets unter Chromium. Das verringert den Entwicklungsaufwand und macht die programmierte Anwendung robuster. Entwickler profitieren von den Debugging-Tools, die ebenfalls aus dem Hause Chromium stammen. Wie Abbildung 2 rechts im Bild ahnen lässt, sind diese Tools auch voll einsatzfähig.

Abbildung 2: Links grüßt die Webapp, die Debugging-Tools lassen sich in der finalen Version ausschalten.

Abbildung 2: Links grüßt die Webapp, die Debugging-Tools lassen sich in der finalen Version ausschalten.

Der so genannte Main Process, bei Abbildung 1 links im Bild zu sehen, verwaltet die Browserfenster und kümmert sich um die Anbindung an das Desktop-Betriebssystem. Node hält den Main-Prozess unter Kontrolle und verwendet das Electron-API Betriebssystem-seitig, um Menüs, Benachrichtigungen oder den Zugriff auf das Dateisystem zu ermöglichen. Der Entwickler erweitert das API dann um beliebige Node-Pakete.

Framework installieren

Electron, die darauf aufbauenden Boilerplate-Projekte und Werkzeuge wie »electron-packer«, »electron-builder« oder »electron-forge« erscheinen allesamt in Form von Node-Paketen. Listing 1 installiert auf einem Ubuntu 16.04 Node, Electron sowie sämtliche Tools, die ein Entwickler zum Packen der Electron-Apps benötigt. Zeile 1 installiert Git und Curl über den Paketmanager, Zeile 3 die neueste Version von Node 8. Die dazu nötige Paketliste legt ein Bash-Skript, das Curl in Zeile 2 holt, unter »/etc/apt/sources.list.d/nodesource.list« an, um dann die Liste mit verfügbaren Paketen über Apt-get zu aktualisieren.

Listing 1

Node installieren

01 sudo apt-get install git curl
02 sudo curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
03 sudo apt-get install -y nodejs
04 npm install yarn
05 sudo su
06 # es geht auch ohne Yarn mit: sudo npm -g install electron-forge
07 yarn add global electron-forge

Nach »nodejs« in Zeile 3 spielt das Skript eine Zeile später noch den alternativen Node-Paketmanager Yarn [8] ein. Mit Rootrechten installiert Yarn dann in Zeile 6 seinerseits »electron-forge« [9].

Bühne frei

Für Electron existiert eine Reihe historisch gewachsener Boilerplate-Projekte [10], die den Entwicklungsprozess beschleunigen, indem sie eine lauffähige Minimal-App out of the Box bereitstellen. Diese Projekte verwenden intern »electron-packer«, um lauffähige Electron-Apps zu erzeugen, und »electron-builder« zum Paketieren Plattform-spezifischer Formate. Die beste Kombination aus beiden Tools bietet das in Listing 1 installierte »electron-forge«, das übrigens ebenfalls aus der Werkstatt der Macher von »electron-packer« und »electron-builder« stammt. Das gleichnamige Shellkommando »forge« macht dabei Gebrauch von »electron-forge«.

Der Lebenszyklus einer App nimmt seinen Lauf, sobald der Entwickler den Befehl »forge init app« in die Tastatur hackt. Der erzeugt das Projektverzeichnis »app« aus Listing 2 im Stile eines Boilerplate-Projekts. Wie bei jeder Node-App speichert das Verzeichnis »node_modules« alle Pakete, die die Konfigurationsdatei »package.json« aufführt – in der jeweils neuesten Version.

Listing 2

Boilerplate-App

01 |- app
02   |- node_modules
03   |- package.json
04   |- src
05   |- yarn.lock

Das Verzeichnis »src« speichert schließlich die minimale Webapp, die der Entwickler in der Folge schrittweise in seine Wunschanwendung umbaut.

Initial enthält das Verzeichnis das HTML-Dokument »index.html« und damit sozusagen die gesamte Webapp sowie mit der Datei »index.js« den Hauptprozess. Den Entwicklungsfortschritt überprüft der Programmierer, indem er in das Projektverzeichnis »app« wechselt und den Befehl »forge init start« eingibt. Da ein Watch-Prozess wie unter Angular [6] fehlt, lädt ein »location.reload()« über die Debugging-Konsole die App neu.

Abbildung 2 zeigt die gestartet App zur Laufzeit. Im Chromium-Fenster taucht rechts im Bild das Debugging-Tool standardmäßig auf. In der finalen Version muss der Entwickler daran denken, die Debugging-Tools im Hauptprozess-Code zu deaktivieren.

Die Datei »yarn.lock« aus Zeile 5 in Listing 2 merkt sich – analog zur »packages.lock« unter Npm – die aktuell unter »node_modules« gespeicherten Pakete samt ihren jeweiligen Versionsnummern. Dieser Mechanismus ermöglicht die Reproduktion von Node-Projekten auf anderen Maschinen im Maßstab 1 zu 1.

Portieren

Die Boilerplate-App aus Abbildung 2 auf andere Desktopsysteme portieren, dabei hilft der Befehl »forge package«. Ohne Angabe von Optionen erzeugt der Befehl unter Ubuntu 16.04 eine Stand-alone-Version für Linux und die vorliegende x64-Prozessorarchitektur im Unterverzeichnis »out/app-linux-x64« des Projektordners »app«. Dieses Verzeichnis enthält neben der etwa 80 MByte großen ausführbaren Datei »app« im ELF-Format noch weitere Binärdateien. Unter »resources/app« finden sich die Webapplikation und die benötigten Node-Pakete. Nach dem Wechsel in das Verzeichnis startet der Befehl »./app« die App in der Shell, die exakt aussieht wie in Abbildung 2.

Die Portierung der App nach Windows übernimmt der Kommandozeilenschalter »–platform« im Befehl »forge package –platform win32«. Der erzeugt die App für 64-Bit-Windows analog zu Linux im Ordner »out/app-win32-x64«. Die Distribution enthält neben der ausführbaren Datei »app.exe« eine Vielzahl Windows- typischer DLLs sowie den Ordner »resources«. Der ist annähernd Bit-gleich zu dem unter Linux.

Wer den Ordner von Linux auf ein Windows-10-System kopiert und die App startet, sieht auch hier keinen nennenswerten Unterschied zu Abbildung 2. Umgekehrt lässt sich »electron-forge« auch unter Windows 10 installieren. In diesem Fall läuft die unter Windows erzeugte Linux-App dann unter Linux.

Tabelle 1

Kompatibilität von Electron

System Version ia32 x64 armv7l arm64
Ubuntu >=12.04 ja ja (getestet) ja ja
Debian 8 ja ja ja ja
Fedora 21 ja ja ja ja
Windows >=7 ja ja (getestet) ja ja
OS X >=10.9 nein ja nein ja

Unterschiedliche Prozessorarchitekturen lassen sich dem Kommandozeilenschalter »arch« mit auf den Weg geben. Die möglichen Kombinationen der Werte für »platform« und »arch« zeigt Tabelle 1.

Packen

Um eine App einfach zu verteilen, bietet »forge« an, auch Plattform-spezifische Paketformate oder Installer zu erzeugen (Tabelle 2). Ein »forge make« generiert für die Boilerplate-App ein Debian-Paket. Das Skript brach im Test aber beim Erzeugen eines RPM-Pakets zunächst mit der Fehlermeldung aus Abbildung 3 ab. Ein »sudo apt-get install rpm« behob aber das Problem.

Tabelle 2

Mögliche Paketformate unter “forge”

Typ System Beschreibung
»zip« alle Zip-Archiv
»squirrel« Windows Installer für Squirell-Dot-Windows
»appx« Windows Windows-Store-Paket
»dmg« OS X Darwin DMG-Paket
»deb« Linux Debian-Paket
»rpm« Linux RPM-Paket
»flatpack« Linux Flatpack-Paket

Ähnliche Szenen spielten sich beim Versuch ab, mit dem Befehl »forge make –platform win32« einen Windows-Installer zu erzeugen. Hier fehlte die Dotnet-Unterstützung, die ein »sudo apt-get install mono wine« aber nachliefert. Unter »out/make/squirell.Windows/x64« findet sich dann die Installer-Datei »app-1.0.0 Setup.exe«, die sich im Test problemlos unter Windows 10 installieren ließ.

Abbildung 3: Der Start von <code>rpmbuild</code> als ein eigener Prozess mittels <code>spawn</code> schlug zun&auml;chst fehl, weil <code>rpm</code> noch nicht installiert war.

Abbildung 3: Der Start von »rpmbuild« als ein eigener Prozess mittels »spawn« schlug zunächst fehl, weil »rpm« noch nicht installiert war.

Listing 3 zeigt das Konfigurationsobjekt [11] aus der Datei »package.json« als Ausschnitt. Die Zeilen 2 bis 13 enthalten die zu erzeugenden Paketformate im Unterobjekt »make_targets«, aufgelistet nach Betriebssystem.

Listing 3

Konfiguration von forge

01 [...]
02 "forge": {
03  "make_targets": {
04   "win32": [
05    "squirrel"
06   ],
07   "darwin": [
08    "zip"
09   ],
10   "linux": [
11    "deb",
12    "rpm"
13   ]
14  },
15  "electronPackagerConfig": {
16   "packageManager": "yarn"
17  },
18  "electronWinstallerConfig": {
19   "name": "app"
20  },
21  "electronInstallerDebian": {},
22  "electronInstallerRedhat": {},
23  "github_repository": {
24   "owner": "",
25   "name": ""
26  },
27  "windowsStoreConfig": {
28   "packageName": "",
29   "name": "app"
30  }
31 }
32 [...]

Fazit

Electron vereinfacht es, Desktop-Apps zu erstellen, indem es populäre Webtechnologien wie HTML, CSS und Javascript nutzt. Zugleich bietet es eine Infrastruktur an, die Apps per Kommandozeile auf andere Systeme portieren kann.

Verglichen mit Cordova Phone Gap [12] ist die Installation trivial, wenn derzeit auch noch der Support für mobile Betriebssysteme wie Android oder I-OS fehlt. Wer auf Nummer sicher gehen möchte, paketiert einfach jeweils auf dem Zielsystem. Das hat den Vorteil, dass sich die App dort auch gleich testen lässt. Ein Folgeartikel wird dann anhand einer etwas komplexeren Beispiel-App eruieren, wie einfach oder kompliziert sich bestimmte, häufig genutzte Features implementieren lassen.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 4 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
1 Kommentar
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Bauinformatiker
7 Jahre her

Gibt es eine Liste mit Electron-basierter Software?

Möchte wissen, welche Programme jetzt diese Sicherheitslücke aus Chrome “mitschleppen”.

https://www.heise.de/security/meldung/Jetzt-patchen-Exploit-Code-fuer-Google-Chrome-in-Umlauf-4328122.html

Nach oben