Hinweis: Alles Wichtige zum Xamarin Developer Summit 2019

Kurz notiert: Auch wenn die nächste große Konferenz mit der Microsoft Inspire, die in wenigen Tagen beginnt, für uns Consumer und einfachen Entwickler keine große Relevanz hat, gibt es zumindest für die mobilen .NET-Entwickler heute und morgen ordentlich Nachschub. In...

Klicke hier, um den Artikel zu lesen

Danke! Ich finde Xamarin ist eine echt feine Sache. Ich programmiere eigentlich fast nur noch auf Xamarin-Basis.

Welche verbreiteten Androidprogramme sind mit dem Framework gebaut?

Als User bevorzuge ich natürlich native Programme.

Was ist für dich "nativ"? Ohne Runtime wie .NET oder Java? Ich dachte die Xamarin-GUI geht doch genau wieder auf die vom OS bereitgestellten Controls der jeweiligen Plattform, keine Paintbox oder so etwas...

ntoskrnl schrieb:

Welche verbreiteten Androidprogramme sind mit dem Framework gebaut?

Als User bevorzuge ich natürlich native Programme.

Zum Vergrößern anklicken....

Wenn es dir um native Umsetzungen geht, ist das schlicht und ergreifend Banane. Hybride Entwicklung ist zwar auf dem Vormarsch, aber der Sinn von dieser ist gerade, dass du deine eigene Sprache vorne reinschickst und hinten kommen dann in den meisten Fällen Java-Code für Android und Objective-C-Code für iOS raus. Das kann C# bei Xamarin sein, Dart bei Flutter, JavaScript bei React Native, Ionic oder NativeScript, C++ bei Qt oder andere Umsetzungen zum Beispiel mit Pascal, die es auch noch gibt.

Was man bei Xamarin eher hinterfragen kann, ist, ob es jeweils noch das richtige Target hat oder ob Microsoft schon auf die neueren Programmiersprachen (Swift bei iOS, Kotlin bei Android) wechselt. Davon habe ich bisher nichts gelesen.

"Native" ist bei Android der Java-VM Code (und C/C++ für nicht GUI-Teile).

der Sinn von dieser ist gerade, dass du deine eigene Sprache vorne reinschickst und hinten kommen dann in den meisten Fällen Java-Code für Android ... raus ...

Zum Vergrößern anklicken....

Schon. Aber die Methoden des OS werden nicht direkt aufgerufen, sondern über Zwischenschichten/Bibliotheken. Die brauchen Platz/Zeit/Performance/Speicher. Manchmal mehr, manchmal weniger. Die direkte Nutzung der OS Interfaces ist immer die performantere Lösung.

Da wird kein C# nach Java-Bytecode oder gar Objective-C gewandelt.
Die Apps enthalten einfach eine zusaetzliche Runtime und die Libraries mappen auch zusaetzlich C# Objekte auf die nativen Objekte. Jenachdem wie "schlau" das gemacht ist kostet das weniger oder mehr CPU&RAM.
Kleiner Trost: insofern besteht da gar kein Unterschied zur Situation auf Windows - in Windows selbst gibts auch keine nativen C# Objekte...
Vielleicht gibts das dann mit Windows Lite.

Zu ergänzen wäre noch, dass bei iOS sowieso auf nativ kompiliert wird, weil iOS keine Runtime mit just-in-time Compilation erlaubt.
Bei Android kann man auch in nativen Code kompilieren (das ist nach ARM-Instruktionen usw., nicht nach Java), allerdings hat man für diese Form der Ahead-of-Time Compilation zumindest bei Visual Studio 2017 immer die Enterprise Edition benötigt. (Und dann stimmt es auch wieder mit der Performance grad beim App-Start.)

Es waere mal schoen wenn jemand die verschiedenen Moeglichkeiten Apps zu erstellen fuer Android/iOS/Mac/Windows/Linux im Hinblick auf Performance/RAM/Stromverbrauch testen koennte.
Insbesondere der Hybride-Ansatz einfach eine App mit WebView fuer HTML/CSS/JavaScript zu machen interessiert mich da: was wird da "liegengelassen" im Vergleich zu einer nativen Loesung?
-
Es wird zwar fleissig diskutiert was z.B. BitCoin an Strom verbraucht - aber wie siehts bei den SmartPhones und Computern aus wenn die billigen Code laufen lassen? Und das x-Millionenfach? Denn hinter dem Hybriden-Ansatz steckt im Endeffekt vor allem der Gedanke Entwicklungskosten einzusparen....