B2B Apps mit Xamarin


Unternehmensanwendungen mit Xamarin, eine nachhaltige Entwicklung

Es steht ein neues App Projekt vor der Tür und man stellt sich wieder die Fragen, "wie soll es umgesetzt werden" bzw. "mit welcher Technik…“ oder sogar „warum nicht mit Xamarin"? Dieser Beitrag gibt einen praktischen Einblick aus der Vogelperspektive in unsere bisherigen Xamarin Projekte. Du erfährst welche Fehler wir gemacht haben und wie sich Xamarin in vielen Projekten positiv bewährt hat.

Zielgruppe der App ermitteln und User Profile definieren, B2C oder B2B

Zu Beginn der App sollte man sich Gedanken über die potentiellen User machen, sind das Mitarbeiter im Unternehmen, Jugendliche, Erwachsene mit bestimmten Interessen? Denn nur wenn man den User "richtig" identifiziert kann man sich auch die Frage stellen mit welcher Lösungmethode man diesen bedienen möchte. Ganz klar, für eine B2C App die, die neusten Features haben muss und sehr komplexe UI Anforderungen hat ist es zwingend notwendig eine App bestenfalls Java/Swift zu programmieren, da man hier die Updates viel schneller bekommt. Dagegen falls die User an späteren Updates nicht gestört werden kann man auch hier in Richung Xamarin.Android sowie Xamarin.IOS gehen. Eine Globale B2C App, die zeitnah die neusten Plattform Features unterstützen muss sollte aber die Java/Swift Entwicklung angehen.

Bei einer B2B App wiederum sieht die Thematik ganz anders aus, denn hier sind meistens Mitarbeiter oder Kunden unsere User, die nicht unbedingt die neuesten Features brauchen. Für  diese Grupe ist zum einen die einwandfreie Funktionalität sowie das gute Design sehr wichtig. User Experience ist natürlich auch hier ein Thema, denn wer möchte bitte jeden Tag mit einer App arbeiten, die nicht clever entwickelt wurde. Schauen wir doch einfach mal die Merkmale einer solchen App genauer an.

Merkmale einer B2B App

Eine B2B App ist für eine bestimmte Business Gruppe gedacht, meistens landen diese Apps auch nicht in den Stores sondern werden über Management Services herausgegeben. Nun zu den Eigenschaften solcher Apps, die wir versuchen sehr grob zu definieren:

  • Daten können lokal abgespeichert werden
  • Online Funktionalität, Abindung an interne Systeme via REST oder anderen Standards
  • Barrierefreiheit ist intern evtl. eine Herausforderung
  • Daten müssen verschlüsselt abgespeichert werden
  • Benutzeranmeldung sowie Authentifizierung über vorhandene Systeme
  • Entwicklung findet im Team statt
  • Es existieren Bereits Deployment sowie Testing Guidelines
  • Lokalisierung 

Natürlich kann man diese Liste beliebig erweiteren, wir haben hier wirklich sehr grobe Annahmen getroffen.

Xamarin als Allheilmittel

Im Bereich B2B scheint Xamarin besonders gut seine Stärken auszuspielen. Lass uns doch einfach mal über die Punkte gehen und prüfen wie sich Xamarin hier integriert. Datenverwaltung, Offline sowie Online Funktionalitäten werden standardisiert in "Shared" Libraries aufgehoben, d.h. diese Funktionen stehen sowohl für iOS als auch für Android zur Verfügung. Verschlüsselung bietet iOS automatisch mit an, wenn man aber noch eine Sicherheitsstufe hochgehen möchte ist sich hier SQLCipher einen Blick wert. SQLCipher ist eine SQLite Datenbank, die von Haus aus verschlüsselt ist. Die Performance im Vergleich zu SQLite ist erstaunlich, Details dazu bietet euch dieser Artikel... Standard-Anmelde Logik wie mit OAuth2 müssen in iOS und Android getrennt implementiert werden, weil es hier keinen gemeinsamen Code gibt, man kann diese dennoch für die nächsten Projekte verwenden.

Thema Barrierefreiheit...

