 Hallo zusammen! Ich freue mich, dass ihr alle hier seid, um meinen Vortrag über how to efficiently build native cross-platform-apps, that your users love, eine Einführung in Xamarin zu hören. Vorweg mal ein kurzes Stimmungsbild. Wer hat schon mal mobile Apps gebaut? Wahrscheinlich fast wieder. Okay, sehr cool. Kurz zu mir. Ich bin Tobi. Ich bin ein großer Hackathon-Fan und jetzt Xamarin Entwickler seit fast anderthalb Jahren. Das ist meine erste GPN und auch das erste Mal, dass ich auf so einem Event wie dem hier bin. Aber ich habe gedacht, ich bin so verrückt und halte jetzt auch gleich noch einen Vortrag über was, was ich cool finde. Kurze Inhaltsübersicht. Ich möchte kurz darüber reden, was es überhaupt native, also was zeichnet eine App aus, die man als native bezeichnen kann. Welche Ansätze gibt es hier schon in dem Bereich? Und wie sieht dann Xamarin native aus? Also wie funktioniert das? Außerdem will ich dann über die verschiedenen Code-Sharing-Methoden reden, die uns Xamarin bietet und dann eine Einführung in Xamarin Forms, das noch ein bisschen mehr uns erlaubt, schneller Apps zu bauen mit nativen Design. Und zuletzt will ich dann noch ein bisschen darüber reden, wie wir unsere Apps dann testen können mit Xamarin Test Cloud. Zunächst einmal also, was ist eine native App? Zu einer nativen App gehört natürlich einiges, aber es gibt im Wesentlichen drei Merkmale, die so eine App auszeichnen. Zum einen eine native Benutzeroberfläche, das heißt, wir verwenden native UI-Elemente, die uns das System zur Verfügung stellt, wie zum Beispiel der hier dargestellte Toggle-Switch von iOS oder eine Action-Bau auf Android. Als weiterer Punkt dann native API-Zugriff, das heißt wir haben Zugriff auf Sachen wie den Bluetooth-Sensor, auf Airplay zum Beispiel, also auf all diese Funktionalitäten, ohne dass wir uns irgendwie auf Plugins oder so, die wir in unserem Framework brauchen, verlassen müssen, sondern wir haben die wirklich in unsere, wir haben direkt darauf Zugriff, sobald sie auch vom Hersteller released werden. Und zu guter Letzt dann noch native Performance, das heißt, wir können das Maximale der Performance unserer App rausholen und müssen nicht aufgrund von irgendwelchen Flaschenhelden Performance-Rückschläge wahrnehmen. Native Apps sind sehr relevant. Als Beispiel habe ich hier zum Beispiel die Spotify-App jetzt mal mitgebracht. Die hatte bis vor Kurzem noch ein Hamburger-Menü auf iOS, also an der Seite so eine Liste mit verschiedenen Menüpunkten. Wir können jetzt sehen, dass Sie vor knapp zwei Wochen Ihre App geupdatet haben und wir jetzt unten so ein Tapper-Menü haben, was der nativen User-Interface auf iOS entspricht und eben das, was die Nutzer erwarten, wenn sie native Apps verwenden. Native Apps sind also vor allem auch im Consumer-Bereich wichtig. Deswegen sieht man das auch bei so Apps wie Spotify, im Enterprise-Bereich ist das nicht immer ganz so wichtig, da steht auf die Funktionalität im Vordergrund und die Form ist eher unwichtig. Wenn man jetzt überlegt, was für Ansätze gibt es hier eigentlich, um cross-platform native Apps zu haben, der ganz offensichtliche wäre, ich baue mir drei Apps auf iOS mit Objective C und Swift und als Entwicklungsgebung Xcode auf Android damit Java, Android Studio und auf Windows mit C Sharp und Visual Studio. Man sieht hier relativ schnell, dass das irgendwie uneffizient ist. Ich habe hier keinen geteilten Code, ich habe unterschiedliche Entwicklungsumgebung und ich brauche mehrere Entwicklerteams, die alle unterschiedliche Skills haben können. Und vor allen Dingen für Leute, die vielleicht irgendwie sehr kleine Entwicklerteams haben oder alleine Apps entwickeln wollen, ist das ineffizient. Außerdem gibt es dann auch diesen, der Vorteil ist natürlich, dass man am Ende echte native Apps hat. Dann gibt es diesen Write Ones Run Anywhere Ansatz. Hier baut man praktisch eine App mit JavaScript, HTML, CSS, packt die dann irgendeinen Container und kann die dann auch auf seine Geräte deployen. Hier hat man aber natürlich nur begrenzten API Zugriff, weil man sich irgendwie auf andere verlassen müssen, die das einem bereitstellen und manchmal auch Performance-Rückschläge sowie eine schlechte User Experience, weil man einfach UI-Elemente selber definiert, anstatt die zu verwenden, die einem das System gibt und mit dem die Nutzer vertraut sind. Vorteil bei dem Ansatz gerade eben ist natürlich, dass man den Code auf den verschiedenen Plattformen nur einmal, also für alle Plattformen nur einmal schreiben muss. Beide Ansätze haben ihre Vorteile, aber am besten wäre es eigentlich, wenn wir diese Vorteile kombinieren könnten. Und hier kommt jetzt der Xamarin-Ansatz ins Spiel. Was der uns erlaubt ist, dass wir eine geteilte C Sharp Codebase haben, indem wir unsere ganze Hinterkundlogik kapseln. Das heißt, so Sachen wie Server-Kommunikation oder Modelarbeit, das packen wir alles da rein und dann packen wir die View obendrauf in Form von iOS, Android und Windows Phone C Sharp Code für die UI. Xamarin erlaubt uns, dann 100% nativen API Zugriff zu haben. Im Detail sieht es dann so aus, dass wir sowohl Zugriff auf das gesamte.net Framework haben, wie hier dargestellt, und obendrauf natürlich auch Windows Phone oder UWP, die gesamte APIs, die uns dort auch normal zur Verfügung stehen. Auf iOS ist es auch der Fall. Auch hier haben wir Zugriff auf das gesamte.net Framework und zusätzlich die noch die nativen APIs wie UIKit, MapKit und viele weitere. Also alle, die wir als iOS-Entwickler schon kennen, sind auch hier verfügbar. Und genauso ist es auch bei Android, auch hier das.net Framework verfügbar und zusätzlich noch die bekannten UI-Lamente wie Actionbar und Core, außer dem Text-to-Speech, RenderScript und viele mehr. Also auch eben die Sachen, die wir schon kennen. Zusätzlich jetzt noch zur nativen Leistung. Die habe ich jetzt hier mal mitgebracht. Und zwar sehen wir, dass Xamarin iOS ahead of time Compilation macht und baut daraus dann IAM Binary. Also auf iOS müssen wir ahead of time Compilation machen, aber wir verwenden genau das, was auch iOS uns vorgibt, um so die maximale Leistung zu erzielen. Und mit Xamarin Android genau das gleiche. Hier verwenden wir den Just-in-Time-Compiler, um dann eben um die Android-App zu kompilieren und auch dort die maximale Leistung dann zu holen. Bindings werden natürlich dann gestrippt, Klassen, die wir nicht verwenden und so aus dem.net Framework werden alle rausgenommen. Wie entwickeln wir das Ganze dann? Also vielleicht Leute, die aus dem.net Bereich kommen, kennen Visual Studio ziemlich sicher und das können wir auch verwenden, um für Xamarin zu entwickeln. Außerdem gibt es dann noch Xamarin Studio, sowohl auf Mac als auch auf Windows und auch hier können wir dann Xamarin Apps entwickeln. Bei Visual Studio ist natürlich der Vorteil, dass wir hier die ganzen Plugins, die wir schon kennen, weiter verwenden können und uns damit manchmal vielleicht auch Arbeit erleichtern können. Außerdem gibt es für Xamarin dann Emulatorn, sowohl für Android auch als auf iOS, auf Windows und auf Mac OS X. Der iOS-Emulator für Windows von Xamarin wurde jetzt erst kürzlich vorgestellt und man kann dort seine Apps auch ausführen auf einem Windows-Rechner. Einzige Bedingung ist, wir brauchen so ein Remote-Bildhost und mit den müssen wir dann unsere Dateien an Mac schicken, dort wird es gebaut, kommt zurück in unseren Windows PC und da können wir das dann ausführen. Soweit so gut, wir haben also einen groben Überblick, wie der Ansatz funktioniert. Jetzt ist es natürlich auch noch unser Motto, dass wir alles teilen wollen auf dem Plattform. Wie machen wir das in einer sauberen Art und Weise? Wir verwenden dafür eine Portable Class Library. Bei der Portable Class Library wählen wir unsere Zielplattform aus und wir kriegen dann am Ende eine Schnittmenge von APIs, die uns zur Verfügung stehen. Man sieht jetzt hier exemplarisch ausgewählt Xamarin, iOS, Xamarin, Android und auch die Windows Store Applications und wir können dann unsere ganze Hintergrundlogik darin kapseln und am Ende das dann kompilieren und dann die DLL dazu verwenden, um sie in unserer App als Library zum Beispiel zu verwenden. Außerdem haben wir in Xamarin vollen Zugriff auf Nougat. Das heißt, die ganzen APIs, die andere schon für uns entwickelt haben und dort im Nougat Package Manager zur Verfügung stehen, die können wir auch einfach verwenden und auf allen Plattformen nutzen. So Sachen wie Lip Phone, Library von Google oder so, um Telefonnummern zu verifizieren. Ich habe jetzt viel über Code Sharing geredet. Wie sieht es aber in der Realität aus? Ich habe hier ein Beispiel mitgebracht von iCircuit. Das ist eine App mit der kann man elektronischer Schaltung planen und simulieren und man sieht jetzt hier, dass bis zu 90% des Anteils am Code geteilter Code sind und wir sehen auch, dass mindestens 70% des Codes geteilter Code sein können. Es ist also ein erheblicher Anteil an Arbeit, der uns hier erspart bleiben kann und eine effizientere Weise so eine App zu programmieren. Dann habe ich noch ein UI Beispiel mitgebracht. Hier sieht man jetzt auf der linken Seite die Android-App von so einer Notfall-App und hier ist ein Floating-Button und auf der rechten Seite ist jetzt von iOS und da ist eher so ein Flat-Design. Also man sieht hier, dass die UI nativ ist, aber wenn man jetzt genauer hinschauen würde, würde man herausfinden, dass der Hintergrundlogik von diesen beiden Apps oder von dieser einen App auf beiden Plattformen geteilt ist und nur der UI Aufwand einmal gemacht wurde pro Plattform. Das ist schön und gut, aber irgendwie sind wir noch fauler und deswegen brauchen wir Samurai-Forms. Und was uns Samurai-Forms erlaubt, ist, dass wir native Apps für iOS, Android und UWP mit einer einzigen geteilten C-Sharp-Codebase bauen können. Zum Vergleich nochmal der traditionelle Ansatz, geteilte Codebase, drei UIs, die ich selber schreiben muss. Und jetzt der Samurai-Forms-Ansatz. Hier habe ich eine geteilte C-Sharp-Codebase, in dem meine Hintergrundlogik ist und dann nochmal geteilten UI-Code für alle Plattformen. Was kann ich mit diesem UI-Code alles machen? Im Prinzip sind hier verschiedene Funktionalitäten gegeben, die ich jetzt alle vorstellen will. Und zwar haben wir über 40 verschiedene Pages, Layouts und Controls, die mir Samrent zur Verfügung stellt. Außerdem verschiedene Navigations, also verschiedene Navigationsabläufe innerhalb meiner App. Dann eine Animations-API, das ist natürlich sehr grundlegend. Das heißt, ich kann Sachen bewegen, ich kann Sachen größer und kleiner machen, aber nicht jetzt irgendwie ganz verrückte Sachen. Dann habe ich ein Dependency-Service. Was das mir erlaubt, ist, dass ich Interfaces definieren kann und dann pro Plattform, die jeweils implementiere. Und der Samrent-Compiler weiß dann, okay, ich muss jetzt die entsprechende Implementierung nehmen für die konkrete Plattform. Außerdem habe ich sowas, das heißt Data-Pages, das wurde jetzt gerade auf Samrent Evolve vorgestellt vor Kurzem mit praktisch 10 Zeilen Code, eine direkte Anbindung an seine Datenbank zu machen und daraus tabellarische Datendatendastellungen zu generieren. Also es nimmt einem Arbeit ab, wenn man so Tabellen ganz einfacher machen will. Und außerdem gibt es noch Themes. Mit diesen Themes kann ich meine App dann einfärben, zum Beispiel, wenn ich jetzt irgendwie ein dunkleres Layout haben will, dann binde ich das einfach ein und meine App hat dann eine andere Farbe insgesamt. Wie funktioniert es mit der nativen UI ausgeteilt im Code? Wer von Windows Phone kommt, kennt das, dass man Sammel verwendet oder ist scharf, um die UI zu definieren und genauso ist es auch bei Samrent Forms. Also ich habe hier auf der rechten Seite mal so ein Code Snippet rausgeholt. Man sieht da, dass es so verschachtelt und relativ logisch aufgebaut und man kann dann den UI Code definieren. Und Samrent Forms kümmert sich dann darum, das in der nativen UI zu übersetzen. Hier habe ich jetzt auch noch mal die verschiedenen Pages und Layouts aufgelistet. Also es gibt sowohl Content, Master Detail, Navigation Tab und Carousel View. Ich habe auch eine App dabei, eine Demo App dabei, auf der ich das gleich nochmal zeigen werde. Und es gibt verschiedene Layouts, also Stake Layouts, absolutes Layouts, die Sachen, die man eben kennt von den verschiedenen Plattformen, aber die man normalerweise, wenn man Apps schreibt, dreimal einzeln implementieren muss und nicht wie bei Samrent Forms, jetzt einmal verwenden muss und dann auf alle einfach deployen kann, auf alle Plattformen. Ja, von Labels bis hin zu Tabellen. Das Label von Samrent Forms wird dann halt entsprechend auf iOS, auf den UI Text Field übersetzt oder auf die entsprechenden Labelklassen der einzelnen Plattform. Ja, jetzt eine kurze Demo von der App, von der ich gerade eben geredet habe. Und zwar, genau, die App heißt Forms Gallery, die kann auch jeder der Interesse daran hat auf der Samrent Website runterladen und auf sein Gerät deployen. Die App, die ich jetzt hier habe, ist eine Samrent Forms App. Das heißt, wir haben die einmal geschrieben und ich könnte die jetzt genauso auf Android deployen und die würde dann nativ aussehen, aber genau die gleichen Funktionalitäten haben. Also erstmal sowas grundlegend. Das hier sieht man so ein Label, das einfach nur Text darstellt. Das ist jetzt nicht so ein Hexenwerk. Wir sehen dann aber auch so Sachen wie Maps, was ganz cool ist. Ich binde einfach ein MapView ein und der wird dann entsprechend auf Google zu dem passenden MapView am Ende gerendert und auf iOS genauso aktive Maps, die mir hier angezeigt werden. Dann gibt es eben auch so verschiedene Controls wie Stepper und so weiter. Und auch hier noch die verschiedene Zellen für Tabellen und Co. Und außerdem hier noch die verschiedenen Layouts. Mein Lieblingslayout, das ist absolut layout, weil hier noch so eine coole Animation dabei ist. Da sieht man eben auch, dass eine AnimationsAPI in Samrent mit enthalten ist und man da auch so kleine Sachen animieren kann. So viel also zu der UI. Wir sehen jetzt aber, wenn wir darüber nachdenken, was so eine App eigentlich alles hat, die auf einem Gerät läuft, das dann noch viel mehr dazu gehört. Der gehört Zugriff auf die GPS-Sensor dazu, der gehört Zugriff auf irgendwelche Einstellungen oder auf Text-to-Speech-Funktion dazu. Auch die müssen wir irgendwie durch eine Schnittstelle ansprechen können. Wir haben hier eine Dependency Services geredet, mit dem wir das praktisch selber implementieren können. Es gibt dann aber auch andere Implementierungen, die uns Samrent schon bereitstellt. Ein Beispiel hierfür ist zum Beispiel der Samrent Geolocator. Was der uns erlaubt, ist das einfach eine einheitliche Schnittstelle zum Zugriff auf den CLL Location Manager von iOS, Location Manager von Android und den Geolocator von Windows Phone bietet. Und wir können den dann einfach verwenden, um über eine einheitliche Schnittstelle unseren Hintergrundcode zu schreiben. Die Frage ist jetzt natürlich, wer macht so was? Das machen Trittentwickler in Form von Components. Und es gibt dann Components Store in Samrent Studio, in den kann man gehen. Und es gibt davon Schnittstellen zu Amazon Web Services bis hin zu irgendwelchen UI-Libraries, wie zum Beispiel Setsync, mit dem man dann mit einer Zeile praktisch QR Code Scanner in seiner App haben kann. Ist dann also ein kroner Aufruf, ich erwarte den, kriege eine Antwort zurück, aber wirklich cross-platform diese Komponenten verwenden kann, ohne selber viel Aufwand zu haben. Ein Teil dieser Komponent oder der Großteil dieser Komponenten ist kostenlos. Es ist aber so, dass es auch kostenpflichtige Komponenten gibt, aber das ja, manche Leute wollen immer Geld verdienen. Dann, was ist der richtige Samrent-Ansatz für deine App? Ist es so, wenn die App wirklich nur einfach ist und keine highly sophisticated UI haben soll, nicht mega ausgereift und so, dann ist Samrent Forms genau das Richtige. Damit können wir einfache UIs bauen, die Daten irgendwie darstellen sollen, aber es ist nicht geeignet, wenn man diese Consumer-Apps, von denen ich geredet habe, bauen will. Ein gutes Beispiel aber für eine richtig tolle Samrent-App, die mit Forms gemacht wurde, ist die Samrent Evolve-App von der Konferenz dieses Jahr und wenn man die Möglichkeit hat, die vielleicht auch zwei verschiedenen Geräten runterzuladen, was Samrent da eigentlich für eine Magie macht und wie das am Ende dann aussieht. Der Samrent iOS und Samrent Android-Ansatz hingegen ist wirklich für Apps, die 100% slicker UI haben soll, wo das Design im Vordergrund steht und wo ich auch viele native API-Zugriffe habe. Für die Leute ist der Samrent iOS und Samrent Android-Ansatz gut geeignet. Wir haben jetzt also eine Idee davon bekommen, wie wir eine App mit Samrent bauen können. Ich habe das extra ein bisschen High-Level gehalten, weil ich dachte, so als Einführung sollte das lang. Es geht jetzt aber dann nach dem Bau und auch irgendwann ans Testen. Wir müssen sicherstellen, dass unsere App auf allen Geräten gut funktioniert. Und das Problem, das sich uns hier offenbart ist, dass wir viele, viele, viele verschiedene Geräte haben. Also wir haben sowohl auf iOS, aber besonders auf Android eine große Fragmentierung von Displaygrößen, von verschiedenen OS-Versionen und so weiter. Und jetzt kommt Samrent Test Cloud ins Spiel. Was wir mit Samrent Test Cloud machen können, ist, wir schreiben auf unserem Rechner UI-Tests und die können wir dann in Samrent Test Cloud hochladen. Und Samrent hat bei sich dann physikalisch Geräte liegen, auf die unsere App deployt wird. Also die garantieren auch, dass die platt gemacht sind. Wir müssen uns keine Sorgen machen, dass da irgendwelche anderen Apps auch noch rumschummeln und unser Zeug irgendwie mitlesen. Wir können auch noch ein bisschen automatisiert berichten, können sogar Aufnahmen darüber machen. Und was jetzt ganz neu ist, wir können sogar den Debugger attachen mit Visual Studio und dann über die Cloud auf jedem beliebigen Smartphone debuggen. Und das finde ich ziemlich cool. Wenn es jetzt darum geht, UI-Tests zu schreiben, dann sagt jeder Ohne, da habe ich keinen Bock drauf. Aber dann sagt Samrent, okay, wir haben den Samrent Test Recorder. Was der Samrent Test Recorder macht, also ein paar Schritte. Und am Ende haben wir dann ein Testfall, den wir einfach in Samrent Testlaut hochladen können. Und dort wird er dann automatisiert ausgeführt auf den verschiedenen Geräten. Und wir erhalten auch da wieder Berichte dann. Das Beste zum Schluss. Samrent ist kostenlos. Das heißt, wenn ihr jetzt Lust habt, das zu verwenden, könnt ihr das jetzt tun. Das ist erst seit kurzem so. Davor war es nur für Studenten kostenlos. Jetzt ist es für jeden kostenlos. Und ich finde es cool, wenn ich ein paar von euch auch begeistert habe. Ich möchte mich für eure Aufmerksamkeit bedanken. Und wenn ihr jetzt noch Fragen habt, dann stehe ich dazu gerne zur Verfügung. Oder ihr könnt danach auch noch zu mir kommen. Ja? Sie sieht es dann aus, wenn wir das ausgefahren haben, jetzt nicht nur auf mobile Weisen zu verstehen, sondern auch, ich will einen gleichen Grund für den, den wir in letzter Zeit haben. Und für es gibt Leute, die sagen, Samrent ist Multi-Plattform, nicht Cross-Plattform. Also es ist für mobile gedacht. Was wir natürlich haben, ist, dass es für web, ASP.net gibt, wo wir das C-Sharp-Code verwenden können im Hintergrund. Aber es ist in erster Linie für mobile gedacht. Ja? Genau. Also das Ding ist, Samrent selber kümmert sich eigentlich nur um iOS und Android. Und was sie einem dann sagen, ist, okay, das ist eh schon alles in C-Sharp, was du jetzt machst auf iOS und Android. Und im Endeffekt haben sie gewisse Design-Patterns, die sie empfehlen. Und genau die kann man auch auf iOS und Android. Und die kann man auch auf iOS und Android. Und die kann man auch auf iOS und Android. Genau. Das Ding ist, Samrent selber kümmert sich eigentlich nur um Internetans, die sie empfehlen. Und genau die kann man auch auf Windows verwenden. Also es ist nicht unüblich. Oder es ist komplett normal, dass man dann so eine Universal-Windows-Platform-App hat. Wo man im Hintergrund eben die Logik verwendet, die man auch auf seinem iOS und Android-System verwendet. Also man kann dann durchaus Desktop-Apps machen, aber eben nur für Windows und dann diese UWP-Apps. Ja? Ja. Also es gibt ganz kleinere Restriktionen. Das ist auf iOS, weil da können wir keine Kompilierung zur Laufzeit machen mit allen Geräten. Also was Samrent macht, es packt eine Mono-Runtime mit auf das Gerät drauf und in der wird der ganze C-Sharpcode dann mit ausgeführt. Und deshalb können wir wirklich 100% vollwertige native Apps bauen. Also wir haben Zugriff auf wirklich jede einzelne API und was man vielleicht auch noch betonen muss, ist, dass Samrent mit iOS zum Beispiel, nach der WWDC, sobald die SDKs verfügbar sind, haben sie Day One Support. Also keiner weiß genau, wie es funktioniert, aber sie machen es. Das ist natürlich. Aber man hat Zugriff auf alle nativen APIs, die einem zur Verfügung stehen. Ja? Du sagst, es geht alle Samrent, die Mono-Runtime mit in die App. Die hat es eigentlich damals so verstanden. Der Mono-Kompilier, der Samrent in die Oma, tut das in die nativischen Sprache übersetzen. Also bei iOS, das ist das Objekt, das siebt, wie schonfalls bei der Apple-Sharp, dann kommt der und kommt dann mit, der ist nicht mehr geistig und muss jetzt nachschauen. Da können wir auch noch mal darüber reden. Ja, ich bin mir auch nicht ganz sicher. Dankeschön. Bitte. Aber auch ganz der Land lang, wenn die da drin ist, muss der denn die App sein? Also, der Overhead ist ziemlich klein. Eine Android-App, die man baut, hat vielleicht zwei, drei Megabyte mehr, aber es ist vertretbar. Aufwand. Es gibt da einen guten Artikel zur auf medium.com, aber sie wird nicht spürbar langsam, es sind ganz kleine Nürnersen. Also vielleicht bin ich auch ein bisschen biased, aber ich spürs nicht, wenn ich die Apps entwickelt und aufmache. Also später, ich habe auch ein paar Samen Apps auf dem Handy, können wir einfach mal anschauen. Okay, cool. Wenn es noch Fragen gibt, freue ich mich, wenn ihr nach vorne kommt und die mir stellt. Ansonsten vielen Dank. Bis dann.