Liebe Leserinnen, liebe Leser,

wer „Maui“ hört, denkt wahrscheinlich wie auch ich erst einmal an Sonnenschein, Sandstrände und Palmen. Seit einiger Zeit gesellt sich aber eine zweite Assoziation zur zweitgrößten Insel des hawaiianischen Archipels dazu: Die Abkürzung für das .NET Multi-Platform App UI: MAUI. In dieser Ausgabe nehmen unsere Expert:innen Dr. Eva Maria Iwers, Lars Behl und André Krämer Sie mit auf eine Erkundungstour durch das Redmonder .NET MAUI und versuchen zu ergründen, ob sich ein Abstecher dorthin ebenso lohnt wie zum pazifischen Pendant.

Judith Andresen und Sandra Schwedler zeigen in ihrem Beitrag, wie es möglich wird, aus Fehlern wirklich zu lernen, wenn in einem Unternehmen aus einer Fehler- eine Lernkultur wird. Veikko Krypczyk schließt seine Serie zu Blazor-Komponenten ab, indem er einige hilfreiche Drittanbieterkomponenten für das UI-Design vorstellt. Ebenso Matthias Eschhold, der seine Serie zu agiler Produktlinienarchitektur mit Clean Architecture beendet.

Außerdem stellt Tam Hanna Microsofts Initiativen zur verantwortungsvollen Entwicklung und Nutzung von AI vor, Manfred Steyer zeigt, welche Neuerungen Angular 14 im Gepäck hat, und Rebekka Aalbers erzählt uns von ihren Erfahrungen als Frau in der Tech-Branche.

Wir wünschen Ihnen viel Spaß beim Lesen. Vielleicht fördert .NET MAUI jetzt im September ja Assoziationen an den einen oder anderen schönen Sommertag.

Janine Jochum-Frenster, Redakteurin

Wenn sie den Namen Maui hören, sind einige gedanklich wahrscheinlich schon im Urlaub, denn Maui soll die schönste der hawaiianischen Inseln sein. Doch darum geht es in diesem Artikel nicht, sondern um das neue Framework .NET MAUI (Multi-Platform App UI). Bietet auch .NET MAUI traumhaufte Multi-Platform-Entwicklung, die der berühmten Insel würdig ist? Wir zeigen, was .NET MAUI ist, was es kann und berichten über unsere Erfahrungen mit der Nutzung der ersten Vorabversionen des Frameworks.

Entwicklungen für mehrere Betriebssysteme bringen oft eine Vielzahl von Problemen und Herausforderungen mit sich. Dazu gehört unter anderem, dass zu prüfen ist, ob die verwendeten Bibliotheken für alle Systeme verfügbar sind, sowie die Installation diverser Cross-Compiler-Tools, um die Anwendung für alle Systeme auf einem Gerät bauen zu können. Wenn zusätzlich die Anforderung der nativen Veröffentlichung auf mobilen Endgeräten gestellt wird, so wachsen Komplexität und Aufwand oft exponentiell. Es gibt unterschiedliche Möglichkeiten, mit dieser Situation umzugehen:

• Entwicklung einer Anwendung für alle Plattformen (all for one)

• Getrennte Entwicklung von Anwendungen jeweils für Desktop und Mobile

Jede dieser Möglichkeiten hat ihre Vor- und Nachteile. Eine Trennung von Mobile- und Desktopanwendung hat beispielsweise zur Folge, dass die gesamte Codebasis größer ausfällt, da die Anwendungslogik mit hoher Wahrscheinlichkeit nicht zwischen den Plattformen geteilt werden kann. Somit steigen wiederum Wartungsaufwand und Fehleranfälligkeit der Anwendung, da Korrekturen an mehreren Stellen im Code vorgenommen werden müssen.

Auf der anderen Seite hat eine plattformübergreifende Anwendung oftmals den Nachteil, dass die Benutzeroberfläche auf allen Geräten gleich aussieht, da die Nutzung von plattformspezifischen UI-Elementen meist nicht unterstützt wird. Dann integriert sich die Anwendung schlechter in das Ökosystem der jeweiligen Plattform.

Unterstützung von mobilen Betriebssystemen und Desktop mit .NET MAUI

.NET MAUI ist ein neues Open-Source-Framework, das unter der Leitung von Microsoft für die Implementierung von Cross-Plattform-Anwendungen entwickelt wurde. Sowohl die Oberfläche als auch die Logik der Anwendung werden mit XAML und C# beschrieben. Die Besonderheit dabei ist, dass die Oberfläche für alle Plattformen gleichzeitig mit XAML-Dateien beschrieben wird, jedoch je nach Zielplattform die jeweiligen nativen UI-Elemente genutzt werden. Dadurch ergibt sich eine gemeinsame Codebasis für alle Plattformen und trotzdem eine an das System angepasste Nutzererfahrung. Dieses Konzept ist bereits von Xamarin.Forms bekannt, jedoch ist dieses Framework auf mobile Betriebssysteme wie Android oder iOS beschränkt. Mit .NET MAUI werden zusätzlich die Desktopbetriebssysteme Windows und macOS erschlossen. Durch diese Erweiterung der Verfügbarkeit gegenüber Xamarin.Forms kann .NET MAUI als nächste Evolutionsstufe von Xamarin.Forms angesehen werden [1].

Unterschiede zwischen .NET MAUI und Angular

In einem Projekt für den Masterstudiengang Informatik an der Hochschule RheinMain wurde das .NET MAUI Framework untersucht und praktisch eingesetzt. Ziel war ein MAUI-Projekt zur Visualisierung von Daten.

Wer bereits ausgeprägte Erfahrung mit ASP.NET Core hat, fühlt sich mit .NET MAUI direkt zu Hause. Die gewohnten und beliebten Features und Besonderheiten von C# stehen in vollem Umfang zur Verfügung. Dies ist auch einer der größten Vorteile von .NET MAUI: Die Entwicklung von plattformübergreifenden Anwendungen wird für Backend- und Desktopentwickler leichter zugänglich, da sie sich ganz auf die Funktionalitäten des Frameworks konzentrieren können und keine neue Programmiersprache lernen müssen. Wie die letzten Jahre gezeigt haben, ist besonders ASP.NET Core eines der beliebtesten Frameworks für die Entwicklung von Web-Services. C# und das gesamte .NET-Ökosystem werden daher von Programmierbegeisterten auf der ganzen Welt hochgeschätzt [2].