Grundsätzlich gilt, die Benutzer Schrifteinstellungen werden respektiert, d.h. die Änderungen sind in sofort in der App sichtbar. Ein Thema ist jedoch die Sprachausgabe, welche aktuell nicht in Forms zur Verfügung steht. Man müsste eine Vielzahl der Funktionen abstrahieren und im platform Code implementieren, dies ist mit einem gewissen Aufwand verbunden.

Lokalisierung mit Ressource Dateien

Übersetzung der UI kann mithilfe von statischen XML-Dateien (Resx) erfolgen. Zur weiterbearbeiten kann man die Datei einfach exportieren und an ein Übersetzungsbüro weitergeben.

Langfristige Ernte

Was hat man wenn man Xamarin nicht nur für kurzfristige sondern auch für langfristige Projekte plant, d.h. eine Firmenstrategie daraus entwickelt? Diese Überlegung haben wir als Cross-Apps mehrfach durchgeführt und möchten dir mal unsere Gedankenspielereien mitgeben. 

Zunächst einmal zu kurzfristigen Xamarin Projekten, das ist eine App, die mal schnell für einen Kunden entwickelt wird, deshalb nutzt man ausnahmweise Xamarin.Forms und schließt das Projekt ab. Weitere Projekte werden entweder in Java bzw. in Swift programmiert, je nach Kunde. Man entscheidet sich quasi "je nach Kunde" für eine Technologie. Wenn man sich aber eine strategische Frage stellt, "welche Benefits habe ich für meinen nächsten Kunden", dann überlegt man sich das Thema zwei, wenn nicht drei mal. 

Wir als Cross-Apps entwickeln, nur in Xamarin, nicht weil wir kein Java oder Swift können sondern weil wir Xamarin als strategisches Mittel für langfristigen Erfolg sehen. Jedes unserer Kundenprojekte erweitert unsere "Cross" Platform Module, die wir in zukünftigen Projekten mit Leichtigkeit einfügen und so Wartbarkeit und Langlebigkeit gewährleisten. 

Perspektiven

Gerade viele Entwickler die Xamarin vor 5 bzw. 7 Jahren ausprobiert und sich davon abgewendet haben, einfach weil ständig irgendwelche Probleme auftraten, werden sich aber wundern wie gut doch die Entwicklung im Moment vorran geht. Wir gehören noch zu jenen Entwicklern die für Xamarin Lizenzen Geld ausgegeben haben. Seit der Übernahme von Microsoft sind viele lang erwünschte Features dazugekommen. 

Wie realisiert man erfolgreiche Projekte im B2B Umfeld mit Xamarin und Tools.

Lasst uns zu Beginn die App Landschaft kurz erneut erkunden, wir wissen das es hier drei große Paradigmen existieren, native, hybrid, web. Während web und hybrid sich eher auf eine „Lösung für Alles“ konzentrieren, überzeugt eine native Entwicklung mit platformspezifischen Eigenschaften / Verhalten einer App und bietet damit ein besseres User Experience.

Aus diversen Diskussion im Kollegenkreis sowie Kundenkreis habe ich mitbekommen, das B2B Apps nicht unbedingt schön sein müssten und einfach nur funktionieren. Diesen Ansatz finden wir persönlich nur bedingt richtig, es gibt natürlich Nieschen in denen evtl. kein Wettbewerb herrscht, dort kann man sich mit diesem Ansatz kurzfristig zu frieden geben, aber was passiert wenn die Konkurrenz erwacht und hier ein besseres B2B Erlebnis anbietet?

B2B Apps mit Xamarin

Während die native Entwicklng mit Java und Swift diverse Vorteile mit sich bringt, wie bspw. verwenden von bereits existierenden UI Komponenten usw. ist diese Art von Projekten nur mit zwei Teams und damit verbunden zwei unterschiedlichen Toolings, Wartungsansätze, verbunden. Als einfaches Beispiel nehmen wir man benötigt eine Heatmap, welche man falls nicht vorhanden für zwei Platformen entwickeln muss, iOS & Android. Jedes weitere Feature dieser Komponente muss weiterhin für zwei Platformen entwickelt, gewartet und dokumentiert werden. Was aber wenn man für diesen Fall Xamarin und genauer Xamarin.Forms verwendet?

