© Goran Jakus/Shutterstock.com
Realtime-Cross-Platform-Applikationen – Teil 1

Das Signal zur Echtzeit


Moderne Webapplikationen sind im Browser lauffähig und somit auf verschiedenen Betriebssystemen anwendbar. Aber wenn eine Anwendung einmal für das Web geschrieben ist, wie überträgt man sie als App auf die mobile Plattform? Und von dort weiter auf den Desktop, falls der gewünschte Browser nicht installiert werden kann? Das alles lässt sich durch Cross-Platform-Entwicklung bewerkstelligen und Entwickler können sich durch das Hinzufügen der Echtzeitkomponente noch weiter die Arbeit erleichtern.

Verteilte Applikationen haben heutzutage den Anspruch, auf allen möglichen Plattformen zur Verfügung zu stehen. Cross-Platform eben. Dazu gehören nicht nur Mac, Linux und Windows, also der Einsatz auf verschiedenen Betriebssystemen. Vielmehr wird bei verteilten Anwendungen auch Wert auf die Benutzbarkeit durch mobile Apps, Desktops und Webanwendungen gelegt. Unter anderem machen es Spotify oder Slack schon vor.

Als Beispiel einer Web-App, die auch auf einer mobilen Plattform oder dem Desktop installiert werden soll, wird in diesem ersten Serienteil eine Angular-Anwendung als Startpunkt verwendet. Sie wurde mit der Angular CLI erstellt, läuft im Browser und soll nun auf verschiedene Systeme portiert werden. Weiter wollen wir sicherstellen, dass etwaige Änderungen an den verschiedenen Apps auch auf allen anderen Apps zu Aktualisierungen führen. Der Status der App sollte geändert und durch Benachrichtigungen oder automatisches Aktualisieren der Benutzeroberfläche auf dem neusten Stand gehalten werden. Das Backend ist im Beispiel eine bestehende ASP.NET-Core-Applikation, die einen REST-Endpunkt bietet. Weder Frontend noch Backend implementieren bis zu diesem Zeitpunkt eine Realtime-Aktualisierungsfunktionalität. Der Code zu diesem Beispiel kann auf GitHub [1], [2] gefunden werden.

Separierung von Front- und Backend

Bevor wir den ersten Schritt gehen können, brauchen wir eine klare Separierung von Front- und Backend. Hierbei geht es um die klare Abgrenzung der Datenquelle von der Clientapplikation selbst. Die Datenquelle als Back-end kann ein REST-Endpunkt sein. Dieser bekommt HTTP-Anfragen geschickt und sendet Antworten an den Client zurück, die die entsprechenden Informationen wie Statuscode und eventuell angeforderte Daten enthalten. In unserem Beispiel ist es ein REST-Endpunkt in ASP.NET Core, der auf Azure gehostet ist und somit von jeder Art von Applikation konsumiert werden kann. Das Frontend ist eine komplett getrennte Angular-Applikation, die von ihrem Backend ausschließlich den URL kennt. In Abbildung 1 sieht man das Beispiel-API. Der nächste Schritt besteht darin, SignalR zur ASP.NET-Core-Applikation hinzuzufügen. So erhält sie den Echtzeitfaktor.

gosebrink_crossplatform_teil1_1.tif_fmt1.jpgAbb. 1: Screenshot des Endpunkts mit Swagger-Dokumentation

Funktionsweise von SignalR

Um das Backend mit einer Realtimefunktionalität auszustatten, greifen wir auf die Open-Source-Library SignalR [3] von Microsoft zurück. Die Clients müssen mit ihr nicht mehr manuell eine Aktualisierung ihrer Daten anfordern, sondern bekommen Aktualisierungen per Event direkt zugesendet. Falls sie interessiert sind, registrieren sie sich auf das Event und handeln bei dem Event entsprechend. SignalR ist eine Dachtechnologie, die verschiedene Updatemechanismen für uns in einer einzigen Library kapselt. Hierbei werden nacheinander automatisch die folgenden Technologien für einen Echtzeitaustausch abgefragt:

  1. WebSockets

  2. Server-sent Events

  3. Long Polling

In einer Verhandlungsphase klärt die Library zwischen Client und Server ab, welche Technologie möglich ist und baut danach die Verbindung auf. Anschließend können die Aktualisierungen hin- und hergeschickt werden. SignalR stellt die Kommunikation bzw. die gemeinsame Schnittstelle, über die die Kommunikation laufen kann mit Hilfe von Hubs sicher. Methoden, die auf einem Hub implementiert sind, können vom Client auf dem Server aufgerufen werden. Im Gegenzug kann der Server Events an den Client schicken, auf die dieser dann wiederum reagieren kann. Hierbei wird das Serialisieren und Deserialisieren in beide Richtungen unterstützt. Es können also Klassen zur Kommunikation verwendet werden. Unterstützt wird das binäre Protokoll MessagePack und das altbekannte Textprotokoll JSON.

Hinzufügen von SignalR zu einer ASP.NET-Core-Applikation

Ab dem .NET Core 3.0 SDK ist ASP.NET Core SignalR bereits enthalten und es muss kein explizites NuGet-Paket installiert werden. Um das zu überprüfen, kann man die *.csproj im Backend-Projekt öffnen und das SDK überprüfen. ASP.NET Core SignalR kommt mit dem Shared Framework Microsoft.AspNetCore.App. Es wird entweder explizit referenziert oder aber implizit, indem das SDK Microsoft.NET.Sdk.Web verwendet wird wie in Listing 1.

Listing 1

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net5.0</TargetFramework> </PropertyGroup> ... </Project>

Um das Backend mit der Real-Time-Funktionalität zu versehen, müssen wir eine Hub-Klasse erstellen, über die die Ko...

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