Plattformübergreifende Entwicklung mit dem Mono-Projekt

Eine für alle?!
Kommentare

Entwickelt man Anwendungen für ein bestimmtes Betriebssystem, ist die Auswahl groß. Es stehen verschiedene technologische Ansätze und Frameworks zur Verfügung. Will man jedoch plattformübergreifend entwickeln, schrumpft die Anzahl der Möglichkeiten merklich. An erster Stelle wird weiterhin die Programmierung mithilfe der Sprache Java genannt. Aber es gibt auch andere Ansätze einer systemübergreifenden Programmierung. Wir haben einen intensiven Blick auf das Mono-Projekt geworfen.

Die plattformübergreifende Entwicklung gewinnt zunehmend an Bedeutung. Der Traum jedes Softwareentwicklers aus technischer Perspektive und noch viel mehr der Traum jeder Softwarefirma ist es, die Anwendung nur einmal zu konzipieren, das Design für die Oberfläche einmalig zu entwerfen und dann das fertige Produkt auf allen gängigen Betriebssystemen zur Verfügung zu stellen. Heutzutage kann diese Vorstellung noch offener formuliert werden: Neben den unterschiedlichen Betriebssystemen, wie Windows, Linux und Mac OS, hat die Zahl der Gerätekategorien in den letzen Jahren erheblich zugenommen. Die Palette reicht vom klassischen Desktoprechner bis hin zum Smartphone. Unter Berücksichtigung dieser gerätetechnischen Dimension potenzieren sich die Einsatzmöglichkeiten einer Software. Auch weitere Betriebssysteme sind von Relevanz, die bisher in klassischen Anwendungsbereichen keine Rolle gespielt haben. Gemeint ist zum Beispiel Android als Betriebssystem für Smartphones und Tablet-PCs (Abb. 1)

Abb. 1: Einsatz von Software aus hard- und softwaretechnischer Perspektive

Ansätze, Software auf verschiedenen Plattformen verfügbar zu machen, gibt es mehrere. Java geht den Weg über die Programmiersprache, indem die Programme in einer Art Sandbox auf dem jeweiligen Endgerät laufen. Die Java-Runtime-Umgebung wird für eine Vielzahl von Betriebssystemen zur Verfügung gestellt. Das Konzept hat sich über die Jahre bewährt. Dennoch gibt es auch Situationen, in denen der Einsatz von Java nicht möglich bzw. nicht empfehlenswert ist. Beispielsweise können laufzeittechnische Aspekte (Performance) eine entscheidende Rolle spielen. Gelegentlich wird auch berichtet, dass sich Java-Anwendungen etwas fremd auf dem jeweiligen Betriebssystem anfühlen. Dieses Kriterium ist nur zum Teil richtig und hat sich in den letzen Jahren auch (teilweise) überholt, da die grafischen Bibliotheken entsprechend in der Zusammenarbeit mit den nativen API-Funktionen des jeweiligen Systems besser interagieren bzw. diese besser nachbilden. Richtig ist natürlich, dass die speziellen Möglichkeiten einer nativen Entwicklung in Bezug auf das jeweilige Betriebssystem immer Vorteile bieten und manche Anforderungen nur darüber umgesetzt werden können. Beispielsweise sind die vielfältigen Gestaltungsmöglichkeiten von Benutzeroberflächen unter Microsoft Windows aktuell nur unter Verwendung des .NET Frameworks in Verbindung mit der Windows Presentation Foundation (WPF) umzusetzen.
Eines gleich vorweg: Eine ideale Variante einer plattformübergreifen Entwicklung wird es auch in Zukunft nicht geben. Generalisierung geht eben zu Lasten der Spezialisierung! Es gilt, das richtige Mittelmaß für den individuellen Anwendungszweck ausfindig zu machen und es mit den dafür am besten geeigneten Werkzeugen umzusetzen.



In diesem Beitrag des Entwickler Magazins beschäftigen wir uns mit der dem Mono-Projekt. Neben einer Vorstellung des Projektes stehen folgende Themen auf der Agenda:

  • Das Mono-Projekt und die historische Entwicklung im Überblick
  • Heutige Bedeutung und erfolgreich adaptierte Applikationen
  • Installation unter Windows und Linux
  • Entwicklungsumgebung MonoDevelop
  • Erstellung einer ersten Anwendung
  • Portierung von Anwendungen

Das Mono-Projekt und die historische Entwicklung im Überblick

Das von Miguel de Icaza mitgegründete Unternehmen Ximian hatte das Ziel, eine Reihe von .NET-kompatiblen Werkzeugen inklusive eines C#-Compilers und einer Common Language Runtime für die Verwendung unter Windows, Linux, mehreren Unix-Derivaten und unter Mac OS X zu erstellen. Einige Meilensteine des Projektes lauten:

  • April 2001: Die erste Version wird präsentiert
  • Juli 2001: Gründung des Mono-Open-Source-Projektes
  • April 2004: Mono 1.0 wurde veröffentlicht
  • Oktober 2008: Mono 2.0 wurde veröffentlicht; dazu wurden die wichtigsten Eigenschaften von .NET 2.0 realisiert; ebenfalls gab es Bemühungen die neueren Technologien von .NET 3.0 und .NET 3.5 zu implementieren; C# wurde um LINQ erweitert
  • Dezember 2009: Version 2.4.3. wurde herausgebracht; der Compiler basiert nunmehr auf C# 4.0
  • 2011: Gründung des Unternehmens Xamarin, welches die Entwicklung des Mono-Projektes fortsetzt, nachdem das Engagement von Novell endete

Heutige Bedeutung und erfolgreich adaptierte Applikationen

Auf die Frage, welche Bedeutung das Mono-Projekt heute hat, kann man mehrere Fakten nennen. Ein entscheidendes Kriterium ist die Möglichkeit, plattformübergreifende Anwendungen zu entwickeln. Während in den letzen Jahren die Entwicklung von Desktopanwendungen unter dem Betriebssystem Windows im Wesentlichen vom .NET Framework geprägt wurde, gab es derartig große und umfassende Umbrüche bei anderen Betriebssystemen nicht zu verzeichnen. Das .NET Framework schaffte eine Unabhängigkeit der Entwicklung von Applikationen von der eingesetzten Programmiersprache. Für die endgültige Qualität der Anwendungen spielt es keine Rolle, ob mit der präferierten Sprache C#, mit Visual Basic for .NET oder einer anderen – auf das .NET Framework angepassten Sprache – entwickelt wird. Eine weitere Stärke des .NET Frameworks bildet der sehr große Umfang an Klassen und Datentypen. Für (fast) jeden Verwendungszweck finden sich Ansatzpunkte und vorimplementierte Klassen. Bei der Umsetzung einer Aufgabenstellung kann man als Entwickler meist auf einen großen Fundus an Vorarbeiten zurückgreifen. Das vereinfacht die Entwicklung, reduziert die Fehlerrate und schont wertvolle Zeitressourcen. Die Stabilität von verwaltetem Code, verbunden mit einer sehr komfortablen Entwicklungsumgebung (Visual Studio) erleichtert die Programmierung von Anwendungen erheblich. Diese Eigenschaften und die daraus resultierenden Vorzüge sprechen dafür, diese Technologie auch auf anderen Plattformen zu verwenden. Der Reiz einer möglichen plattformübergreifenden Entwicklung ist dabei ungebrochen.
Ein weiteres Motiv für die Existenzberechtigung des Mono-Projekts besteht natürlich darin, dass man die Abhängigkeit der Programmentwicklung von Anwendungen (auf der Basis von .NET) von Microsoft verringern will.
Das Mono-Projekt existiert nun schon einige Zeit und es lohnt sich, eine Bestandsaufnahme zum heutigen Zeitpunkt durchzuführen. Sieht man auf die Webseite des Projektes, so ergeben sich folgende Teilprojekte:

  • Mono: Hierbei handelt es sich um das Ausgangs- und Kernelement des Mono-Projektes. Mono soll plattformübergreifende Anwendungen auf unterschiedlichen Systemen ermöglichen. Als technisches Vorbild gilt das .NET Framework.
  • MonoTouch for iOS: Mittels dieses Projektes ist es möglich, iPhone- und iPad-Apps auf der Basis der Programmiersprache C# zu entwickeln. Bei der Verwendung fallen Lizenzgebühren an. Lediglich das Testen mithilfe der Free Edition (Emulator) ist kostenfrei. Darüber hinaus existieren eine Professional (399 US-Dollar), eine Enterprise (999 US-Dollar) und eine Enterprise Priority Edition (2499 US-Dollar).
  • Mono for Android: Dient der Entwicklung von Apps für die Android-Plattform. Hinsichtlich der Editionen und der Preisgestaltung gilt das gleiche, was zu der Version von MonoTouch for iOS ausgeführt wurde.

Auch bei der Verwendung von Mono für die mobilen Plattformen liegt die Hoffnung auf einer möglichst plattformübergreifenden Entwicklung. Hier sind die Erfahrungen noch geringer und die zu berücksichtigenden Betriebssysteme (Android, iOS und Windows Mobile, …) sind andere und werden in einer anderen Häufigkeit eingesetzt, als es bei Desktopanwendungen der Fall ist (Abb. 2).

Abb. 2: Einsatzhäufigkeiten mobiler Betriebssysteme, Quelle

Wie gut ein Produkt ist, zeigt sich insbesondere daran, ob es sich in der praktischen Anwendung bewährt. Auf unseren Fokus übersetzt bedeutet das: Gibt es erfolgreich umgesetzte Anwendungen, die auf dem Mono-Framework basieren? Auf der Webseite des Projektes werden einige implementierte Programme auf der Basis des Mono-Frameworks vorgestellt. Dazu gehören u. a.:

  • Das Zeichenprogramm Pinta
  • Das UML-Modellierungswerkzeug NClass
  • Das Schachprogramm SharpChess
  • Das Administrationswerkzeug Likewise

[ header = Entwicklungsumgebung ]

Entwicklungsumgebung

Mono selbst ist zunächst nur das Pendant zur .NET-Laufzeitumgebung. Für die Entwicklung von Programmen wird weiterhin eine Entwicklungsumgebung benötigt. Dazu wird MonoDevelop bereitgestellt. MonoDevelop ist eine vollständig integrierte Entwicklungsumgebung (IDE). Vom Aufbau, der Bedienung und der Konzeption ist sie mit Visual Studio zu vergleichen. Die folgenden Abschnitte basieren auf der Verwendung dieser IDE. Zum Zeitpunkt des Verfassens dieses Beitrages (Anfang Juli 2012) war die Version 3 (3.0.3) aktuell.

Installation unter Linux