So wie bei Xamarin.Forms wird auch bei .NET MAUI die MVVM-Architektur empfohlen [3]. Es kommt ein komponentenbasierter Stil zum Einsatz, ähnlich wie bei der Angular-Entwicklung, und die in der Ansicht zu visualisierenden Daten werden direkt in der Komponente gehalten. Hier zeigen sich erstmals einige Unterschiede zwischen Angular und .NET MAUI, insbesondere in der Bedienbarkeit und der Menge an benötigtem Boilerplate-Code. Während Angular einen Mechanismus bereitstellt, mit dem alle von einer Datenänderung betroffenen Visualisierungen automatisch neu gerendert werden, müssen bei MAUI diese Änderung und damit das erneute Rendern der Komponenten manuell angestoßen werden.

// HomePage.xaml.cs
namespace TestApp;
public partial class HomePage : ContentPage
{
  private bool _isLoading = true;
  public bool IsLoading
  {
    get =>    this._isLoading;
    set
    {
      this._isLoading = value;
      OnPropertyChanged(nameof(this.IsLoading));
    }
  }
  public HomePage(){ InitializeComponent(); BindingContext = this; }
  // Fetch some data from a service
  […]
}
// HomePage.xaml
// Other visible components
[…]
<ActivityIndicator IsRunning="{Binding IsLoading}" IsVisible="{Binding IsLoading}" />

Listing 1 zeigt den C#-Teil einer einfachen Seite, die in der App angezeigt werden soll. Darauf sollen Daten zu sehen sein, die von einem Web-Service abgerufen wurden. Während der Anfrage an den Server soll ein Spinner oder ein anderer Indikator erscheinen, damit erkennbar ist, dass die Anwendung noch arbeitet und nicht abgestürzt ist. Der Indikator soll nur so lange angezeigt werden, bis die Daten abgerufen wurden; darum verfügt die Seite über die Eigenschaft IsLoading mit einem dazugehörigen Backing Field. Wer schon mit C# gearbeitet hat, weiß, dass Properties eigentlich kein dahinterliegendes Feld benötigen und der Compiler dies automatisch generiert (bekannt als auto-implemented properties). Um jedoch das MAUI Framework über Wertänderungen der IsLoading-Eigenschaft zu informieren, muss die OnPropertyChanged()-Methode aufgerufen werden. Dazu muss der Setter explizit implementiert werden und daher wird ein Backing Field benötigt.

Vergleicht man dies mit dem für Angular benötigten Code (Listing 2), wird deutlich, dass bei .NET MAUI erheblich mehr Boilerplate-Code entsteht.

// main.component.ts
@Component({ selector: 'app-main', templateUrl: './home.component.html', styleUrls: ['./home.component.scss'] })
export class HomeComponent implements OnInit {
  isLoading: boolean = true;
  // Fetch some data from a service
  [...]
}
// main.component.html
// other visible components
[…]
<mat-spinner *ngIf="isLoading"></mat-spinner>

Ein weiteres, viel schwerwiegenderes Beispiel für die Menge an benötigtem Boilerplate-Code ist die Erstellung wiederverwendbarer Komponenten. Oft sollen Komponenten Konfigurationsmöglichkeiten bieten, beispielsweise um zu bestimmen, ob der Inhalt eines Textfelds angezeigt oder (für die Eingabe eines Passworts) verschleiert werden soll. Hierfür werden bei .NET MAUI sogenannte Bindable Properties verwendet. Damit können aus XAML heraus Werte an eine Komponente übergeben werden. Eine solche Bindable Property muss innerhalb der wiederzuverwendenden Komponente deklariert werden (Listing 3).

public static readonly BindableProperty InputIsPasswordProperty =
  BindableProperty.Create(
    propertyName: nameof(InputIsPassword),
    returnType: typeof(bool),
    declaringType: typeof(InputComponent),
    defaultValue: false,
    defaultBindingMode: BindingMode.OneWay,
propertyChanged: InputIsPasswordChanged);

Neben der Bindable Property selbst wird außerdem eine Property InputIsPassword benötigt, die in Listing 3 in Zeile 3 referenziert wird. Sie enthält für die jeweilige Instanz der Komponente den entsprechenden Wert. Je nach Anwendungsfall muss auch hier ein zugehöriges Backing Field angelegt und jede Wertänderung muss durch den Aufruf von OnPropertyChanged(…) propagiert werden. Außerdem wird eine statische Methode benötigt, die Wertänderungen der Bindable Property an die Eigenschaft weitergibt (Listing 3, Zeile 8).

Listing 4 zeigt den Code, der benötigt wird, um einen einfachen Wert von einer Eltern- an eine Kindkomponente zu übergeben.

public bool InputIsPassword { get; set; }
public static void InputIsPasswordChanged(
  BindableObject bindable,
  object oldValue,
  object newValue
)
{
  InputComponent inputComponent = (InputComponent) bindable;
  inputComponent.InputIsPassword = (bool) newValue;
}

Auch hier ist ein Vergleich mit dem äquivalenten Angular-Code interessant:

@Input() inputIsPassword: boolean = false;

Eine einzige Zeile Code bietet bei Angular die gleiche Funktionalität. Hier besteht Entwicklungsbedarf für das .NET-MAUI-Entwicklerteam, ebenso wie intern bei Microsoft, denn Blazor bietet eine ähnlich einfache Möglichkeit, Werte zu übergeben. Natürlich kann nicht ausgeschlossen werden, dass es konzeptionelle oder technische Gründe für die gewählte Umsetzung bei .NET MAUI gibt. Aus Sicht der Anwender:innen erscheinen die erforderlichen Schritte jedoch etwas umständlich.

Fazit

