4: ARKit. Mit Manuela Rink

In dieser Folge spreche ich mit Manuela Rink von Apple über die Grundlagen von ARKit unter iOS.

Links

Neuer Podcast “DevTalk”

Ich habe einen neuen Podcast gestartet! Von jetzt an gibt es jede zweite Woche eine neue Folge. In jeder Folge werde ich einen (oder mehrere) Gast/Gäste zu einem Thema aus der Welt der Softwareentwicklung interviewen. Der Schwerpunkt liegt auf Microsoft-Technologien, aber auch andere Technologien werden thematisiert werden.

In der ersten Folge spreche ich mit Robin-Manuel Thiel von Microsoft über die Cloud im Allgemeinen.

Den Feed zum Abonnieren gibt es unter https://kerry.lothrop.de/feed/podcast/.

1: Erste Schritte mit der Cloud. Mit Robin-Manuel Thiel.

Dies ist der Start meines neuen Podcasts. In diesem Podcast werde ich alle zwei Wochen einen Gast zu Themen rund um die Softwareentwicklung interviewen. Der Schwerpunkt liegt auf Microsoft-Technologien, aber auch andere Technologien sollen zu Wort kommen.

In der ersten Folge spreche ich mit Robin-Manuel Thiel von Microsoft über die Möglichkeiten der Cloud und von Azure.

Links:

Die vielen Varianten von HttpClient

HttpClientHandler

Wer Xamarin verwendet, hat die Möglichkeit, den Standard-.NET-HttpClient zu verwenden. Standardmäßig ist HttpClient eine komplette Reimplementierung des gesamten HTTP-Stacks in Mono. Für viele Anwendungsfälle reicht dies aus, allerdings kann durch die Wahl eines alternativen HttpClientHandler ein unterschiedliches Verhalten erreicht werden. Für meinen Vortrag auf der Evolve habe ich eine Übersicht der unterschiedlichen HttpClientHandler zusammengestellt:

HttpClientHandlers

CFNetworkHandler (iOS 6+) und der neue NSUrlSessionHandler (iOS 7+, ab Xamarin.iOS 9.8) sind Handler, die Apple native APIs statt der Mono-Implementierung verwenden. Der Standardhandler, der beim Aufruf des Defaultkonstruktors von HttpClient verwendet wird, kann entweder in der IDE oder durch Übergabe einer Option an mtouch (z.B. --http-message-handler=NSUrlSessionHandler) beeinflusst werden.

iOS-Optionen: HttpClientHandler

Für Android gibt es jetzt AndroidClientHandler (ab Xamarin.Android 6.1). In der IDE gibt es keine Option zur Definition des Standardhandlers, allerdings lässt sich der Handler mit Hilfe einer Textdatei mit der @(AndroidEnvironment) Build Action die Umgebungsvariable XA_HTTP_CLIENT_HANDLER_TYPE auf den Wert Xamarin.Android.Net.AndroidClientHandler setzen.

Alternativ kann aus ModernHttpClient der NativeMessageHandler an den HttpClient-Konstructor übergeben, wordurch auch native Implementierungen für HTTP-Aufrufe verwendet werden.

SSL/TLS

Die Standardimplementierung in Mono unterstützt leider im Gegensatz zu den nativen Handlern nicht den neuesten (und sichersten) TLS-Standard 1.2. Um TLS 1.2 mit der Mono-Implementierung zu verwenden, hat Xamarin.iOS 9.8 eine Möglichkeit eingeführt, die TLS-Implementierung durch P/Invoke-Aufrufe in die TLS-Implementierung von Apple zu ersetzen. Dies kann entweder über die IDE oder die mtouch-Option --tls-provider=appletls aktiviert werden.

iOS-Optionen: TLS

Für Android gibt es aktuell keine solche Option, allerdings wird erwartet, dass bald BoringSSL-Support hinzugefügt wird.

Hier ist die Zusammenfassungsfolie aus meine Vortrag:

HttpClient comparison

Xamarin hat tatsächlich eine Reimplementierung des TLS-Codes erstellt, um auch TLS 1.1 and 1.2 zu unterstützen. Es wird allerings erwartet, dass diese Implementierung aus Sicherheitsbedenken verworfen und stattdessen die nativen Implementierungen der jeweiligen Plattformen herangezogen werden, so wie Microsoft das seit jeher schon mit Windows macht.

Update (2017-02-15)

