RxSwift – Grundlagen und praktische Beispiele
Viele Anwendungsfälle erfordern die Implementierung asynchroner Tasks. Eine eigenständige Entwicklung ist häufig fehleranfällig, also muss ein Framework her. ReactiveX definiert eine API, die wiederum RxSwift implementiert, um die asynchronen Aufgaben durch reaktive Implementierung leichter lesbar, testbar und robuster zu machen.
- Mattes Wieben
Reaktive Programmierung bietet Entwicklern die Möglichkeit, Datenströme zu verarbeiten, die asynchrone Tasks erzeugen. Viel zu häufig wird Reaktivität jedoch durch die Verkettung von Callback-Funktionen realisiert. Das endet schnell in einer Pyramid of Doom.
ReactiveX verspricht, reaktive Programmierung zu vereinfachen und die Entstehung solcher Pyramiden zu verhindern. Die Popularität der API lässt sich durch die Reichweite seiner Nutzer zum Ausdruck bringen. Microsoft, Netflix, Github und AirBnBhaben die Vorteile erkannt und setzen auf ReactiveX.
Theoretische Basis
Bevor jedoch RxSwift zur Sprache kommt, erläutert der Artikel die theoretischen Grundlagen von ReactiveX. Dieses ist eine technologieagnostische API-Spezifikation, und RxSwift implementiert sie mit kleineren Änderungen und Erweiterungen. Neben Swift gibt es diverse weitere Sprachen, die ebenfalls ReactiveX implementieren. Dazu gehören Java mit RxJava, JavaScript mit RxJS und Python mit RxPy. Sind die Konzepte von ReactiveX einmal verinnerlicht, lassen sie sich nahezu überall analog anwenden.
Seine Entwickler beschreiben ReactiveX als "An API for asynchronous programming with observables". Die Definition setzt sich hauptsächlich aus drei Elementen zusammen, neben einer API aus
- asynchroner Programmierung: eine Art der Programmierung, die es erlaubt, langläufige Tasks unabhängig vom primären Programmfluss auszuführen.
- Observables: eine der fundamentalen Säulen von ReactiveX.
Ein Observable verkörpert eine Reihe von Events, die asynchron erzeugt werden. Häufig vergleicht man Observables mit Iterables. Der einzige Unterschied im Verständnis liegt darin, dass ein Observable im Laufe der Zeit, also asynchron, zusätzliche Elemente erhalten kann. Von diesen Events kann ein Observable beliebig viele erzeugen, von null bis unendlich. Folglich kann auch ein Observable endlich oder unendlich sein. Außer den Events emittiert es Benachrichtigungen für einen Fehlerfall beziehungsweise für das Ende der Event-Erzeugung. Die Benachrichtigungen signalisieren allen Observern, dass es keine weiteren Events von jenem Observable mehr geben wird.
Um auf die Events eines Observables zu reagieren, ist ein Observer zu erstellen. Er entsteht durch die Subscription auf einem Observable. Das bedeutet, eine Funktion wird beim Observable angemeldet und bei dem Erzeugen jedes Events mit eben jenem als Parameter aufgerufen. Die Benachrichtigungen des Observables, die am Ende oder im Fehlerfall verschickt werden, kann ein Observer separat behandeln.
(Bild: http://reactivex.io/documentation/observable.html)
Auf diesem Konzept baut der spannende Teil von ReactiveX auf, die Extensions – daher das X im Namen. Sie werden durch Operatoren implementiert und dienen dazu, den vom Observable erzeugten Datenstrom zu transformieren oder zu manipulieren.
Eine Übersicht aller Operatoren ist in der hervorragenden Dokumentation von ReactiveX zu finden, die jeden Operator beschreibt und veranschaulicht. Außerdem ist auf der Seite ein Entscheidungsbaum dokumentiert, der bei der Suche nach dem passenden Operator für einen Anwendungsfall unterstützt. Grob zusammengefasst lassen sich die Operatoren in die folgenden Kategorien einteilen:
- erzeugend
- transformierend
- filternd
- kombinierend
- fehlerbehandelnd
- aggregierend
Auf die Beschreibung weiterer Operatoren verzichtet der Autor an dieser Stelle, die wichtigsten stellt er später anhand praktischer Beispielen dar. Auch weiterführende Konzepte wie Scheduler und Subjects werden hier nicht weiter betrachtet.
