Android besitzt ein sehr grosses Eco-System an Third-Party Bibliotheken. Es kann öfters durchaus Sinn machen eine bestehende Java Bibliothek in ein Xamarin.Android Projekt einzubinden anstatt selber eine entsprechende Implementation in C# zu schreiben.

Dabei gibt es zwei mögliche Optionen:

• Erstellen einer Binding Bibliothek. Dies ist im Wesentlichen eine Wrapper um die Java Bibliothek herum. Die Bindings werden mit Hilfe von so genannter Managed Callable Wrappers (MCW) implementiert.
• Verwendung des Java Native Interface (JNI) um direkt Java Code aufzurufen.

In folgendem Blog Beitrag wird auf die erste Option eingegangen und anhand eines Beispielprojektes gezeigt, auf was für Probleme man dabei stossen kann und wie diese gelöst werden können.

Das komplette Beispielprojekt kann hier gefunden werden und beinhaltet die Xamarin Solution sowie den Java Source Code der Beispielbibliothek.

Vorgehen

• Erstellen der Binding Library
  Xamarin bieten eine Projektvorlage für das Erstellen einer Binding Bibliothek. So kann einfach zu einer bestehenden Xamarin.Android Solution ein neues Binding Projekt hinzugefügt werden.Im Template enthalten ist unter anderem die Datei Metadata.xml. Mit Hilfe von dieser kann in den Generierungsprozess der Bindings eingegriffen werden. Ausführliche Informationen dazu sind auf der Xamarin Website zu finden.
• Java Bibliothek zum Binding Projekt hinzufügen
  Um die Java Bibliothek zum Binding Projekt hinzuzufügen, zieht man die Jar Datei in den Jars Ordner des Projektes. Anschliessend muss noch die richtige Build Action für die Jar Datei ausgewählt werden. In Unserem Fall ist dies EmbeddedJar. Eine genaue beschreibung der verschiendenen Build Actions kann hier gefunden werden.
• Binding Projekt kompilieren
  Nun kann das Projekt kompiliert werden. Doch das ist leichter gesagt als getan. Versucht man dies nämlich mit der oben verwiesenen Jar Datei, so stellt man fest, dass mehrere Fehler auftreten:
  

CS0234 The type of namespace name ‘TipCalculationServiceBase’ does not exit

Wenn man sich diesen Fehler genauer anschaut, so sieht man, dass eine Klasse TipCalculationServiceImpl generiert worden ist, welche von TipCalculationServiceBase ableitet. Allerdings wurde gar keine TipCalculationServiceBase Klasse generiert. Um die Ursache des Problems zu finden, muss man sich den Java Code genauer ansehen. Dort ist zu erkennen, dass beide Klassen ebenfalls vorhanden sind. Die TipCalculationServiceBase Klasse ist allerdings nicht public. Während es in Java erlaubt ist, dass eine public Klasse von einer anderen ableitet, die nicht public ist, so ist das in C# nicht möglich.

Um das Problem zu lösen hat man nun zwei Möglichkeiten:

• Man entfernt die TipCalculationServiceImpl Klasse mit folgendem Eintrag in der metadata.xml Datei:

  <remove-node path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceImpl']"/>

Dies ist in unserem Fall jedoch keine Option, weil wir die TipCalculationServiceImpl verwenden wollen und somit unsere Binding Library einen solchen Wrapper besitzen muss.

• Man macht die TipCalculationServiceBase mit Hilfe der metdata.xml Datei public:

  <attr path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceBase']" name="visibility">public</attr>

Nun wird zwar ebenfalls ein Binding für die TipCalculationServiceBase Klasse erstellt, allerdings sollte man im C# Code diese nicht direkt verwenden.

Versucht man das Projekt erneut zu kompilieren, so stellt man fest, dass nun zwar alle vorgängigen Fehler behoben wurden. Allerdings ist ein neuer erschienen:

Dieser Fehler tritt auf, wenn z.B. ein Binding für eine Java Methode generiert wird, dass einen kovarianten Rückgabe Wert hat. So definiert das Java Interface TipCalculationService für die Methode CalculateTip einen Rückgabewert vom Typ Object, während bei TipCalculationServiceBase der Rückgabewert vom Typ TipCalculationResult ist.

Nun hat man auch wieder zwei Möglichkeiten um das Problem zu lösen:

• Man ändert den Typ des Rückgabewertes für den generierten C# Code indem folgenden Eintrag in der Metadata.xml definiert_

  <attr path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceBase']/method[@name='calculateTip' and count(parameter)=1 and parameter[1][@type='crehmann.samples.monodroidjarexample.TipRequest']]" name="managedReturn">Java.Lang.Object</attr>

• Man fügt zum Projekt eine Partial Class Deklaration hinzu, welche das Interface entsprechend implementiert:

  using Java.Lang;
  
  namespace Crehmann.Samples.Monodroidjarexample
  {
     public abstract partial class TipCalculationServiceBase
     {
         Object ITipCalculationService.CalculateTip(TipRequest p0)
         {
             return CalculateTip(p0);
         }
     }
  }

Nun lässt sich das Projekt ohne Fehler kompilieren und kann innerhalb des Xamarin.Android Projektes referenziert und verwendet werden.

Fazit

Mit Xamarin ist es relativ leicht möglich bestehende Android Java Bibliotheken zu verwenden. Mit dem Binding Projekt Template kann dabei auf einfache Weise eine Wrapper Bibliothek generiert werden. Dabei hat man viele Möglichkeiten um in die Generierung der Wrapper Klassen einzugreifen und diese zu modifizieren um dadurch allfällige Probleme zu beheben.

