Windows, iOS und Android in einem Rutsch

MVVM-Frameworks für die Cross-Plattform-Entwicklung im Vergleich
Kommentare

Durch Xamarin für iOS und Android können .NET-Entwickler schon seit längerer Zeit die „feindlichen“ Betriebssysteme erobern. Dabei möchte man auf den Luxus einer soliden Architektur natürlich nicht verzichten. Aber mithilfe des Model-View-ViewModel-Patterns (MVVM-Pattern) sollen nicht nur die üblichen Architekturprobleme angegangen werden. Bei der Entwicklung für unterschiedliche Plattformen kommt es vor allem darauf an, den plattformspezifischen Codeanteil zu reduzieren. Der folgende Artikel vergleicht mit MvvmCross und Crosslight zwei Frameworks, die sich dieser Aufgabe stellen.

Bindings, Commands, Inversion of Control: Das sind die Schlagworte, die Softwareentwicklern zum Thema MVVM auf Anhieb einfallen. Genau diese Mechanismen haben das Model-View-ViewModel-Pattern bekannt und beliebt gemacht, auch über die Grenzen des .NET-Universums hinaus. Mithilfe von Bindings lassen sich Änderungen im ViewModel direkt an die Benutzeroberfläche (View) weitergeben. Commands sorgen für die Weitergabe der Benutzerinteraktion an die ViewModels. Mithilfe von Inversion of Control lassen sich die Komponenten miteinander verheiraten und können über Messages miteinander kommunizieren. Das sind die Grundlagen für jedes MVVM-Framework. An diese Verhaltensmuster sind auch die beiden hier vorgestellten Frameworks gebunden. Doch lassen sich diese auch auf die unterschiedlichen Plattformen übertragen? Um es gleich vorweg zu nehmen: Ja, es funktioniert. Aber beide Frameworks müssen hier echte Pionierarbeit leisten.

Ausgangslage: MVVM-Frameworks

Obwohl sich beide Frameworks mit MVVM befassen, könnte die Ausganssituation bei beiden nicht unterschiedlicher sein. Denn sie basiert auf einer der elementarsten Fragen der Softwareentwicklung: Open-Source-Software oder kommerzielle Software. Bei MvvmCross handelt es sich um ein Open-Source-Projekt von Stuart Lodge, der das Projekt regelmäßig weiterentwickelt. Ein Wiki, Beispiele und Ausblicke in die Zukunft sind vorhanden. Xamarin nutzt das Projekt auch regelmäßig für Beispiele. Dies und die obligatorischen Einträge auf Stack Overflow machen den Einstieg in Cross-Plattform-Entwicklung so angenehm wie möglich. Crosslight hingegen wird von Intersoft Solutions entwickelt. Das Unternehmen ist offizieller Partner von Xamarin. Bezüglich der Kosten: Eine Lizenz schlägt mit 999 US-Dollar zu Buche. Dafür erhält der Lizenznehmer zusätzlich zum Framework garantierte Releases, viele dokumentierte Beispiele und garantierten Support. Weiterhin gibt es Tutorials zu neuen Features und die Möglichkeit, alles per Testversion auszuprobieren. Es ließe sich das Für und Wider der beiden Ausganslagen abwägen, aber das würde an dieser Stelle den Rahmen sprengen. Außerdem ist es noch zu früh im Artikel, um ein endgültiges Urteil zu fällen. Für den Moment lautet das Urteil unentschieden.

Aufbau

Da Xamarins Cross-Plattform-Lösung beiden Frameworks als Grundlage dient, überrascht es nicht, dass beim grundlegenden Aufbau der Projekte die Unterschiede eher gering ausfallen. Das gilt bei der Entwicklung in Visual Studio, aber auch in der von Xamarin selbst zur Verfügung gestellten IDE mit dem Namen Xamarin Studio.

Das Herzstück einer Visual Studio Solution stellt immer ein Portable-Class-Library-Projekt dar. Dieses Projekt enthält üblicherweise die benötigten ViewModels und Models. Ziel ist es, die gesamte Logik in eben diesem oder mehreren Portable-Class-Library-Projekten abzubilden. Für jedes Betriebssystem kommt jeweils ein Plattformprojekt hinzu. Hier sind in erster Linie die Views zu finden. Diese müssen für jede Plattform separat erstellt und gestaltet werden. Hierbei lässt sich auch auf unterschiedliche Auflösungen und Formfaktoren wie Smartphone oder Tablet eingehen (Abb. 1). Da beide exakt denselben Weg gehen, bleibt eine Überraschung an dieser Stelle aus: unentschieden.