Hier ein Update zum aktuellen Stand zu HttpClient:

  • Man kann jetzt in den Projekteinstellungen von Android-Projekten angeben, dass man den AndroidClientHandler verwenden will, so wie es bereits für iOS möglich war.
  • Wie erwartet hat Xamarin TLS-1.2-Unterstützung zum Mono-HttpClientHandler hinzugefügt durch die Einbindung von Googles BoringSSL. For Android ist diese Option ebenfalls in den Projekteinstellungen auswählbar. BoringSSL bringt TLS 1.2 auch für die Unix/Linux-Implementatierungen von Mono.
  • Entgegen meinem bisherigen Kenntnisstand unterstütz ModernHttpClient doch support Certificate Pinning mit Hilfe von ServicePointManager. Thomas Bandt hat einen exzellenten Blogbeitrag darüber geschrieben, wie man Certificate Pinning mit ModernHttpClient oder sogar AndroidClientHandler zum Laufen bekommt.

Und hier ist die aktualisierte Matrix:

HttpClient comparison

Wow, ich bin ein Microsoft MVP!

Am 1. April 2016 wurde mir der Microsoft-MVP-Status für “Visual Studio and Development Technologies” verliehen. Für mich ist das eine große Ehre und ich bin immer noch ein bisschen baff. Ich habe in der kurzen Zeit seit Beginn des Monats schon mitbekommen, auf welche neuen Informationen ich jetzt Zugriff erhalte und habe neue Kontake geknüpft. Ich freue mich sehr auf das, was noch bevorsteht.

Der überraschende Teil war, dass ich meine Community-Arbeit fast ausschließlich auf die Xamarin-Technologie beschränkt hatte. Oktober 2015 wurde durch eine Änderung der Kategorien für das MVP-Programm plötzlich Xamarin als eine der möglichen Technologien aufgeführt, für die der MVP-Award vergeben wird (hey, auf der Liste steht sogar Java!).

MVP-Award-Kategorien

Ich wurde von Microsofts Technical Evangelist Daniel Meixner Ende 2015 nominiert (vielen Dank!), dann gab es ein Review, und offensichtlich haben meine Beiträge zur Community der Jury gereicht.

2016 soll weitergehen wie 2015. Anfang des Jahres habe ich zum MvvmCross-4.0-Relase beigetragen, ich habe schon zwei öffentliche Vorträge gehalten und die Zeit gefunden, um zu bloggen. Jetzt, da die Xamarin-Evolve-Konferenz vor der Tür steht (auf der ich auch einen Vortrag halten werde) bin ich gespannt, in welche Richtung Xamarin und jetzt Microsoft das Cross-Platform-Abenteuer führen werden. Die Ankündungen auf der Build-Konferenz haben mich persönlich schon sehr glücklich gemacht, und ich freue mich darauf, das Wissen in Zukunft mit noch mehr Entwicklern teilen zu können.

Wer einen meiner Vorträge sehen will, sollte auf meiner Liste öffentlicher Vorträge nachsehen. Dort werde ich auch Links zu Folien oder Videos für all diejenigen posten, die den Vortrag verpasst haben.

Vielen Dank vor allem auch an meinen Arbeitgeber Zühlke, der mich bei der Communityarbeit mit Zeit und Geld unterstützt!

C/C++-Bibliotheken aus Xamarin-Code aufrufen

Mit Hilfe der Xamarin-Plattform lassen sich iOS- und Android-Anwendungen vollständig in C# entwickeln. Es gibt jedoch Fälle, in denen existierender Code zu groß oder komplex ist, um eine Portierung nach C# sinnvoll werden zu lassen. Die meisten Beispiele, die man online findet, zeigen, wie man existierenden Objective-C-Code in Xamarin.iOS und existierenden Java-Code in Xamarin.Android einbindet, obwohl es durchaus möglich ist, C-Code aus einer Xamarin-App aufzurufen. Seit kurzem unterstützt Microsofts C/C++-Projekte für iOS und Android in Visual Studio, wodruch diese Aufgabe deutlich einfacher wird.

Die einzubindende-Bibliothek muss im Quelltext vorliegen, um sie für iOS und Android zu kompilieren. Der Code darf keine Bibliotheken verwenden, die nur in Binärform für eine andere Plattform kompiliert vorliegen.