Alles in allem war der erste Eindruck von .NET MAUI aber sehr überzeugend. Für Entwickler:innen mit Erfahrung in Xamarin.Forms, Windows-Desktop-Entwicklung mit C# und XAML-basierten Frameworks oder .NET im Allgemeinen bietet .NET MAUI eine einfache Möglichkeit, Einblicke in die Cross-Platform-Entwicklung zu gewinnen. Wir empfehlen, die Visual Studio IDE mit vollem Funktionsumfang zu verwenden, da sie die beste Entwicklungserfahrung bietet. Die Verwendung anderer Editoren und IDEs ist ebenfalls möglich, aber Visual Studio enthält eine hervorragende Integration des .NET MAUI Workloads.

.NET MAUI sollte ursprünglich mit .NET 6, das im November 2021 veröffentlicht wurde, allgemein verfügbar sein. Doch bereits mit dem am 14.09.2021 erschienenen Post zu .NET MAUI in den Microsoft DevBlogs wurde das Release verschoben. Der neue Termin sollte im zweiten Quartal 2022 liegen [4]. Aufgrund der Erfahrungen mit den Vorschauversionen kann das Verschieben der Veröffentlichung als eine gute Entscheidung angesehen werden, da einige Funktionalitäten noch nicht bzw. noch nicht vollständig implementiert waren. Hingegen konnte von Oktober 2021 bis einschließlich Januar 2022 die stetige Arbeit und Verbesserung des Frameworks mitverfolgt und getestet werden. Dieser Artikel basiert auf dem dritten Release Candidate. Dieser enthielt alle für Version 1.0 geplanten Funktionalitäten und keine schwerwiegenden Fehler mehr, wodurch er für die Entwicklung von Produktionsanwendungen geeignet ist.

Besonders positiv zu erwähnen ist, dass eingereichte Fehlerberichte zum Großteil bearbeitet und viele Fehler behoben wurden. Die verbleibenden Fehler sollen in kommenden Versionen, spätestens aber mit .NET 7, behoben werden. Es bleibt zu hoffen, dass auch die oben genannten Schönheitsfehler in Zukunft Aufmerksamkeit erhalten und .NET MAUI dann noch komfortabler und einfacher zu nutzen sein wird. Betrachten wir unseren anfänglichen Vergleich mit der hawaiianischen Insel, dann ist festzustellen, dass .NET MAUI noch nicht perfekt ist, doch für erfahrene .NET-Entwickler auf jeden Fall eine empfehlenswerte Alternative darstellt.

Links & Literatur

[1] https://github.com/dotnet/maui/blob/969bf6f24ab7ed1ad84557e43cf6242ef52b9366/README.md

[2] https://insights.stackoverflow.com/survey/2021#most-loved-dreaded-and-wanted-webframe-love-dread

[3] https://docs.microsoft.com/en-us/dotnet/maui/xaml

[4] https://devblogs.microsoft.com/dotnet/update-on-dotnet-maui

Maui ist nicht nur eine paradiesische, zu Hawaii gehörende Insel, sondern auch der Kurzname des .NET Multi-Platform App UI, Microsofts neuem Oberflächenframework zur Cross-Platt-Entwicklung. Nach mehrjähriger Entwicklung hat Microsoft den Xamarin.Forms-Nachfolger im Mai 2022 final veröffentlicht. Es ist also an der Zeit, sich einen Überblick zu verschaffen und einen Vergleich zum Vorgänger zu ziehen.

.NET MAUI erschien während der Build-Konferenz im Mai 2022 als verspäteter Bestandteil von NET 6. Das Framework ersetzt das 2016 von Microsoft zugekaufte Produkt Xamarin.Forms und erlaubt es, Anwendungen für Android, iOS, macOS und den Windows Desktop auf der Basis von C# und dem .NET Framework unter Zuhilfenahme eines plattformübergreifenden UI-Frameworks zu entwickeln (Abb. 1). .NET-MAUI-Apps greifen dabei unabhängig von der Zielplattform auf die gemeinsame .NET 6 Base Class Library (BCL) zu (Abb. 2).

Abb. 1: .NET MAUI ist Teil von .NET 6; die Zielplattformen sind Android, iOS, macOS und Android

Die BCL abstrahiert an vielen Stellen bereits Unterschiede der zugrunde liegenden mobilen Betriebssysteme weg und liefert dem Entwickler somit ein einheitliches Programmiermodell.

Abb. 2: .NET MAUI nutzt eine einheitliche BCL, aber unterschiedliche Laufzeitumgebungen

Die unter Xamarin.Forms verwendete Mono Class Library kommt unter MAUI nicht mehr zum Einsatz. Trotzdem steckt auch in MAUI noch ein Stückchen Mono. So kommt für Android, iOS und macOS weiterhin die Mono-Laufzeitumgebung (Mono Runtime) zum Einsatz. Für Windows Apps ist es Win32.

Keine Revolution, sondern eine Evolution

Microsoft beschreibt .NET MAUI als Evolution von Xamarin.Forms, erweitert von mobilen auf Desktopszenarien, mit von Grund auf für Performance und Erweiterbarkeit neuntwickelten Oberflächenelementen.

Mit .NET MAUI liefern die Redmonder also ein Framework, das sich nicht mehr nur auf die mobilen Betriebssysteme Android und iOS konzentriert, sondern auch einen Fokus auf die Desktopbetriebssysteme macOS und Windows legt. Letzteres wurde zwar in der Form von UWP-Apps auch bereits von Xamarin.Forms unterstützt, hinkte im Funktionsumfang jedoch an einigen Stellen hinter den beiden mobilen Betriebssystemen her. Unter .NET MAUI ist die Basis für Windows-Apps nun auch nicht mehr die UWP, sondern WinUI 3, das Oberflächenframework des Windows-App-SDK. Unter macOS kommt Mac Catalyst zu Einsatz. Dabei handelt es sich um eine Technologie von Apple, mit der Apps für das iPad für den Mac neu kompiliert werden können.