Mittlerweilen besitzt fast jeder eine Smartphone und verschiedenste Apps haben sich schon fest in unseren Alltag integriert. Android und iOS sind dabei die beiden grössten Plattformen aber auch Windows Phone von Microsoft ist am Wachsen.

Die Entwicklung von Apps für zwei oder gar drei Plattformen kann jedoch sehr zeitintensiv und kostenaufwendig werden. Insbesondere, da jede Plattform ihre spezifische Programmiersprache besitzt und somit kaum Code zwischen den Applikationen geteilt werden kann. Daher hat sich in den letzten Jahren ein eigenes Ökosystem an Frameworks entwickelt, die sich das Ziel gesetzt haben Cross Platform Development zu vereinfachen. Dabei können unterschiedliche Strategien verfolgt werden:

Web Apps
Diese Apps werden mit HTML5, CSS und JavaScript entwickelt. Sie laufen jeweils im Browser der mobilen Geräte. Aus diesem Grund haben sie auch nur sehr beschränkten Zugriff auf die Hardware und die Sensoren der Geräte. Als ein weiteres Hindernis werden oft die mobilen Datenverbindungen gesehen, welche zu längeren Ladezeiten führen können.
Dies hat selbst grosse Webseiten wie zum Beispiel Facebook und LinkedIn dazu bewogen Apps für mobile Plattformen anzubieten.

Hybrid Apps
Die Hybrid Apps basieren auch auf HTML5, CSS und JavaScript. Im Gegensatz zu den Web Apps können sie zwar über einen Mobile Store veröffentlich werden, jedoch sind sie keine nativen Applikationen und laufen innerhalb eines Web Containers. PhoneGap ist ein Beispiel eines Frameworks, mit dem man solche Apps entwickeln kann. Durch die Verwendung von Plugins wird der Zugriff auf plattformspezifischen Funktionalitäten ermöglicht. Diese werden jeweils in der plattformspezifischen Sprache entwickelt. Allerdings unterscheiden sich solche Apps immer noch merklich von nativen Apps, da sie oft bei Performance und dem gewohnten Look and Feel nicht mithalten können.

Cross Compiled Apps
Diese Apps werden mit einer Programmiersprache geschrieben und anschliessend in die plattformspezifische Sprache kompiliert. Sie haben somit den Vorteil, dass sie die nativen SDK Bibliotheken verwenden können. Ebenso ist es auch möglich UI Komponenten der jeweiligen Plattform einzusetzen. Weiter kann vollumfänglich auf die Sensoren, wie etwa GPS, Kamera und Gyroskop, zugegriffen werden. Die User Experience ist dadurch gleich gut wie bei einer nativen App.

Native Apps
Native Apps werden mit den plattformspezifischen Programmiersprachen und SDK’s implementiert. Es kann auf alle Hardware Features zugegriffen werden. Möchte man allerdings mehrere Plattformen abdecken muss der sogenannte Silo Approach verwendet werden. Das heisst, dass die App für jede Plattform einzeln entwickelt werden muss. Dabei müssen nicht nur die verschiedenen Programmiersprachen beherrscht, sondern auch unterschiedlichste Entwicklungsumgebungen und Toolchains verwendet werden. Aus diesem Grund werden oftmals verschiedene Entwicklerteams pro Plattform eingesetzt. Dies kann dann wiederum zu mehr Komplexität führen, da sich die Teams auch untereinander absprechen müssen.

Cross-Platform Development mit Xamarin

Wir bei Noser Engineering arbeiten eng mit unserem Partner Xamarin zusammen um unseren Kunden den besten Mehrwert für Ihre mobilen Investitionen zu bieten.

Xamarin ist ein Framework, dass die Cross Compile Strategie verfolgt. Es basiert auf Mono und stellt nahezu 100% der nativen API von Android, iOS und Windows Phone zur Verfügung und steht so der nativen Entwicklung in nichts nach. Als Programmiersprache kommt plattformübergreifend C# zum Einsatz. Dadurch ist es möglich die gesamte Anwendungslogik zu teilen und bis zu 90% des Codes wiederzuverwenden. Lediglich das UI muss für jede Plattform einzeln entwickelt werden. Für das Erstellen des UI kann auf bewährte Designtools wie Storyboards für iOS, AXML für Android und XAML mit Blend für Windows Phone zugegriffen werden.

Sollte es doch einmal nötig sein, dass man auf eine bereits bestehende Objective-C, Java oder C/C++ Bibliotheken zugreifen muss, bietet Xamarin ausserdem die notwendige Interoperabilität.

Die Cross Compile Strategie hat einige Vorteile gegenüber dem Silo Approach der nativen Entwicklung:

•  Die Entwicklung kann mit einer Programmiersprache durchgeführt werden und erleichtert somit die Arbeit des Entwicklers.
• Die Anwendungslogik, welche den grössten Teil der Entwicklung ausmacht, kann zwischen den verschiedenen Plattformen geteilt werden. Dadurch können Code Duplikationen vermieden werden. Dies führt zu einer Verkürzung der Entwicklungszeit und auch bei der Wartung und Weiterentwicklung der Applikation müssen Änderungen jeweils nur an einer Stelle vorgenommen werden.
• Durch die Aufwandersparnis, die durch das Teilen der Anwendungslogik entsteht, lassen sich erheblich Kosten einsparen.