Als erstes sollte ein neues “C++ Cross Platform Project” mit Visual Studio 2015 erzeugt werden.
Neues Cross-platform-Projekt erzeugen
Hierzu muss das passende Visual-Studio-Paket bei der Installation ausgewählt worden sein.
Visual Studio Setup Cross-Platform Mobile C++
Hierdurch werden drei Projekte erzeugt: Eins für Android, eins für iOS und ein Shared Project.
Projektstruktur

Hierzu muss man das Shared-Project-Konzept verstanden haben. Der Code im Shared Project wird, anders als andere Visual-Studio-Projekte, nicht in eine DLL oder Bibliothek übersetzt. Ein Shared Project kann jede Art Datei beinhalten. Projekte, die das Shared Project referenzieren, können auf den Code in jeder Datei im Shared Project zugreifen. Wird Code nicht referenziert, wird er auch nicht kompiliert. Aus diesem Grund ist es notwendig, Aufrufe in den geteilten Code in die plattformspezifischen Projekte aufzunehmen. Dies heißt, dass auch die plattformspezifischen Projekt Code enthalten müssen. Der Code kann für Android und iOS identisch sein und aus der jeweils gleichen Datei stammen. Im Gegensatz zu .NET wird hierfür kein File-Linking benötigt, da der Code nicht Projektverzeichnis oder -unterverzeichnis liegen muss.

Im Beispiel habe ich eine einfache Funktion clib_add_internal() erstellt, die zwei Integers addiert und im Shared Project liegt.


Dieser Code wird aus einer Funktion in den plattformspezifischen Projekten aufgerufen.

Das ergibt für das Beispielprojekt eigentlich keinen Sinn. In einem echten Projekt würden man den Code, der aus dem .NET-Code aufgerufen werden soll (das Interface) in die plattformspezifischen Projekte nehmen und den darunterliegenden Code in das Shared Project.

Die Aufrufe aus .NET heraus erfolgen mit Hilfe von P/Invoke, da C++/CLI für iOS und Android nicht verfügbar ist. Daher müssen auch die übrlichen Regeln für P/Invoke für den Interface-Code eingehalten werden: Entweder ist der Code reiner C-Code oder, wenn C++ verwendet wird, sind die Aufrufe entweder einfache Funktionen oder statische Methoden und sie beinhalten nur POC-Parameter und Rückgabewerte.

Für das iOS-Projekt muss das Outgabeformat in statische Bibliothek (.a-Datei) geändert werden, da iOS kein dynamisches Nachladen von Code erlaubt. Für Android sollte eine dynamische Bibliothek (.so) erstellt werden.

iOS-Einstellungen
Android-Einstellungen

Das Android-Projekt lässt sich komplett in Visual Studio kompilieren. Für iOS wird jedoch eine Verbindung zu einem Mac-Build-Agent benötigt. Dieser ist nicht der aus der normalen Xamarin.iOS-Installation sondern ein eigenes Microsoft-Tool, das unter OS X mit Hilfe von npm installiert wird. Visual Studio kommuniziert mit dem Tool über TCP/IP.

Verbindung zum Build Host

Um den nativen Code aufzurufen sollte ein Xamarin-Projekt für je iOS und Android erstellt werden. Die nativen Bibliotheken sollten in die Xamarin-Projekte eingefügt werden.

Das iOS lässt sich mit dem Plattform-Dropdown für unterschiedliche Prozessorarchitekturen kompilieren (um z.B. iPhones vor dem iPhone 5s zu unterstützen, oder auch den iOS-Simulator). Mit Hilfe des Tools lipo lassen sich die Bibliotheken für die unterschiedlichen Plattformen zu einer Bibliothek vereinen (siehe Xamarin-Dokumentation). Unter Android muss die .csproj-Datei von Hand angepasst werden, um die unterschiedlichen Plattformen anzugeben (siehe Xamarin-Dokumentation).

Die Aufrufe in den nativen sind normale P/Invoke-Aufrufe (obwohl DLLs hier nicht im Spiel sind). Unter Android muss der Name der Shared Library spezifiziert werden.

Unter iOS muss der Bibliotheksname __Internal angegeben werden, um einen Aufruf in die statisch Bibliothek zu machen.

Und das wars! Der Beispielcode liegt unter https://github.com/lothrop/XamarinNative. Im Beispiel habe ich den C#-Marshaling-Code in ein weiteres Shared Project gelegt, das jeweils vom Xamarin.iOS- und vom Xamarin.Android-Project eingebunden wird.