© prettyboy80/Shutterstock.com
Teil 2: Android-Besonderheiten für Entwicklungen mit Xamarin

Die Hostplattform kennen


Einer der gefährlichsten Irrglauben im Bereich Cross-Plattform-Entwicklung ist, dass man auch ohne Verständnis der Hostplattform erfolgreiche Applikationen erzeugen kann. Da Android spätestens dank der Übernahme von Xamarin durch Microsoft auch in den Fokus der .NET-Entwickler rückt, wollen wir nun einen Blick auf das Betriebssystem als Ganzes werfen. Schon aus Gründen der besseren Weiterverwendbarkeit unserer Ergebnisse wollen wir als Arbeits- und Forschungsumgebung Xamarin verwenden.

Die folgenden Schritte basieren auf der mit Visual Studio 2015 Update 2 ausgelieferten Version der Entwicklungsumgebung. Starten Sie die IDE, und erzeugen Sie ein neues Projekt vom Typ Visual C# | Android | Blank App (Android). Das leere Projektskelett bietet uns Gelegenheit für erste Gelegenheiten zur Reflektion.

Auf den Spuren der Alten

Android ist im Grunde genommen eine Kette von parallel ablaufenden Android-Runtimes, die über eine darunterliegende Serviceschicht miteinander verbunden werden. Jede Applikation läuft dabei in ihrer eigenen Laufzeitumgebung und kann auf die Daten der anderen Apps nicht zugreifen. Die Datei AndroidManifest.xml realisiert einen Index aller im Projekt enthaltenen Elemente und ist zudem für die Zuweisung von Intents und Ereignissen an Handler verantwortlich. Die Bearbeitung des Files erfolgt unter Android Studio normalerweise manuell. Im Fall von Xamarin Studio ist die Situation komplett anders, da die Entwickler ihren Nutzern das manuelle Anpassen der Datei ersparen möchten. Wer die im Ordner Properties liegende Datei im Editor öffnet, sieht folgenden Code:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="SUSAndroidTest1.SUSAndroidTest1" android:versionCode="1" android:versionName="1.0">
<uses-sdk android:minSdkVersion="16" />
<application android:label="SUSAndroidTest1"></application>
</manifest>

Der Unterschied zu Android Studio liegt darin, dass Xamarin die Manifestdatei anhand von diversen Einstellungen zusammenbaut. Die in Visual Studio angebotene Datei wird während der Kompilation von Xamarin geparst und um die aus den Callouts erzeugten Deklarationen erweitert. Der Generator weiß dabei, welches Kindelement in welches Elternelement wandern muss.

So kommt die Deklaration der Activity beispielsweise aus der Datei MainActivity.cs, wo sich folgendes Kommando findet:

[Activity(Label = "SUSAndroidTest1", MainLauncher = true, Icon = "@drawable/icon")]

Wer die Ergebnisse der Arbeit des Mergingprozesses sehen möchte, öffnet die unter obj/Debug/android/AndroidManifest.xml liegende Variante des Files – die so aussieht:

<?xml version="1.0" encoding="utf-8"?>
<manifest . . .>
<uses-sdk android:minSdkVersion="16" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

Nach der Deklaration der minimal zulässigen SDK-Version melden wir die beiden Permissions an, die für die Programmausführung notwendig sind. Android setzt auf das von JavaME und Symbian eingeführte Berechtigungssystem, um den Nutzern so zu ermöglichen, unerwünschte Applikationen anhand des Verhaltens zu erkennen und außer Gefecht zu setzen.

Im nächsten Schritt folgt das eigentliche Application-Objekt, in dem die Eigenschaften/Attribute des Programms festgelegt werden. Die Activity-Declaration besprechen wir im nächsten Abschnitt:

 <application android:label="SUSAndroidTest1" android:name="mono.android.app.Application" android:allowBackup="true" android:icon="@drawable/icon" android:debuggable="true">
<activity android:icon="@drawable/icon" android:label="SUSAndroidTest1" android:name="md54ad7a0700598417e8970a2871168311f.MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Weiter unten befindet sich die Deklaration eines Providers. Es handelt sich dabei um eine Art Hilfsdienst, der für die Applikation notwendige Aufgaben erledigt. Der Prozess mit dem Namen Seppuku ist für den Aufruf eines Teils der Mono-Runtime zuständig, die für die eigentliche Abarbeitung des Codes beim Debugging verantwortlich ist (Listing 1).

 <provider android:name="mono.MonoRuntimeProvider" android:exported="false" android:initOrder="2147483647" android:authorities="SUSAndroidTest1.SUSAndroidTest1.mono.MonoRuntimeProvider.__mono_init__" />
<!--suppress ExportedReceiver-->
<receiver android:name="mono.android.Seppuku">
<intent-filter>
<action android:name="mono.android.intent.action.SEPPUKU" />
<category android:name="mono.android.intent.category.SEPPUKU.SUSAndroidTest1.SUSAndroidTest1" />
</intent-filter>
</receiver>
</application>
</manifest>

Listing 1

Realisierung weiterer Formulare

Nach diesem zugegebenermaßen unhandlich langen Codestück wollen wir uns der Realisierung weiterer Formulare zuwenden. Der Aufbau des Hauptformulars dient uns dabei als „Vorlage". In der Datei MainActivity.cs findet sich folgender Code:

public class MainActivity : Activity
{
int count = 1;

protected override void OnCreate(Bundle bundle)
{
base.OnCreate(bundle);
SetContentView(Resource.Layout.Main);
. . .
}
}

Android-Ressourcen entstehen normalerweise aus xml-Dateien, die zur Laufzeit von einem Parser eingelesen und belebt werden. Im Fall unserer Activity erfolgt dies durch den Befehl setContentView, der die im Ordner /Resources/layout liegende Datei Main.axml einliest. Ihr Format wurde im vorhergehenden Artikel im Detail besprochen; weitere Informationen finden sich in der Xamarin-Dokumentation.

Klicken Sie im nächsten Schritt auf Add | New Item | Activity, um ein neues Formular zu erstellen. Vergeben Sie als Name ZweiteActivity. Xamarin reagiert darauf mit der Erzeugung der Datei ZweiteActivity.cs. Sie beschränkt sich im Moment auf ...

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