Das Vordringen auf den Desktop ist, wie bereits erwähnt, nicht die einzige große Neuerung. Sämtliche Steuerelemente wurden von Grund auf neu entwickelt. Sie sind zwar größtenteils API-kompatibel zu den bestehenden Xamarin.Forms-Pendants, implementieren jedoch einen leichtgewichtigeren, auf Schnittstellen basierenden Architekturansatz, der nicht nur eine bessere Performance bringt, sondern auch Erweiterungen über das neue Handler-Prinzip leichter ermöglicht.

Neben diesen beiden Änderungen, die primär unter der Haube stattfanden, gibt es auch einige Änderungen, die den Einstieg in die Cross-Platform-Entwicklung einfacher und die Arbeit produktiver machen.

Weniger ist mehr

Ein erster Fallstrick bei der Entwicklung mit Xamarin. Forms war stets die unerwartete Projektvielfalt. So gab es ein Projekt für den plattformübergreifend geteilten Quellcode und ein Projekt je Zielplattform. Typische Xamarin.Forms-Projektmappen bestanden also aus vier oder mehr Projekten (Abb. 3). In der Praxis war das eine unnötige Einstiegshürde, denn gerade Anfänger in der plattformübergreifenden Entwicklung verloren häufig den Überblick darüber, welcher Code in welches Projekt kommt.

Abb. 3: Die Projektstruktur einer Xamarin.Forms-App umfasst immer mehrere Projekte

Mit .NET MAUI hat Microsoft die Anzahl der benötigten Projekte – „weniger ist mehr“ – auf eins reduziert. Diese Änderung (Abb. 4) reduziert die Komplexität und erhöht gleichzeitig die Einsteigerfreundlichkeit.

Abb. 4: .NET MAUI benötigt nur noch ein Projekt

Die Reduzierung auf ein einziges Projekt bedeutet übrigens nicht, dass Sie keinen plattformspezifischen Quellcode mehr in .NET-MAUI-Apps entwickelt können. Dieser hat nach wie vor seine Daseinsberechtigung, allerdings müssen Sie ihn nicht mehr in einem separaten Projekt ablegen, sondern Sie speichern ihn in einem Unterordner des Ordners Platforms. Wie Sie in Abbildung 3 sehen, legt Visual Studio beim Erstellen einer neuen .NET-MAUI-App bereits Unterordner für Android, iOS, Mac Catalyst, Tizen und Windows an. Tizen ist ein auf Linux basierendes Betriebssystem, das unter anderem auf Smart TVs der Firma Samsung zum Einsatz kommt. In jedem der fünf Unterordner des Ordners Platforms befinden sich plattformspezifischer Quellcode und plattformspezifische Einstellungen (Abb. 5). Beides ist erforderlich, da sich einige Dinge, wie zum Beispiel angeforderte Berechtigungen oder Einstellungen zur Paketierung der App für den Store, auf den verschiedenen Plattformen stark unterscheiden und somit nicht allgemeingültig angegeben werden können.

Abb. 5: Plattformspezifischer Quellcode befindet sich in speziellen Unterordnern

Bilder, Schriftarten und Splash Screens

Die Entwicklung von Splash Screens gehörte genauso wie die Verwendung plattformspezifischer Bilder oder App-Icons zu den aufwendigeren Tätigkeiten bei der Entwicklung von Xamarin.Forms-Apps. Splash Screens mussten individuell je Betriebssystem umgesetzt werden, Bilder mehrfach je Zielplattform, Auflösung und Pixeldichte der potenziellen Endgeräte abgespeichert werden. Gleiches galt für App-Icons. Auch das Einbinden benutzerdefinierter Schriftarten stellte sich als umständlicher heraus als vermutet.

Unter .NET MAUI reduziert sich der notwendige Aufwand beträchtlich. App-Icons, Bilder und Splash Screens werden hier einmalig, idealerweise als Vektorgrafik, in den Unterordnern AppIcon, Images oder Splash des Ordners Resources des Projekts abgelegt (Abb. 4). Neben dem SVG-Format, also einem vektorbasierten Format, werden auch Rastergrafikformate wie PNG-Dateien von .NET MAUI unterstützt. Der Vorteil der Vektorgrafiken gegenüber den Rastergrafiken liegt jedoch darin, dass .NET MAUI beim Kompilieren automatisch alle benötigten Größen der Grafik für die einzelnen Zielplattformen erzeugt, sodass man sich als Entwickler nicht mehr darum kümmern muss. Die Magie der zuvor genannten Ordner basiert auf einer automatischen Zuweisung des Build-Vorgangs in den Projekteigenschaften (Abb. 6).

Abb. 6: Dateien in den Ordnern AppIcon, Fonts, Images, Raw und Splash erhalten automatisch einen zum Ordner passenden Build-Vorgang

Die Konvention für die Zuweisung des Build-Vorgangs zum Unterordner ist unter .NET MAUI übrigens nicht fest einprogrammiert worden. Stattdessen wird sie über die CSPROJ-Projektdatei konfiguriert. Listing 1 zeigt einen Ausschnitt einer .NET-MAUI-Projektdatei, wie sie von der Visual-Studio-Projektvorlage generiert wurde, der Sie die Standardkonventionen entnehmen können.

<ItemGroup>
  <!-- App Icon -->
  <MauiIcon Include="Resources\AppIcon\appicon.svg" ForegroundFile="Resources\AppIcon\appiconfg.svg" Color="#512BD4" />
 
  <!-- Splash Screen -->
  <MauiSplashScreen Include="Resources\Splash\splash.svg" Color="#512BD4" BaseSize="128,128" />
 
  <!-- Images -->
  <MauiImage Include="Resources\Images\*" />
  <MauiImage Update=»Resources\Images\dotnet_bot.svg» BaseSize=»168,208» />
 
  <!-- Custom Fonts -->
  <MauiFont Include="Resources\Fonts\*" />
 
  <!-- Raw Assets (also remove the "Resources\Raw" prefix) -->
  <MauiAsset Include="Resources\Raw\**" LogicalName="%(RecursiveDir)%(Filename)%(Extension)" />
</ItemGroup>

Neben der einfacheren Handhabung von App-Icons, Bildern und Splash Screens erleichtert .NET MAUI auch den Umgang mit benutzerdefinierten Schriftarten. Um eine solche zu nutzen, sind zwei Schritte erforderlich. Die Schriftart muss als TTF- oder OTF-Datei im Ordner Resources\Fonts abgelegt und in der Datei MauiProgram registriert werden.