Abb. 1: Aufbau einer Cross-Plattform-Solution

Inversion of Control

Um Abhängigkeiten zwischen Schichten und Komponenten zu vermeiden, setzen fast alle MVVM-Frameworks auf einen Inversion of Control. Dies ist auch bei den beiden Frameworks der Fall. Um alle Komponenten zu registrieren, muss das Core-Projekt bei MvvmCross eine App.cs enthalten. Hier wird festgelegt, mit welchem ViewModel die Anwendung startet oder welche Klasse die Geschäftslogik enthält. Die APP-Klasse wird plattformspezifisch initialisiert. Dazu enthält jedes plattformspezifische Projekt eine Setup.cs. Bei der Initialisierung werden die ViewModels via Reflection den passenden Views zugeordnet. Beispiel: MeinViewModel wird von MeinView verwendet (Listing 1).

using Cirrious.CrossCore.IoC;
using Cirrious.MvvmCross.ViewModels;

namespace TipCalc.Core
{
  public class App : MvxApplication
  {
    public App()
    {
      Mvx.RegisterType<ICalculation,Calculation>();
      Mvx.RegisterSingleton(new MvxAppStart());
    }
  }
}

Auf Seiten von Crosslight sieht der Mechanismus ähnlich aus. Auch hier gibt es eine zentrale Klasse im Core-Projekt, die von den Plattformprojekten aufgerufen wird. Nur die Namensgebung ändert sich ein wenig. Die Syntax ist nahezu identisch. Allerdings kommt hinzu, dass die Views über ein Attribut in der Code-Behind, respektive Activity, zugeordnet werden. So lassen sich auch verschiedene Views mit einem ViewModel bedienen (Listing 2).

namespace Rooms.WinPhone.Views
{
  [ViewModelType(typeof(DefineRoomViewModel))]
  public partial class DefineRoomPage
  {
  }
}

Crosslight setzt hier auf mehr Flexibilität, während MvvmCross sich etwas an ASP.MVC anlehnt. Es funktioniert beides ohne Probleme, und was man in der Praxis vorzieht, ist wohl eine Frage des persönlichen Geschmacks. Das Urteil lautet auch hier unentschieden.

Bindings, Commands und Converter

Damit dem Benutzer in seiner Anwendung auch tatsächlich Informationen angezeigt werden, sind beim MVVM-Pattern Bindings notwendig, die vom View auf das ViewModel zugreifen. Generell ist man es von WPF-Anwendungen gewohnt, die Bindings in XAML zu deklarieren. Diesen Weg geht MvvmCross. Hier lassen sich über Bindings, die im Framework definiert werden, einfache String- oder Integerwerte binden und so Commands unterstützen. Wird das Binding etwas komplizierter, ist es empfehlenswert, einen eigenen Binding-Provider zu schreiben oder schon im ViewModel zu versuchen, das Ganze zu vereinfachen. Bei iOS muss man auf Bindings im Layout noch verzichten. Hier muss das Ganze im Quellcode definiert werden. Bindings mit MvvmCross in Android:


Crosslight geht hier einen einheitlichen Weg. Die Bindings werden nicht in der Layout-Datei definiert, sondern in einem separaten Binding-Provider. Dieser kann über ein Attribut in einer Activity, Xamarins Entsprechung einer Code-Behind-Datei, importiert werden. Das erscheint auf den ersten Blick eigenartig. In der Praxis sorgt es aber für eine weitere Reduktion des plattformspezifischen Codes, da Binding-Provider im Core-Projekt abgelegt werden können. So lassen sie sich einfach von den unterschiedlichsten Projekttypen wiederverwenden (Listing 3).

public class SimpleBindingProvider : BindingProvider 
{ 
  #region Constructors
  public SimpleBindingProvider()
  {
    this.AddBinding("GreetingLabel", BindableProperties.TextProperty, "GreetingText"); 
    this.AddBinding("FooterLabel", BindableProperties.TextProperty, "FooterText");
    this.AddBinding("Text1", BindableProperties.TextProperty, new BindingDescription("NewText", BindingMode.TwoWay, Up dateSourceTrigger.PropertyChanged));
    this.AddBinding("Button1", BindableProperties.CommandProperty, "ShowToastCommand");
  }  
  #endregion 
}

In puncto Bindings erfüllen beide Frameworks ihre Aufgabe ohne Probleme. MvvmCross setzt, zumindest bei Android, auf einen dem Entwickler vertrauten Mechanismus. Dieser ist aber nicht so flexibel wie die Lösung von Crosslight. Da beide Ansätze ihren Charme haben und auch beide das Konzept von Value Convertern unterstützen, steht es weiterhin unentschieden.

[ header = Seite 2: Layout und Controls ]

Layout und Controls

Wie bei jeder Anwendung muss der Nutzer auch etwas auf dem Bildschirm sehen. Das geschieht in den Views. Aber hier wartet eine der größten Cross-Plattform-Herausforderungen. Es müssen nicht nur die verschiedenen Designsprachen der Plattformen beachtet werden. Auch die Formfaktoren der Geräte wie Smartphone oder Tablet spielen hier eine gewichtige Rolle. MvvmCross bietet für die grundlegende Präsentation von Daten eigene Controls, die sich um Templates erweitern lassen, fast so wie bei WPF (Listing 4).


Crosslight verfügt ebenfalls über diese Möglichkeit. Die Notation in C#-Code erfolgt wie im Abschnitt Bindings beschrieben. Aber Crosslight kann noch mehr, z. B. wenn es um das Erstellen großer Anwendungen geht. Das Framework bietet einen Projekt-Wizard mit einer Fülle von Einstellungsmöglichkeiten, die es erlauben, eine ganze Anwendungsstruktur per Knopfdruck zu erstellen. Zudem lassen sich mit Crosslight Seiten aus bereits vorgefertigten Templates erstellen und die Formfaktoren der unterschiedlichen Geräte angeben, die sich so direkt ansteuern lassen. Zusätzlich gibt es noch die Möglichkeit, Standardoberflächen wie Progressbars oder Messageboxen in der View zu definieren und die Ausführung auf den einzelnen Plattformen dem Framework zu überlassen.

Abb. 2: Crosslight-Projekt-Wizard

Obwohl MvvmCross hier sehr solide arbeitet, müssen doch viele, sich wiederholende, Aufgaben manuell erledigt oder gar neu programmiert werden. Zu erwähnen ist auch, dass sich mit dem neuen Release 3.0 von Xamarin auch ohne Crosslight mehr Code plattformunabhängig programmieren lässt – Xamarin.Forms sei Dank. Für Entwickler ist es eine Freude, wenn sich etwas automatisch erstellen lässt. Für den Vergleich beider Frameworks bedeutet das: Vorteil Crosslight.

Navigation

Ohne eine Navigation von Anwendungsseite zu Anwendungsseite wäre jede Anwendung ein ziemlich kleiner Spaß. Deshalb ist es notwendig, auf diese Funktion zu achten. MvvmCross löst diese Aufgabe, salopp gesagt, ziemlich „straight forward“. Der frameworkeigene Navigationsservice wird in der plattformspezifischen Setup.cs initialisiert und ab dann kümmern sich die Viewmodels um den Programmablauf. Eine Zeile Code genügt dafür schon. Wenn es nötig ist, können dabei auch Parameter übergeben werden. Navigation mit Parameter in MvvmCross:

ShowViewModel(new DetailParameters() { Index = 2 });

Crosslight steht seinem Konkurrenten in puncto Einfachheit in nichts nach. Auch hier ist die Navigation über einen Service geregelt, der nur darauf wartet, das entsprechende ViewModel genannt zu bekommen. Allerdings ist das erst der Anfang. Die Navigation zu verschiedenen Ableitungen, das Verhalten beim Zurücknavigieren oder auch die Navigation abhängig vom Formfaktor des Devices lassen sich bei Bedarf anpassen. Navigation zurück mit Parameter in Crosslight:

private void ExecuteOK(object parameter) 
{ 
  this.NavigationService.Close(new NavigationResult(this.InputText)); 
}

Beide Frameworks decken die Grundbedürfnisse der Navigation in fast identischer Art und Weise ab. Crosslight bietet aber deutlich mehr Möglichkeiten. Da sie aber eher in den Bereich des Anwendungslayouts passen, steht es in dieser Kategorie unentschieden.

Datenverarbeitung

Geschäftsanwendungen sind oftmals datengetrieben, und so verwundert es nicht, dass es mit SQLite auch eine Datenbank für mobile Endgeräte gibt. Doch können die Frameworks auch damit umgehen? MvvmCross bietet hier eine Erweiterung an, die SQLite plattformunabhängig einbindet und somit die ganze Verarbeitung im Core-Projekt ermöglicht.

Über eine solche Funktionalität verfügt Crosslight out of the box. Dabei werden aber auch noch andere Funktionen abgedeckt. Es kann ebenfalls mithilfe des Entity Frameworks ein Datenbankmodell angelegt werden, das über Web-API zugänglich ist. Ebenfalls integriert sind Online- und Offlineszenarien, Authentisierung und die Bereitstellung eines Repositories für die Verarbeitung der Models. Da es sich nicht nur auf den reinen Datenbankzugriff beschränkt, ist Crosslight hier einen ganzen Schritt weiter als MvvmCross. Crosslight erweitert das Ganze auch auf weitere bewährte .NET-Technologien und ermöglicht somit auch die Umsetzung von großen Softwareprojekten. Die elementaren Datenbankfunktionen bleiben dabei unkompliziert bestehen: Vorteil Crosslight.

Services/Plug-ins

Auf mobilen Endgeräten gibt es Funktionen, bei denen auf Ebene des Betriebssystems Information ausgelesen werden müssen. Hierzu gehört das Ablegen von Dateien oder das Auslesen der aktuellen Positionsdaten mithilfe von GPS. MvvmCross bietet hier diverse Plug-ins an, auf deren Basis sich eigene Services plattformunabhängig entwickeln lassen. Zudem lässt sich das Framework selbst mit diesen Plug-ins um Funktionen erweitern. Ein Beispiel dafür ist die Implementierung einer Messenger-Komponente, mit der sich Events aggregieren lassen. Mit bereits implementierten Services für diverse Aufgaben deckt Crosslight auch die mobilen Probleme des Alltags ab. Mit dem plattformübergreifenden Ansatz lässt sich so wenig Code wie möglich generieren. Verbindungsinformationen, Benachrichtigungen und der E-Mail-Service fallen hier besonders ins Auge: Diese sind bei MvvmCross nicht vorhanden. Bei beiden Frameworks fällt auf, dass die Erweiterungen stets versuchen, die plattformspezifischen Codeanteile zu reduzieren, ein Vorteil gegenüber der von Xamarin angebotenen Xamarin.Mobile-Komponente. MvvmCross kann aber an einigen Stellen noch nicht mithalten: die Plug-ins sind zum Teil noch in der Entwicklung oder konnten sich aus dem Projektkontext des Entwicklers noch nicht ergeben. Crosslight kann somit seinen kommerziellen Hintergrund voll ausspielen. Zudem wirken die Services wie aus einem Guss. Aus diesem Grund heißt es Vorteil für Crosslight.

Fazit: MVVM-Frameworks für die Cross-Plattform-Entwicklung im Vergleich

Wie der Vergleich gezeigt hat, lässt sich mit MvvmCross und seinen Grundfunktionen nichts falsch machen. Für den grundlegenden Aufbau des MVVM-Pattern hat MvvmCross Lösungen parat und meistens sind sie sogar identisch zu den Lösungen, die Crosslight bietet. MvvmCross ist somit ideal für den Einstieg in die Cross-Plattform-Entwicklung. Für den Fall, dass die tausendste Einkaufsliste für Android programmieren werden muss, hält MvvmCross den Frustrationslevel angenehm niedrig. Wenn die Ansprüche aber steigen, stößt MvvmCross schnell an seine Grenzen. Häufig müssen Entwickler dann mehr Zeit in die Eigenentwicklung von Lösungen stecken. Crosslight punktet hier mit vielen, bereits implementierten Lösungen, egal ob Datenbank, Authentifizierung oder Dateien. Selbst wenn es „noch nicht ganz passt“, stellt sich Crosslight oft als deutlich flexibler heraus. Ebenfalls machen sich bei einer großen, aber auch bei vielen kleinen Anwendungen die vorgefertigten Templates und der Wizard von Crosslight sehr schnell positiv bemerkbar. Die höhere Lernkurve lässt sich dabei durch viele Videotutorials und Beispiele effektiv verringern. Vor allem die neueste Version ermöglicht die Entwicklung der berühmten Line-of-Business-Anwendungen deutlich effizienter als MvvmCross.

Etwas plakativ zusammengefasst lässt sich feststellen: Als kommerzielles Framework zielt Crosslight auf kommerzielle Nutzer. MvvmCross richtet sich an Einsteiger und an alle, die nicht kommerziell sein wollen. Es ist aber trotzdem zu empfehlen, beide Frameworks auszuprobieren und sich nicht von Anfang von dem einen oder anderen Framework fernzuhalten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -