.NET@mobile – #1: Einführung in App-Entwicklung und Xamarin

Es ist schon eine ganze Weile her, dass ich mein erstes iPhone-Projekt zusammengestöpselt habe. Eigentlich ist das ja auch gar nicht so schwer, wäre da nicht dieses verfluchte Objective-C und das komische X-Code. Seit über einem Jahr nutze ich nun die Tools von Xamarin und möchte in diesem und folgenden Beiträgen meine Erfahrungen mit Euch teilen.

Nichts für arme Leute

Um das gleich mal vorweg zu nehmen: Das, was ich hier beschreiben werde kann man nur komplett nachvollziehen, wenn man mindestens 300 $ in die Hand nimmt. Mir ist bewusst, dass ich durch diese Aussage allein so einige Leser verlieren werde. Der Preis basiert auf dem Lizenzmodell der Firma Xamarin und kann je nach Anforderung durchaus höher liegen.

Inhalte

Ich weiß jetzt schon, dass ich nicht alles wichtige zu diesem Thema in einen Post reinbekommen werden. Also versuche ich es auch gar nicht erst, sondern teile das ganze auf. Ich stelle mir derzeit folgende Artikel vor:

Teil 1: Einführung in App-Entwicklung und Xamarin

Teil 2: Infrastruktur für Developer (IDE, TFS)

Teil 3: Design von Projektmappen

Teil 4: Publishing

Womöglich muss ich diese Aufteilung später verfeinern, aber ich möchte das Thema einfach mal angehen und hoffe, ein wenig Klarheit in diese Welt zu bringen.

Worum gehts eigentlich?

Ich beginne mal mit einer Einführung in das Thema App-Entwicklung. Wen das nicht weiter interessiert, der kann gern etwas weiter unten ansetzen.

Heute macht kein Mensch mehr eine Zeitung auf, ohne das Thema Mobility um die Ohren gehauen zu bekommen. Als Entwickler kommt man immer öfter in die Situation, dass man Inhalte für Mobilgeräte aufbereiten soll. Das einfachste Beispiel ist da noch das responsive Design von Webseiten (siehe Artikel „Responsive Design mit ASP.NET MVC„). Darum geht es hier jedoch nicht. Vielmehr soll hier das sog. native Entwickeln von Mobil-Apps behandelt werden. Der Unterschied ist eigentlich recht schnell erläutert: Native Apps werden direkt vom Betriebssystem des Mobilgerätes gestartet und angepasste Webseiten laufen innerhalb eines Browser-Prozesses.

Nun scheiden sich die Geister der App-Welt an der Frage, welches der beiden Programmier-Modelle eigentlich das bessere oder zukunftsträchtigere Wäre. Auch codingfreaks hat dazu nach Jahren der App-Programmierung und -Beratung eine Meinung. Wir stehen grundsätzliche auf dem Standpunkt, dass Apps nativ entwickelt werden sollten. Dabei berücksichtigen wir derzeit die Umgebungen iOS, Android und Windows Phone 8. Blackberry scheint zum aktuellen Zeitpunkt wieder mehr in das Interesse der Öffentlichkeit zu rücken. Man wird sehen.

Aus Entwicklersicht bedeutet dies einiges. Zunächst einmal werden Apps für die 3 genannten Plattformen unter Nutzung ganz unterschiedlicher Plattformen und Sprachen entwickelt:

  • iOS: Apple bietet mit X-Code eine kostenfreie Entwicklungsumgebung und erfordert, dass native Anwendungen mit Objective-C, einer C++-basierten Sprache, entwickelt werden. (iOS-Development-Portal)
  • Android: Android-Anwendungen werden typischerweise mit Java programmiert. Als IDE kommt oft Eclipse zum Einsatz. (Android-Developer-Seite).
  • Windows: Microsoft hat mit Windows Phone 8 genau genommen erst Anschluss an die Konkurrenz bekommen. Programmiert wird entweder auf Basis von .NET (Sprache wie immer egal) oder mittels HTML5. (Windows Phone DevCenter)

Die Vorteile der nativen Programmierung sind aus meiner Sicht:

  • Die Performance ist deutlich besser.
  • Man erhält direkten Zugriff auf die API des Gerätes.
  • Die App fühlt sich echt an und ist nicht durch JavaScript o.ä. „verhunzt“.
  • Änderungen an den SDKs der Hersteller können sofort adaptiert werden (man muss nicht warten, bis eine JS-Bibliothek angepasst wurde).
  • Sicherheitsaspekte können direkt umgesetzt werden.
  • Man muss sauberer programmieren, da man sich zwangsläufig mit den Interna der Geräte auseinandersetzen muss.

Ein paar Nachteile seien aber auch nicht verschwiegen:

  • Man programmiert für jede Plattform etwas eigenens.
  • Man muss sich mit den Plattformen auseinander setzen (Lernaufwand, Zeit)
  • Die Plattformen unterscheiden sich in den Anforderungen erheblich.

Da es nun schon genug Aufwand bedeutet, sich mit den Plattformdetails auseinander zu setzen, schien es vielen bislang unzumutbar, nun auch noch ständig zwischen Java, Objective-C und C# zu wechseln. Daher wohl auch das wachsende Interesse an den Web-Frameworks bzw. Zwischen-Schichten, die aus irgendwas dann plattformspezifischen Code bauen.

Xamarin

Jetzt kommt Xamarin ins Spiel. Wer ist das eigentlich? Zuerst einmal wird den meisten eher das Hauptprojekt dieser Firma bekannt sein: „Mono“. Mono ist als eine Laufzeitumgebung für .NET-Code auf Nicht-Windows-Plattformen gestartet. Besonders bekannt ist der Kopf dieser Foundation Miguel de Icaza. Dieser gründete irgendwann die Firma Xamarin und übernahm im gleichen Atemzug die Entwicklung von Mono von Novell. Inzwischen wird Mono auch von Microsoft sehr ernst genommen und entsprechend besser supported.

Offensichtlich erkannten auch die Xamarin-Jungs schnell einen Bedarf für das Problem der plattformübergreifenden Mobilentwicklung und entwickelten zunächst ein Framework für die Entwicklung von iOS-Apps mit C# – MonoTouch.

Wer die Website von Xamarin besucht, wird gleich durch das Motto auf die Zielrichtung der Produkte hingewiesen: „Create iOS, Android and
Mac apps in C#.“ Das sagt eigentlich genau das aus, was man mit den Xamarin-Tools inzwischen machen kann. Es gibt 3 unterschiedliche Ziel-Plattformen: Android, iOS und Mac. Für Mobil-Entwickler sind nur die beiden erstgenannten von Bedeutung.

Wer sich erst einmal mit dem Produkt befassen möchte, kann das ganze zunächst mit der sog. FREE-Edition testen. Hier ist vieles bereits enthalten (später mehr dazu). Will man ernsthafter werden, sollte es mindestens die INDIE für 300$ pro Plattform sein. Das heißt man legt ca. 600 $ hin, wenn man Android und iOS als Ziel wählt (kauft man beides, gibts 50 $ Rabatt).

Arbeitet man in einem Unternehmen, kommen schnell Anforderungen, wie das Inhouse-Deployment und WCF usw. hinzu. Dann muss es die BUSINESS werden (die wir in dieser Serie benutzen werden). Ebenfalls erst ab BUSINESS ist die Integration in das Microsoft Visual Studio enthalten.

IDE

Bis vor Kurzem war man für die Entwicklung gegen Xamarin auf die freie Entwicklungsumgebung MonoDevelop angewiesen. Diese ist inwzischen im Xamarin Studio aufgegangen. Hierbei handelt es sich um eine vollwertige IDE, die an vielen Stellen deutlich Visual Studio erkennen lässt, was gut ist. Das Studio dient der Entwicklung von Code.

Das Studio gibt es für Mac und Windows zum kostenfreien Download. Es bietet IntelliSense, Debugging, Publishing usw. an. Insgesamt vermisst man Code-seitig nicht wirklich etwas. Was allerdings bewusst außen vor gelassen wurde, ist ein UI-Designer unter iOS. Hier greift Xamarin einfach auf die X-Code zurück, sobald man doppelt auf eine View klickt. Für Android ist ein Designer dabei.

Nicht alles Gold, was glänzt…

Auch Xamarin kann nicht völlig frei von Zwängen einfach so gekauft, installiert und vollumfänglich genutzt werden. Nehmen wir mal das Beispiel iOS-Entwicklung. Ich kann mir Xamarin Studio und die dazu gehörige Einbindung ins Visual Studio natürlich auf meinem Windows-Rechner installieren. Nur bringt das nicht das erhoffte volle Glück. Hintergrund: Auch mit Xamarin ist iOS-Entwicklung nur unter Nutzung der nur für den Mac erhältlichen Apple-Entwicklertools so wirklich schön. Das geht los beim Einbinden der Publish-Zertifikate und geht weiter über den Interface Builder und andere Elemente. Wie ich später noch zeigen werde, will auch die Visual-Studio-Komponenten von Xamarin am liebsten einen Mac als Build-Server haben.

Auch an anderer Stelle hat Xamarin noch das ein oder andere Problemchen zu lösen. Man muss sich einfach vor Augen halten, dass Mono als Grundlage für MonoTouch und MonoAndroid letztlich die Klassen des Original-.NET-Framework nachbildet. Wie bei jeder anderen Software auch, kann es hierbei natürlich immer zu Fehlern kommen. Letztens fiel mir sowas komplett auf die Füße, als ich merkte, dass die DateTime.Parse-Methode des MonoTouch-Frameworks einfach nicht mit dem deutschen Datumsformat arbeitet und fröhlich Exceptions wirft.

…aber

Trotz einiger Stolpersteine und Probleme muss man allerdings sagen, dass Xamarin sehr bemüht darum ist, dem Entwickler so einiges für sein Geld zu bieten. Ich würde diese Artikelserie auch nicht beginnen, wenn wir nicht bereits sehr gute Erfahrungen mit Xamarin gemacht hätten. Wenn man die Tools richtig einsetzt, entsteht ein wunderbarer Workflow, der sogar vor dem TFS nicht halt macht (Git wäre sowieso möglich).

Mein Setup

Nach dem ganzen Geplänkel nuin aber endlich mal was handfestes. Wie sieht denn der codingfreaks-Arbeitsplatz des sprinter eigentlich aus? Hier mal die Bildversion:

Abb. 1: sprinters Place
Abb. 1: sprinters Place

Ihr seht ganz links (3 Bildschirme) meinen Windows-Entwicklungsrechner. In der Mitte steht ein Notebook (unwichtig) und rechterhand ist ein iMac zu sehen. Hier der schematische Aufbau:

Abb. 2: Schema
Abb. 2: Schema

Das also ist das Setup, mit dem ich in diesem und den folgenden Artikeln loslegen werden.

Ausblick

Im nächsten Artikel werden wir uns mit der Einrichtung der einzelnen Komponenten beschäftigen und sie uns zum ersten Mal gemeinsam ansehen. Ich werde versuchen, möglichst anschauliche Webcasts zu produzieren und das Zusammenspiel zwischen Windows und Mac demonstrieren. Wünscht mir Glück!

3 Antworten auf „.NET@mobile – #1: Einführung in App-Entwicklung und Xamarin“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.