Die Klasse MauiProgram, deren Quellcode Sie in Listing 2 sehen, nutzt den aus ASP.NET Core bekannten Generic-Host-Ansatz zum Bootstrapping der Anwendung. Das umfasst Dinge wie die Konfiguration des Loggings und der Dependency Injection sowie die Registrierung benutzerdefinierter Schriftarten.

public static class MauiProgram
{
  public static MauiApp CreateMauiApp()
  {
    var builder = MauiApp.CreateBuilder();
    builder
      .UseMauiApp<App>()
      .ConfigureFonts(fonts =>
      {
        fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
        fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
      });
 
    return builder.Build();
  }
}

Raus aus den Abhängigkeiten

Unter Xamarin.Forms wurden sogenannte Renderer-Klassen je Plattform genutzt, die zur Laufzeit über Reflection erzeugt wurden, um aus den abstrakt beschriebenen plattformübergreifenden Oberflächenelementen plattformspezifische, native Steuerelemente zu erzeugen, die schlussendlich die Oberfläche zeichneten. Je Plattform und Steuerelement gab es einen Renderer, der eine fixe Abhängigkeit zum plattformübergreifenden Steuerelement hatte. Diese Architektur war durch den Einsatz von Reflection nicht nur langsamer als nötig, sondern durch die fixe Abhängigkeit zum plattformübergreifenden Steuerelement auch unflexibel.

Unter .NET MAUI wurden nicht nur alle Steuerelemente neu implementiert, unter der Haube wurde auch die Architektur verändert. Für jedes plattformübergreifende Steuerelement, auch View genannt, gibt es unter .NET MAUI ein Interface. Diese Interfaces werden durch sogenannte Virtual Views im plattformübergreifenden Quellcode implementiert. Plattformspezifisch beinhalten die .NET-MAUI-Bibliotheken je Zielplattform sogenannte Handler. Diese werden mit der .NET-MAUI-Dependency-Injection zu den passenden Schnittstellen registriert. Durch diese Vorgehensweise wird keine Reflection mehr benötigt, um zur Laufzeit den passenden Handler zu einem Steuerelement zu erzeugen. Somit sind Handler nicht nur performanter als Renderer, sondern durch eine potenziell mögliche Neuregistrierung eines eigenen Handlers an der Depency Injection sind sie außerdem auch flexibler; Abbildung 7 verdeutlicht das Konstrukt.

Abb. 7: Handler sind für die plattformspezifische Darstellung von Oberflächenelementen zuständig

Weitere Neuigkeiten

Neben den beiden bereits angesprochenen Änderungen zu Xamarin.Forms, der vereinheitlichten BCL, dem neuen Single-Project-Ansatz oder dem Handler-Konzept gibt es noch eine Vielzahl weiterer Neuerungen. Eine der offensichtlichen ist der Umzug der Namespaces von Xamarin.Forms.* zu .Microsoft.Maui.*. Außerdem ist die Bibliothek Xamarin.Essentials nun vollständig in .NET MAUI aufgegangen. Die ehemaligen Essentials-Klassen, deren Aufgabe es ist, plattformspezifische Funktionen plattformübergreifend nutzbar zu machen, also zum Beispiel eine einheitliche Schnittstelle zum Aufnehmen von Bildern auf dem Endgerät bereitzustellen, finden sich unter .NET MAUI unter diversen neuen Namespaces, unter anderem Microsoft.Maui.Devices, oder Microsoft.Maui.Media.

Etwas unauffälliger als die beiden vorherigen Änderungen ist die Installation und Aktualisierung von .NET MAUI im Projekt. Xamarin.Forms war ein NuGet-Paket und konnte somit über den NuGet-Paketmanager installiert und aktualisiert werden. Es lag dabei stets in der Hand des Entwicklers, ob er sein Projekt auf eine neue Xamarin.Forms-Version aktualisieren wollte oder nicht. Unter .NET MAUI ist das anders. .NET MAUI ist Teil von .NET und wird gemeinsam mit .NET über Visual Studio aktualisiert. Als Entwickler steht es mir nun also nicht mehr frei, .NET MAUI unabhängig von der .NET-Version in meinem Projekt zu aktualisieren.

Neben diesen eher organisatorischen Änderungen gibt es auch optische Neuerungen in der Form neuer Steuerelemente. Diese umfassen sowohl kleinere Neuerungen wie die spezialisierten Stacklayout-Elemente VerticalStacklayout und HorizontalStacklayout zur vertikalen oder horizontalen Ausrichtungen von Elementen als auch größere Neuerungen wie die neuen Grafikfunktionen aus Microsoft.Maui.Graphics. Zu den größeren Neuerungen gehören auch die Klasse Shadow zum Zeichnen von Schatten und das neue Border-Element, ein Containersteuerelement zum Zeichnen von Rahmen um andere Elemente herum.

Den eigenen Rechner fit für MAUI machen

Wenn Sie nun auf den Geschmack gekommen sind und selbst auch Apps mit .NET MAUI entwickeln möchten, dann benötigen Sie dazu Visual Studio 2022 in der Version 17.3 oder höher. Zum Zeitpunkt des Schreibens des Artikels handelt es sich dabei noch um ein Preview-Version. Laut der offiziellen .NET-MAUI-Roadmap soll die Version 17.3 im August offiziell veröffentlicht werden, sodass ab dann keine Vorschauversion mehr vonnöten ist.

Unabhängig davon, ob Sie die Version 17.3 noch als Preview- oder bereits als aktuelle Version installieren, müssen Sie im Visual-Studio-Installationsprogramm die Workload .NET Multi-Platform App UI-Entwicklung auswählen (Abb. 8). Anschließend ist Ihr System startklar und Sie können über die Projektvorlage .NET MAUI-App Ihre erste .NET-MAUI-App erstellen.

Abb. 8: Im Visual Studio Installer muss die Workload „Multi-Platform App UI-Entwicklung“ ausgewählt werden, um das eigene System für .NET MAU vorzubereiten

Die offizielle Dokumentation [1] gibt Ihnen bei Ihren ersten Gehversuchen die notwendige Starthilfe. Weitere Unterstützung liefern Microsofts Codebeispiele [2].

Fazit

Mit .NET MAUI macht Microsoft vieles richtig. Mit dem neuen Namen setzt Microsoft ein klares Signal, dass Xamarin.Forms von nun an ein integraler Bestandteil des .NET Frameworks ist und kein nebenher laufendes, zugekauftes Projekt.

Die vielen kleinen und großen Änderungen wie zum Beispiel der Single-Project-Ansatz und die einheitliche BCL erleichtern neuen Entwicklern den Einstieg in die plattformübergreifende Entwicklung.

Trotz aller Änderungen bleibt vieles, was unter Xamarin.Forms gut funktioniert, auch weiterhin erhalten. Dadurch kann nicht nur bestehendes Wissen weiter genutzt werden, sondern auch ein Großteil des Quellcodes bestehender Xamarin.Forms-Apps. Laut Microsoft soll sich dieser in Zukunft über den .NET-Upgrade-Assistenten zu einem großen Teil automatisch migrieren lassen, sodass der manuelle Aufwand nicht so hoch ausfallen sollte.

Zum aktuellen Zeitpunkt kann .NET MAUI mit gutem Gewissen bei der Entwicklung neuer Apps genutzt werden. Wer bestehende Xamarin.Forms-Apps migrieren möchte, sollte sich zuvor einen Überblick verschaffen, ob alle verwendeten Open-Source-Bibliotheken bereits migriert wurden. Zum aktuellen Zeitpunkt ist das Bild hier noch sehr gemischt. Einige populäre Bibliotheken wurden bereits portiert, bei einigen gibt es Betaversionen, bei wiederum anderen gibt es keine Pläne seitens der Entwickler, die Bibliothek zu migrieren.

Links & Literatur

[1] https://docs.microsoft.com/dotnet/maui

[2] https://docs.microsoft.com/de-de/samples/browse/?expanded=dotnet&products=dotnet-maui

Wir zeigen, wie Teams und Organisationen schrittweise der Wechsel zum agilen Arbeiten gelingen kann.

Worte prägen unser Denken und Handeln. Gleichzeitig arbeitet unser Gehirn manchmal anders als erwartet. So behalten wir bei einer Verneinung das Verb häufig ohne das vorangestellte „nicht“ im Kopf: „Nicht vom Beckenrand springen“ erzeugt in unserem Hirn eine starke Verbindung von „Beckenrand“ und „springen“ – und womöglich sogar den Wunsch, einfach mal vom Beckenrand zu springen. Mit dem Wort „Fehlerkultur“ verhält es sich ähnlich. Es bleibt die Kombination von „Fehler“ und „Kultur“ in unserem Hirn. Das beeinflusst womöglich unser Denken, Handeln und Fühlen. Wenn wir hingegen über eine Lernkultur sprechen, stellen wir das Lernen in den Vordergrund. Wie aber können Teams und Organisationen aus einer Fehlerkultur in eine Lernkultur wechseln?

Beklagen Menschen die Fehlerkultur in ihrer Organisation, vermissen sie häufig eine Verantwortungsübernahme für entstandene Ergebnisse. In einer Fehlerkultur werden die Begriffe „Fehler“ und „Schuld“ nahezu synonym genutzt. Weil in einer Fehlerkultur mit der Verantwortung für einen Fehler auch die Schuld daran verbunden ist, wehren viele Beteiligte die Verantwortung ganz ab und suchen nach (anderen) Schuldigen für den passierten Fehler. Zum Schuldgefühl gesellen sich außerdem schnell Scham oder Ärger. Weil der oder die Einzelne diese Gefühle vermeiden möchte, sucht er oder sie einen alternativen Weg. Um schlechte Gefühle (oder auch ein schlechtes Gewissen) über den Fehler abzuwehren, lehnen die Beteiligten jegliche Verantwortung für den Fehler ab. Und das in gewisser Weise wohl zu Recht: Sich schuldig fühlen zu müssen sowie Scham oder Ärger zu empfinden, ist anstrengend. Die Beteiligten sorgen also für sich selbst, wenn sie die Verantwortung für den Fehler und damit das Schuldgefühl abwehren.

Es gibt mehrere effektive Strategien zur Abwehr der Verantwortung eines Fehlers:

• Die Beteiligten suchen nach Menschen, die etwas (nicht) hätten tun müssen (Othering). Die Schuldzuweisung wird dabei häufig entpersonalisiert vorgetragen: „Wenn Abteilung XYZ das vernünftig machen würde, hätten wir das Problem gar nicht.“
• Die Beteiligten negieren den Fehler: „Naja, so falsch war das ja gar nicht. Am Ende haben doch alle das bekommen, was sie wollten.“
• Die Beteiligten reden den Fehler klein: „Das ist schon okay so. Mehr geht hier halt nicht. Und das war schon immer so.“

Alle genannten Strategien führen dazu, dass der eigentliche Fehler nicht als solcher erkannt wird. Schlimmer noch: Sie führen die Beteiligten in einen Teufelskreis, in dem sie um die gemachten Fehler kreisen, diese aber nicht beheben (Abb. 1).

Abb. 1: In einer Fehlerkultur kreisen die Beteiligten um die Fehler

Wenn ein Fehler einer Person oder einem Personenkreis zugeschrieben wird, wird an diese die Schuld delegiert. Die Betroffenen wiederum fühlen sich dementsprechend schlecht, ärgern sich und versuchen ihrerseits, die schlechten Gefühle (auch Wut) abzuwehren oder weiterzugeben. Auch sie übernehmen also keine Verantwortung für den Fehler. Damit bleibt der Fehler unbehandelt. Zu keinem Zeitpunkt hat eine:r der Beteiligten darüber nachgedacht, was genau passiert ist und welche Veränderungen sinnvoll wären. Im Ergebnis hat die Organisation nichts gelernt. Der Fehler kann wiederholt werden. Damit beginnt der Teufelskreis von vorn.

Agile Methoden: Lernen, Erkenntnisse zu gewinnen und anders zu handeln

In einer Lernkultur hingegen übernehmen alle Beteiligten Verantwortung für den Fehler – und vor allem für eine positive Veränderung. Während in einer Fehlerkultur die Beteiligten die Verantwortung und die damit einhergehenden schlechten Gefühle abwehren, führt in einer Lernkultur die gemeinsame Verantwortung in der Situation eines Fehlers zu einer lösungsorientierten Ausrichtung.

Dabei haben die Beteiligten unterschiedliche Strategien, mit einem Fehler umzugehen. Denn auch in einer Lernkultur ist ein Fehler ein Fehler. In den wenigsten Fällen wird es gelingen, dass Fehler direkt begrüßt werden. Und so antworten die einen auf einen Fehler mit Humor, während andere diesem analytisch begegnen. All diese Strategien haben gemeinsam, dass der Fehler als solcher bezeichnet wird. Wir können nur aus Fehlern lernen, wenn wir sie auch als Fehler anerkennen. Darin liegt der große Unterschied zwischen einer Fehler- und einer Lernkultur. Die Beteiligten gehen davon aus, dass Fehler passieren werden, sind gewillt, diese als solche zu benennen und mit den Erkenntnissen rund um den Fehler eine neue Handlungsweise auszuprobieren. Es geht nicht darum, wer genau daran schuld ist. Damit richtet sich die Energie der Organisation auf Veränderung und Lernen. So werden Räume frei und eine stetige Entwicklung möglich. Kern einer Lernkultur sind das gemeinsame Arbeiten und die gemeinsame Verantwortungsübernahme für dieses Arbeiten.

Abb. 2: In einer Lernkultur ist ein Fehler Ausgangspunkt einer positiven Entwicklung

In einer agilen Kultur Lernen ermöglichen

Je nachdem, ob ein Team oder eine Organisation mehr um gemachte Fehler kreist oder Fehler zum Ausgangspunkt von Entwicklung macht, wird das Teamverhalten durch den Begriff „Fehler-“ oder „Lernkultur“ beschrieben. Kultur zeigt sich in Handlungen. So beschreiben Bright und Parkin [1] Organisationskultur mit den Worten: „This is how we do things around here.“ („So machen wir das hier.“) Es ist also nicht entscheidend, wie Menschen in Teams oder Organisationen handeln möchten, sondern es ist kulturbestimmend, wie die Beteiligten faktisch handeln.

Wenn Teams und Organisationen ihre Fehlerkultur verlassen möchten und eine Lernkultur leben möchten, stellt sich also die zentrale Frage: „Was tun wir im Team oder in der Organisation zukünftig anders?“ Dabei zählen die kleinen Dinge, die täglichen Handlungen aller Beteiligten, die sich zu einer Fehler- oder einer Lernkultur aufsummieren. Jede veränderte Handlung, jedes andere Vorgehen, jede noch so kleine neue Antwort auf einen Fehler könnte ein Schritt in die Lernkultur sein. Fehler schnell ausbügeln zu können, Folge- und Wiederholungsfehler zu vermeiden, neue Wege im Sinne des Kundennutzens gehen zu können, sollte im Sinne aller Teams und Organisationen sein. Dennoch verharren viele Teams und Organisationen in ihrer Fehlerkultur. Denn es braucht den oder die Einzelne:n, der oder die sein beziehungsweise ihr Verhalten ändert, damit sich in Summe eine neue Lernkultur zeigen kann. Und das eigene Verhalten zu ändern, ist häufig nicht einfach. Führungskräfte können das gewünschte Verhalten vorleben und verfügen damit über einen riesigen Hebel zur Veränderung.

Jedes Handeln hat seinen Sinn: Auch wenn Schuldzuweisungen und Verleugnung von Fehlern in Teams und Organisationen für Wachstum und bessere Qualität nicht förderlich sein mögen, war es für die Einzelnen irgendwann in ihren Leben einmal sinnvoll, genau so zu handeln. Es kann sich im Elternhaus, im Kindergarten, in der Schule, während der Ausbildung, im Freund:innenkreis oder in einem anderen Unternehmen als hilfreich erwiesen haben. Unbewusst wiederholen wir Verhalten, das für in anderen Situationen erfolgreich und damit sinnvoll war. Das ist uns in der jeweiligen Situation meist nicht bewusst, sondern wir handeln unwillkürlich nach unseren alten Verhaltensmustern.

Agiles Arbeiten: Das Ziel ausrufen und sich Schritt für Schritt diesem nähern

Edgar Schein spricht im Kulturebenen-Modell [3] davon, dass Grundannahmen von Einzelnen die Organisationskultur bestimmen. Um von einer Fehler- in eine Lernkultur zu wechseln, werden alle ihr Verhalten ändern (müssen). Und dabei werden sich Grundannahmen ändern. Der Umgang mit Fehlern ist tief in allen verankert. Jeder Mensch hat seine Geschichte, Erfahrungen und Muster. Eine solche Veränderung gelingt nicht durch das Aufhängen eines Leitbilds im Treppenhaus oder durch eine einzelne Fuckup-Nacht. Eine solche Veränderung braucht eine große Ausrichtung des Teams oder der Organisation – und viele kleine Schritte dorthin. Eine solche Veränderung braucht Kaikaku [2]: Wenn Teams und Organisationen gewohnt sind, Kaizen zu betreiben, also die iterative Verbesserung ihrer Prozesse und Produkte, dann wird es ihnen auch gelingen, eine Veränderung mit Kaikaku herbeizuführen. Echte Veränderung entsteht nämlich Schritt für Schritt.

Ins Lernen kommen

Im Fall von Kaikaku geht der schrittweisen Veränderung „der große Ausruf“ voraus. Im Fall einer Lernkultur könnten das Aussagen sein wie:

• „Wir machen Fehler. Aber keinen ein zweites Mal.“
• „Win or learn.“
• „Wir lernen aus jedem Schritt für den nächsten Schritt.“

Es ist charakteristisch für Kaikaku, dass eine kleinere Gruppe für die anderen das Zielbild „vordenkt“ und es verkündet. In einem Team werden darüber alle Beteiligten verhandeln können, in einer größeren Organisation übernimmt diese Aufgabe ein Transition-Team. Echte Veränderung gelingt am besten mit jenen, die Lust auf eine Veränderung haben. Das Transition-Team wirbt für die Veränderung und lebt diese radikal vor. Kulturveränderungen gelingen dann, wenn die Vorbilder in der Organisation die Veränderung vorleben. Das bedeutet, dass die Alphastimmen in ihrem jeweiligen Umfeld beginnen, ihr Verhalten zu verändern. Dabei werden sie ihre ersten Schritte auf unterschiedliche Weise gehen:

• Sie entscheiden sich, bei jedem erkannten Fehler offensiv nach der Erkenntnis aus dem Fehler und dem nächsten Schritt zu suchen: „Kannst du mich unterstützen? Was ist unser nächster Schritt? Ich brauche deinen Rat und deine Tat: Was tun wir als Nächstes?“
• Die Beteiligten konzentrieren sich auf das Offenlegen der implizit verhandelten Schuld: „Mir geht es nicht gut mit dem Fehler. Ich habe das Gefühl, daran schuld zu sein. Ich versuche daher, die Schuld nicht anzunehmen, und nehme die Situation, so wie sie ist. Was lernen wir aus dem letzten Schritt? Was machen wir jetzt anders?“
• Sie legen „Othering“ offen und suchen nach lokalen Lösungen: „Die Abteilung XYZ schuldig zu erklären, wird in der Folge nichts an unseren Ergebnissen ändern. Wir würden so im Fehler verharren. Also machen wir es anders. Wie müssen wir anders handeln, um ein anderes Ergebnis zu erzielen?“
• Sie sprechen gezielt über eigene Fehler und Fehlentscheidungen und erzählen, wie sie sich daraus gelöst haben – und welche (Lern-)Erfolge sie dabei erzielt haben.

Mit dieser angesagten Verhaltensänderung („Wir möchten uns immer weiterentwickeln und zu jedem Zeitpunkt besser werden!“) und vorgelebtem Verhalten wird die Bereitschaft größer, dass alle Organisationsmitglieder ihr Verhalten ändern können. Denn sie sehen Alternativen zu ihren bisherigen Grundannahmen. Sie machen neue Erfahrungen. Diese Erfahrungen können Teams und Organisationen durch Rituale und Maßnahmen unterstützen:

• Alle Organisationsmitglieder überprüfen in Retrospektiven regelmäßig ihr Verhalten. Die Moderationskräfte achten darauf, dass wirkliches Lernen stattfindet und die Teammitglieder nicht in ihr altes Verhalten zurückfallen (zum Beispiel in Schuldzuweisungen).
• Bei Fehlern größerer Natur werden Post-Mortem-Analysen durchgeführt. Die Moderation sorgt für eine vorwurfsfreie Analyse der jeweiligen Fehler und klare Beschlussfassung über die nächsten Schritte.
• In einer Fuckup-Nacht berichten Freiwillige über ihren größten Fehler – und was sie daraus gelernt haben.
• Alle Organisationsmitglieder trainieren ihre Fähigkeit, Feedback zu geben und anzunehmen, und üben diese in einem Feedback-Karussell [4].
• Das Transition-Team wird die jeweilige Entwicklung beobachten und aus dem jeweiligen Stand lernen und die nächsten Schritte ableiten. So funktioniert eine große Veränderung in einem Team oder einer Organisation: Mit einem klaren Blick auf den formulierten Zielraum nähern sich die Beteiligten diesem Schritt für Schritt.

Agile Methoden: Wir können nur aus Fehlern lernen, die wir als solche anerkennen

Eine besondere Funktion haben in dieser Veränderung alle jene Menschen, die für andere Menschen in Führung gehen. Sowohl die lateralen als auch die disziplinarischen Führungskräfte sind gefordert: sowohl, was das Vorleben im Umgang mit Fehlern betrifft als auch das Spiegeln des Umgangs mit Fehlern. Sie spiegeln den eigenen Umgang mit Fehlern und den anderer Menschen in ihrem Umfeld, indem sie annehmbares Feedback geben. Sie unterstützen diejenigen, die vorwurfsfrei aus einem Fehler lernen möchten.

Solche Unterstützung kann sich ausdrücken in einer Selbstkundgabe kombiniert mit leitenden Fragen, zum Beispiel: „Wenn ich so auf den Sachstand schaue, fühle ich sofort Schuld in mir wachsen und ich möchte mit dem Finger auf andere Menschen zeigen. Das würde mich von meiner Schuld entlasten. Aber das würde dazu führen, dass ich mich mit der Schuld und der Fehlerverweigerung beschäftige. Daher versuche ich, die Schuld nicht anzunehmen. Ich habe die mögliche Schuld zur Kenntnis genommen. Ich lege sie nun zur Seite. Und jetzt versuche ich, mit dem Sachstand anders umzugehen. Ohne Wertung, ohne Beurteilung, ohne Schuld. Wir können nur aus Fehlern lernen, wenn wir sie so nehmen, wie sie sind. Daher habe ich drei Fragen:

1. Was ist faktisch passiert?
2. Welche Schlüsse ziehen wir daraus?
3. Was machen wir ab jetzt anders?“

Alle Beteiligten werden durch ein verändertes Verhalten neue Ergebnisse erhalten. Den eigenen Grundannahmen stehen dann neue Erfahrungen gegenüber. Nach und nach werden die Organisationsmitglieder häufiger und klarer anders mit Fehlern umgehen als bisher. Und so wird die Summe veränderter Handlungen eine Fehlerkultur in eine Lernkultur verwandeln.

Links & Literature

[1] https://de.wikipedia.org/wiki/Organisationskultur#Grundlagen

[2] http://www.wandelweb.de/blog/?p=53

[3] https://de.wikipedia.org/wiki/Kulturebenen-Modell

[4] https://www.bug-nrw.de/arbeitsfelder/unterrichtsentwicklung/praxis/grundlegendes/methoden-von-a-z/karussell-diskussion-kugellager