Xamarin.Froms + Skia = Unendliche Möglichkeiten

Gerade zur Geburtsstunde und Entstehungsphase von Xamarin war es nicht möglich komplexe UI Komponenten zu entwickeln. Als Entwickler hatte man quasi doppleten Afwand, für jede Platform, welche von der Komponenten unterstützt wird, bedürfte es einer individellen Entwicklung mit den platformspezifischen APIs. Seit geraumer Zeit existiert das SKIA Plugin für Xamarin, Skia ist eine Open Source Bibliothek für 2D Zeichnungen, welche ja nach Umfang der Komponente nur einmalig entwickelt werden müssen. Weiterhin besteht die Möglichkeit gewisse UI Teile „Cross-Plattform“ auszulagern und diese mithilfe von iOS sowie Android Widgets zu erweitern. Man stelle sich eine Chart Anzeige vor in der die Zeichnung Cross-Platform stattfindet und die Filter Elemtente wie Popover / Picker aus UIPickerView oder AndroidPicker bestehen.

.NET Entwickler im eigenen Unternehmen

Sofern Inhouse bereits .NET Entwickler im Einsatz sind, besteht eine Möglichkeit diese für Xamarin zu mobilisieren. Der Einstieg wird den meisten nicht schwer fallen, da sehr gute Quellen, Videos und Blogs zu dem Thema existieren. Welche Chancen sich für dieses Team in Zukunft ergeben ist natürlich auch ein strategisches Thema. Gerade in Zeiten des Fachkräfte-Mangels ist es wichtig Know How im eigenen Unternehmen zu etabilieren und natürlich auch regelmäßig zu teilen. Für den Einstieg in Xamarin sowie zu komplexen Themen bieten wir deshalb unsere Speed-Learning Kurse an. 

Aus Fehlern lernen

Wir haben bei einigen Kundenprojekten zuästzliche MVVM Frameworks, wie bspw. MvvmCross verwendet. Ich muss gestehen der Funktionsumfang ist zwar imens, aber für uns hat sich der Einstieg (damals Version 4) nicht gelohnt. Die Frameworks nehmen grundsätzlich einiges an Arbeit ab, bspw. bietet MvvmCross eine ViewCell für Tabellen / Listen an um das Databinding zu ermöglichen. Sofern das nur so einfach wäre ist alles in Ordnung, doch sobald man aus dem "MvvmCross-Standard" raus möchte gibt es gewisse Schwierigkeiten zu lösen. Ein Upgrade auf eine neuere Version ist bei unseren Projekten quasi unmöglich gewesen, da MvvmCross.Plugins, bspwl für Dialoge, Dateizugriffe etc, nicht zeitlich aktualisiert wurden, oder aber nicht mit der Xamarin.Forms Version kompatibel waren. Ein weiteres Problem für uns sind gewisse "Mvx"-Funktionen (MvvmCross Präfix) gewesen welche unzureichend oder sogar falsch dokumentiert wurden. Solche Themen haben enorm viel Zeit und Energie gekostet weshalb man letzten Endes sagen kann, dass es mit Boardmitteln womöglich einfacher zu lösen wäre.

Shared Project oder ein Durcheinander

Xamarin.Forms bietet Shared Projects oder / PCLs (inzwischen .NET Standard) um den Quellcode zwischen Platformen zu trennen. Während Shared Project quasi in Xamarin.iOS (oder aber Xamarin.Android) "hineinkompiliert" wird, erstellt das PCL Projekt eine eigene DLL. Der Quellcode in einem Shared Project muss demnach mit Compile-Flags versehen werden, damit man den plattformspezifischen Code, welcher nur für iOS bspw. gilt, trennen kann. Man stelle sich nun vor wie schnell ein Shared Project wachsen kann und sich quasi überall Compile-Flags angehäuft haben. Das Problem für uns war der "Flow", an gewissen Stellen konnte man den Ablauf einer Funktion nur noch schwer nachvollziehen, da sich Code für iOS und Anroid "vermischt". 

Die bessere Alternative hier ist ganz klar der neue .NET Standard (oder vorher PCL), da man hier nicht dern Überblick verliert.