Die Motivation zur Nutzung von Mono liegt – wie bereits ausgeführt – primär in dem Ziel einer plattformübergreifenden Entwicklung von Anwendungen. Demzufolge war es der erste Schritt, Mono auch direkt unter Linux zu probieren. Als „eingefleischter“ Windows-Nutzer und -Entwickler muss man zugeben, dass der direkte Umstieg nicht leicht fällt. Alles fühlt sich zunächst fremd an … Als Betriebssystem arbeitet Ubuntu in der Version 12.04 LTS (Abb. 3). Im nächsten Schritt gilt es, Mono und MonoDevelop unter Linux zu installieren. Dazu wechselt man in das Ubuntu-Softwarecenter und wählt (über die Suchfunktion) MonoDevelop als zu installierendes Paket aus. Ubuntu bezieht die notwendigen Ressourcen automatisch aus dem Internet, die Installation läuft ohne weitere Eingriffe selbstständig ab. Zu beachten ist dabei, dass noch nicht für alle unterstützen Betriebssysteme die aktuellste Version von MonoDevelop als vorkompiliertes Paket zur Verfügung steht, so auch unter Ubuntu. Hier wird auf die Version 2.8 ausgewichen, was wir akzeptieren. Nach der Installation geht es gleich an einen ersten Versuch. Wir starten MonoDevelop (Abb. 4). Danach wird ein neues Projekt angelegt mittels des Befehls Datei | Neu | Projektmappe … Aus dem eingeblendeten Dialogfeld wird in der Rubrik C# ein Gtk#2.0-Projekt ausgewählt. Dazu sind noch ein Name und der Speicherort für das Projekt zu vergeben. Im nächsten Dialogfeld ist die Gtk#-Version auszuwählen, sofern mehrere installiert sind. Wir entscheiden uns für die aktuellste Version, in diesem Fall mit der Revisionsnummer 2.8. Hier kommt es gegenüber dem klassischen Entwicklungsvorgehen von Anwendungen unter Microsoft Windows zur ersten entscheidenden Abweichung: Für Desktopanwendungen unter Windows wurde unter .NET eine sehr lange Zeit auf die Klassenbibliothek Windows Forms zurückgegriffen. Sie ist ausgereift und stellte sehr lange Zeit den Standard für die Entwicklung derartiger Anwendungen dar. Seit einiger Zeit (mit der Einführung des .NET Framework 3.5 und der Verfügbarkeit von Visual Studio 2010) ist jedoch ein Wechsel des GUI-Frameworks hin zu Windows Presentation Foundation (WPF) zu verzeichnen. WPF ist vollständig vektorbasiert und bietet fast unerschöpfliche Möglichkeiten hinsichtlich der grafischen Gestaltung. Mit diesen Vorzügen hat die WPF den Entwurf von Benutzeroberflächen für Geschäftsanwendungen revolutioniert. Dennoch: Will man plattformübergreifend entwickeln, sind beide Bibliotheken keine Alternative, da sie nicht unter Betriebssystemen wie Mac OS oder Linux zur Verfügung stehen. Man bleibt damit auf die Verwendung unter Microsoft Windows beschränkt. Wir benötigen einen anderen – eben plattformübergreifenden – Ansatz. Über Mono kann man grundsätzlich mit verschiedenen grafischen Benutzeroberflächen umgehen, u. a. mit Gtk, Qyoto oder Qt4Dotnet. Die Frage ist nun, welche Bibliothek am besten geeignet ist. Auf der Seite des Mono-Projektes finden sich dazu einige Hinweise. Für die folgenden kleineren Experimente werden wir die Gtk#-Bibliothek einsetzen. Ergänzende Informationen zur Gtk#-Bibliothek sind im Kasten „Gtk – Grafik für alle“ zusammengestellt.

Abb. 3: Ubuntu Linux macht einen ausgereiften und intuitiv bedienbaren Eindruck

 

Abb. 4: Erster Eindruck von MonoDevelop, Version 2.8 unter Ubuntu Linux

Gtk – Grafik für alle
Das GTK+ (GIMP Toolkit) ist eine Multiplattformumgebung zur Gestaltung von grafischen Benutzeroberflächen. Es umfasst einen vollständigen Satz von Steuerelementen, beispielsweise zur Gestaltung von Dialogfeldern. GTK+ ist in C++ programmiert und zunächst auch für eine Verwendung durch die Programmiersprache C++ vorgesehen. Die Anbindung an das Mono-Framework bzw. die Sprache C# wird durch einen Wrapper erreicht. Die Verwendung von Gtk durch Mono (C#) wird durch den Zusatz von „#“ zu Gtk# deutlich gemacht. Um also Benutzeroberflächen für Mono-Anwendungen zu entwerfen, ist es notwendig, sich mit den Eigenarten der Gtk-Bibliothek vertraut zu machen.

Kehren wir zur Programmentwicklung mit MonoDevelop unter Linux zurück. Nunmehr gilt es – wie bei jedem anderen Softwareprojekt auch – der Anwendung eine Struktur (Architektur) zu verleihen, einen Entwurf der Benutzeroberfläche vorzunehmen (auf der Basis des gewählten Grafikframeworks, hier Gtk#), den Quellcode für die Umsetzung des Fachkonzeptes zu entwerfen (Basis ist C#, die Syntax ist bekannt), eine mögliche Datenbankverbindung zu koppeln, die Schnittstelle zwischen Programmlogik und Benutzeroberfläche zu entwerfen und für deren Anbindung zu sorgen. Ein Schritt sollte bei der plattformübergreifenden Entwicklung nie vergessen werden: das Testen der Anwendung unter allen Zielsystemen.

[ header = Installation unter Windows ]

Installation unter Windows

Fast etwas reumütig kehren wir zu Microsoft Windows als Betriebssystem zurück und machen uns dort an die Installation von Mono und MonoDevelop. Zu einer vollständigen Installation gehören eine aktuelle Version von Mono, Gtk (als Bibliothek für das Erstellen der Benutzeroberflächen) und natürlich MonoDevelop. Für Windows steht die neue Version 3 als Installationspaket zur Verfügung. Und nach dem Start ist man gleichwohl positiv überrascht. Die IDE wirkt modern, deutlich leichtgewichtiger und erinnert (wen verwundert es) an Visual Studio 2010 (Abb. 5). Auch unter Windows wird gleichwohl ein erstes Testprojekt angelegt. Ausgewählt werden C# und Gtk 2.0 Mittels des grafischen Designers lässt sich schnell ein erster rudimentärer Entwurf der grafischen Benutzerschnittstelle entwerfen (Abb. 6). Testweise wird aus der Toolbox auch eine Komponente vom Type FileCooserButton (Auswahldialog für Dateien) auf die Oberfläche gezogen. Interessant ist dabei, wie diese typische Funktionalität des Betriebssystems nunmehr unter Verwendung der Gtk-Bibliothek umgesetzt wird. Nach dem Start unserer kleinen Testanwendung können wir das unmittelbar beurteilen. Gegenüber den Standarddialogen ist natürlich eine Abweichung festzustellen, aber grundsätzlich ist die vollständige Funktionalität einer Dateiauswahl darüber zu erreichen.

Abb. 5: MonoDevelop 3.0 unter Microsoft Windows

Abb. 6: Einsatz des grafischen Designers von MonoDevelop

Ein Streifzug durch die Entwicklungsumgebung

Die neue Entwicklungsumgebung MonoDevelop in der Version 3 sollte genügend Potenzial bieten, um sich mit ihr etwas näher zu beschäftigen. Der Aufbau der Programmoberfläche entspricht dem typischen Design einer Entwicklungsumgebung. Wie gesagt, der Wiedererkennungswert zu Visual Studio 2010 ist unmittelbar gegeben. Betrachten wir ausgewählte wichtige Aspekte der IDE:

  • Die Anlage eines neuen Projektes erfolgt mit File | New Solution
  • Unter Projekt | Optionen … können Voreinstellungen für das Projekt, zum Beispiel im Hinblick auf den Compiler, vorgenommen werden.
  • Unter Build bzw. Run kann der Build des Projektes bzw. der gesamten Solution veranlasst bzw. der Start der Anwendung mit oder ohne Debugging durchgeführt werden.
  • Im Quellcode können Breakpoints gesetzt werden (Abb. 7). An dieser Stelle wird das Programm bei der laufenden Ausführung unterbrochen. Hier werden dem Entwickler dann die entsprechenden Informationen zur Verfügung gestellt. Beispielsweise Informationen zu Variablen oder verwendeten Objekten.
  • Version Control: Unterhalb dieses Menüpunkts kann ein Versionskontrollsystem angebunden und gesteuert werden.
  • Erweiterungen der IDE können über Tools | Add-in-Manager … installiert, deinstalliert und verwaltet werden.

Abb. 7: Das Setzen von Breakpoints erfolgt in gewohnter Weise im Quelltexteditor

Bevor man das erste ernsthaftere Projekt startet, sollte man sich mit der Bedienung und Arbeitsweise der Entwicklungsumgebung vertraut zu machen. Auch ergibt es Sinn, dass eine oder andere Testprojekt zu erstellen. Das Erstellen von Oberflächen auf der Basis der Gtk-Bibliothek will geübt werden. Ein wichtiger Punkt in diesem Zusammenhang ist die Stabilität der Entwicklungsumgebung. Dazu können noch keine abschließenden Aussagen getroffen werden, der Test an umfangreichen Projekten steht noch aus. Eine stabile Umgebung ist essentiell für eine erfolgreiche Programmentwicklung. Es muss eine Vielzahl von Dateien und Einstellungen verwaltet werden, das Umschalten zwischen Lauf- und Entwicklungszeit muss problemlos erfolgen und noch wichtiger: Fehler sind sicher abzufangen und dürfen keine so genannten Seiteneffekte produzieren. Ein Beispiel: Die versehentliche Änderung der Größe einer Schaltfläche auf einen fehlerhaften – außerhalb des Wertbereiches – liegenden Wert führte zu einem Absturz des Designers der IDE und letztendlich zu der Notwendigkeit, MonoDevelop neu zu starten. Aber wie gesagt, daran lässt sich nicht die Qualität der IDE im Gesamten bestimmen. Zunächst einmal gilt der Grundsatz: Regelmäßig speichern!

Ein Test

Zur Einarbeitung in Mono, MonoDevelop und der plattformübergreifenden Entwicklung ist es notwendig, sich die entsprechende Arbeitsumgebung einzurichten. Dazu ist in einem ersten Schritt das Betriebssystem für die Programmentwicklung auszuwählen. Für den Test in anderen Systemumgebungen kann entweder auf einen weitereren Rechner oder auf Virtualisierungslösungen zurückgegriffen werden. Demonstrieren wir einen solchen Test anhand eines Miniprojektes. Es wird MonoDevelop Version 3 unter Windows 7 verwendet. Dazu wird ein neues Gtk-Projekt gestartet und auf dem Hauptformular werden zwei Labels, zwei Textboxen (Entry) und zwei Buttons platziert (Abb. 8). Zuvor ist jedoch ein entsprechender Layoutcontainer anzugeben. Für eine absolute Platzierung der Steuerelemente wird ein Container vom Typ Fixed ausgewählt. Die Verbindung zwischen Benutzerschnittstelle (hier den einzelnen Komponenten) und der Programmlogik erfolgt über so genannte Signale. Dies entspricht der Ereignisbindung in Windows Forms. Gebunden wird das Signal Clicked. Beim Doppelklick auf dieses Signal in der IDE wird der zugehörige Rahmencode durch MonoDevelop erzeugt, der nun mit Leben gefüllt werden sollte. Im Beispiel soll beim Klick auf den OK-Button lediglich ein Meldungsfenster angezeigt werden. Auch unter Gtk handelt es sich dabei um eine MessageBox. Listing 1 zeigt den zugehörigen Quellcode. Ähnlichkeiten mit der C#-Syntax (dem .NET Framework) sind vorhanden. Als Besonderheit ist zu bemerken, dass die Zerstörung des Objektes nach Verwendung manuell erfolgen sollte. Informationen zur Syntax der Gtk-Bibliothek in der Verwendung durch C# (Mono) kann man hier nachlesen. Nach dem Kompilieren lässt sich die Anwendung wie geplant starten (Abb. 9). Die Verzeichnisstruktur entspricht im Wesentlichen derjenigen, die von Visual Studio erzeugt wird. Eine entsprechende ausführbare Datei in Form eines exe-Files wird erzeugt.

Abb. 8: Entwurf der Benutzeroberfläche für das Testprojekt

Abb. 9: Die Testanwendung unter Windows 7

protected void OnButton2Clicked (object sender, EventArgs e)
{
  MessageDialog md = new MessageDialog (this, 
    DialogFlags.DestroyWithParent,
    MessageType.Error, 
    ButtonsType.Close, "Hier kommt eine Meldung");
  int result = md.Run ();
  md.Destroy();
}

Unser Miniprojekt soll nun unter Linux getestet werden. Dazu erfolgte ein Transfer der Anwendung auf das Ubuntu-System. Hier musste ausschließlich die ausführbare Datei gestartet werden (Abb. 10). Dies geschieht recht einfach über das Kontextmenü (rechte Maustaste) und durch Aufruf des Eintrages Ausführen mit Mono-Runtime.

Abb. 10: Die Testanwendung unter Linux

Portierung von Anwendungen

Werden Anwendungen vollständig neu entwickelt und ist ein Einsatz auf unterschiedlichen Betriebssystemen von vorne herein geplant, so kann das unmittelbar bei der Programmierung berücksichtigt werden. Oftmals wird die Anwendung bereits für .NET (also für das Betriebssystem Microsoft Windows) vorliegen und es gilt einzuschätzen, mit welchem Aufwand eine Portierung in andere Systemumgebungen möglich ist. Dazu sind letztendlich die Klassen des .NET Frameworks durch ihre Äquivalente innerhalb von Mono zu ersetzen. Um den Aufwand und die Erfolgsaussichten einschätzen zu können, steht das Tool Mono Migration Analyzer (MoMA) auf der Webseite des Projektes zum Download zur Verfügung. Nach der Auswahl einer .exe– oder .dll-Datei kann der Analysevorgang gestartet werden. Das Tool prüft folgende Gesichtspunkte (Abb. 11):

  • Existieren alle verwendeten Methoden in Mono?
  • Werden so genannte Unmanaged-Code-Aufrufe (Platform Invocation Services) durchgeführt?
  • Ausgabe weiterer Hinweise, die bei der Portierung nach Mono beachtet werden müssen.

Wie gesagt, das Tool gibt Hinweise auf mögliche Problemstellen bei der Portierung der Anwendung. Der ausführliche Portierungsprozess kann danach gestartet werden; wenn man erkennt, dass er mit akzeptablem Aufwand durchgeführt werden kann.

Abb. 11: Der Mono Migration Analyzer (MoMA) als Hilfe bei der Anwendungsportierung

Fazit und Ausblick

Ein seriöses Fazit nach einem so kurzen Streifzug durch die Mono-Welt zu ziehen, ist eigentlich nicht möglich und würde auch gegenüber dem Projekt nicht gerecht ausfallen. Tatsächlich ist es ein weiterer Vorschlag, den lang ersehnten Traum der plattformübergreifenden Programmentwicklung in den Griff zu bekommen. Aufgrund der Heterogenität der Betriebssysteme wird es mit Sicherheit den hundertprozentigen Ansatz niemals geben. Dennoch: Es geht gerade darum, in heterogenen Zielumgebungen möglichst einen Großteil des Quellcodes ohne größere Portierungen zu übernehmen. Dabei haben sich in der Vergangenheit wiederkehrend einige Kernprobleme herauskristallisiert. Dazu gehören der Entwurf der Benutzeroberfläche, der Umgang mit den unterschiedlichen Sicherheitskonzepten der Betriebssysteme, die Zugriffsmöglichkeiten auf das Dateisystem und die Ansprache hardwarenaher Elemente. Mono versucht unter Verwendung einer unabhängigen Grafikbibliothek (zum Beispiel Gtk), das Problem der Erstellung der Benutzeroberfläche in den Griff zu bekommen. Natürlich kann das Mono-Projekt auch nicht zaubern und hat mit den Schwierigkeiten der unterschiedlichen Systeme zu kämpfen.
Darüber hinaus kann festgestellt werden, dass mit der neuen Version 3 von MonoDevelop das gesamte Projekt gewissermaßen einen Aufschwung erfährt. Zum einem hat die Entwicklungsumgebung einen deutliches Facelift gegenüber der Version 2 erfahren, zum anderen fühlt sich die Arbeit damit stabiler und flüssiger an. Interessant wird der Einsatz der Version 3, wenn sie auch für alle wichtigen Linux-Distributionen zur Verfügung steht. Ein weiteres interessantes Feature soll nochmals herausgestellt werden: Mono für die plattformübergreifende Entwicklung von Apps für Smartphones und Tablet-PCs zu verwenden. Auch wenn man mit diesem Schritt die Open-Source-Gemeinde verlässt und Lizenzkosten anfallen, so kann es doch lohnend sein. Die Hoffnung besteht, als .NET- bzw. C#-Entwickler eine für sich ganz neue Welt aufzustoßen, ohne weitere Programmiersprachen (Objective-C bzw. Java) zu lernen. Für eine aussagekräftige Beurteilung in diesem Bereich ist jedoch noch zu früh, bzw. Aufgabe eines eigenen umfangreichen Testszenarios.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -