heise.de: Microsoft Build 2016: Xamarin wird Teil von Visual Studio und Open Source

[bra]

Zitat:

Zitat von Darlo (Beitrag 1334571)

Mit FMX kann man aber ebenso native Komponenten nutzen. Ich nutze iCL von TMS. Je nach Anforderung ist man doch super flexibel mit Firemonkey. iOS-GUI native, Windows, OS X und Android mit Firemonkey.

Dann kann man aber auch mit Xamarin die GUI für unterschiedliche Geräte bauen. Wo ist dann bitte noch der Vorteil von FMX? :roll:

Ein großes Problem der FMX-Geschichte ist die Geschwindigkeit. Ich habe in unserer App einen Einstellungsdialog mit ListBoxes und diversen Schaltern gebaut, der ist je nach Gerät quälend langsam. Obwohl das mit den XE-Versionen immer besser geworden ist.

Und oft sind es auch Kleinigkeiten, die einem als Entwickler (und Nicht-Nutzer des Systems) gar nicht so auffallen, dem Kunden aber schon, wenn sich ein Memo z.B. anders verhält als bei Eingabefeldern in anderen Apps.

[Darlo]

Zitat:

Zitat von bra (Beitrag 1334573)

Dann kann man aber auch mit Xamarin die GUI für unterschiedliche Geräte bauen. Wo ist dann bitte noch der Vorteil von FMX? :roll:

Äh, Delphi ;-)

Zitat:

Zitat von bra (Beitrag 1334573)

Und oft sind es auch Kleinigkeiten, die einem als Entwickler (und Nicht-Nutzer des Systems) gar nicht so auffallen, dem Kunden aber schon, wenn sich ein Memo z.B. anders verhält als bei Eingabefeldern in anderen Apps.

Dafür gibt es ja die nativen Komponenten. Wir zeigen unseren Kunden die GUI von Firemonkey und die native anhand eines kleines Testprogramms. Diese können die Kunden gerne paar Tage lang testen und bewerten ob sie liebe unter Android und iOS exakt das selbe Programm haben möchten und dafür auf bissen native verzichten . Oder eben zumindest für iOS eine native Oberfläche haben möchten (verursacht halt mehr PTs).

[joachimd]

Ich habe am Wochenende eine Win8.1 VM mit VS2015 und Xamarin aufgesetzt ... und der erste Eindruck ist verblüffend. Wo ich in RadStudio immer gescheitert bin, konnte ich nach kurzer Recherche mit VS schon Erfolge erzielen: Der Android Emulator läuft in der VM. Ich habe mit RadStudio seit ca 1 Jahr nicht mehr in diese Richtung probiert, aber ich bezweifle, dass es dort inzwischen geht.

[Bambini]

Zitat:

Zitat von joachimd (Beitrag 1334594)

Der Android Emulator läuft in der VM. Ich habe mit RadStudio seit ca 1 Jahr nicht mehr in diese Richtung probiert, aber ich bezweifle, dass es dort inzwischen geht.

Delphi erzeugt - immer noch - nur Code für ARM CPU.
Der Android mit ARM Emulator ist selbst auf modernsten CPU nicht nutzbar.
Ich vermute Xamarin erzeugt auch X86 Code und nutzt seine Vorteile ...

[vagtler]

Zitat:

Zitat von joachimd (Beitrag 1334594)

Ich habe am Wochenende eine Win8.1 VM mit VS2015 und Xamarin aufgesetzt ... und der erste Eindruck ist verblüffend. [...]

Schön, dass mal jemand unvoreingenommen ohne Scheuklappen an die Sache herangeht.

[MEissing]

Zitat:

Zitat von joachimd (Beitrag 1334594)

Der Android Emulator läuft in der VM. Ich habe mit RadStudio seit ca 1 Jahr nicht mehr in diese Richtung probiert, aber ich bezweifle, dass es dort inzwischen geht.

*Den* Android Emulator gibt es nicht.

Hier läuft zB BlueStacks in der VM:

Anhang 45064

[joachimd]

Zitat:

Zitat von MEissing (Beitrag 1334613)

*Den* Android Emulator gibt es nicht.

Hast schon recht...aber wenn ich ein umfangreiches Softwarepaket installiere, dann möchte ich nicht noch an zig Stellschrauben rumdrehen oder zusätzliche Software suchen, nur damit ein Hello World auf den Schirm kommt. Ich erwarte sowas eigentlich - und virtuelle Maschinen sind heutzutage eigentlich eher Standard als Ausnahme. Gerechterweise muss man sagen, dass dies bei VS2015/Xamarin auch nicht out-of-the-box lief. Eine Google-Suche mit der Fehlermeldung lieferte aber sofort die Lösung (Config ändern) wobei mein Nachfragen in der RadStudio Welt (unter anderem auch bei Dir) eben nix brachte.

[MEissing]

Zitat:

Zitat von joachimd (Beitrag 1334614)

und virtuelle Maschinen sind heutzutage eigentlich eher Standard als Ausnahme.

Ernsthafte Android Entwicklung findet auf dem Gerät statt.... und zwar ausschließlich da. </IMHO>

[vagtler]

Zitat:

Zitat von MEissing (Beitrag 1334615)

[...] Ernsthafte Android Entwicklung findet auf dem Gerät statt.... und zwar ausschließlich da. </IMHO>

Na, Entwicklung und Test sind und bleiben immer noch zwei verschiedene Paar Schuhe.

[Bambini]

Zitat:

Zitat von MEissing (Beitrag 1334615)

Zitat:

Zitat von joachimd (Beitrag 1334614)

und virtuelle Maschinen sind heutzutage eigentlich eher Standard als Ausnahme.

Ernsthafte Android Entwicklung findet auf dem Gerät statt.... und zwar ausschließlich da. </IMHO>

Das Android Gerät in einer VM bzw. per Remote Desktop zu nutzen ist eine ganz besondere Aufgabe:!:

[Stevie]

Benutzt Xamarin für iOS oder Android eigentlich ein anderes Memory Management anstatt des GC? :stupid:

[mkinzler]

Unter Android GC und iOs wohl ARC.

[himitsu]

Zitat:

Zitat von MEissing (Beitrag 1334613)

*Den* Android Emulator gibt es nicht.

Hier läuft zB BlueStacks in der VM:

Anhang 45064

AndyOS "emuliert" einen x86 ... macht BlueStacks das nicht auch oder emuliert der wirklich einen ARM?
Ansonsten laufen die Beiden bei mir eigentlich recht flott (wenn der RAM reicht).
Memu ist auch schnell (und wie die Clone davon alle heißen)

Aber OK, wenn man schon gezwungen wird einen Mac zu kaufen, warum dann nicht auch noch 'nen iOS-Teil und 'ne iWatch und das iRack.

[mkinzler]

x86 wird nicht emuliert, sondern es handelt sich um ein x86-Android. Emuliert wird nur u.U. nur ARM.

[mm1256]

Hallo,

ist ein (kleines) bischen OT, aber auch ein Indiz dafür, wie intensiv M$ derzeit an die Open-Source-Gemeinde herangeht. Dieser Newsletter ist gerade herein gekommen: CRN News

[mkinzler]

Und für die Abkehr von Oracle ...

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1334621)

Unter Android GC und iOs wohl ARC.

Ja, die nativen Objekte, mit denen gearbeitet wird, aber in meinem C# Code herrscht nicht plötzlich ARC statt GC.

[mm1256]

Zitat:

Zitat von mkinzler (Beitrag 1334629)

Und für die Abkehr von Oracle ...

... und dafür, dass die Delphi-Konkurrenz nicht schläft. Darauf wollte ich hinaus. Delphi hilft es nichts oder nicht viel, wenn sich jemand von Oracle abwendet. Aber wenn M$ neues Holz in das Open-Source-Feuer legt, dann gibt das Zunder - für alle!

[Zacherl]

Zitat:

Zitat von Stevie (Beitrag 1334630)

Zitat:

Zitat von mkinzler (Beitrag 1334621)

Unter Android GC und iOs wohl ARC.

Ja, die nativen Objekte, mit denen gearbeitet wird, aber in meinem C# Code herrscht nicht plötzlich ARC statt GC.

Habe ich die Xamarin FAQs falsch verstanden? Dort ist nämlich unter anderem dieser Auszug zu finden:

Zitat:

[..]your Xamarin app is compiled to a native binary, not interpreted[..]

Oder ist damit nur eine Art JIT-Compiling des C# Codes gemeint?

Nvm: Unter iOS wird wohl "Mono" verwendet, also am Ende doch kein natives Kompilat.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1334625)

x86 wird nicht emuliert, sondern es handelt sich um ein x86-Android. Emuliert wird nur u.U. nur ARM.

Deswegen ja "emuliert" und nicht emuliert, weil das Ding sich ja dennoch Emulator schimpft. :stupid:

[Bambini]

Zitat:

Zitat von Darlo (Beitrag 1334571)

Mit FMX kann man aber ebenso native Komponenten nutzen. Ich nutze iCL von TMS. Je nach Anforderung ist man doch super flexibel mit Firemonkey. iOS-GUI native, Windows, OS X und Android mit Firemonkey.

Ich versuchte vor einiger Zeit die mCL für MacOS. Da gab es massive Probleme mit dem Zeichen und beim Mischen von FMX mit den native MacOS Controls,
wie z.B. beim Zeichnen von NSPopover oder was machen wenn es keinen native Splitter gibt u.v.m.

[Rollo62]

@Sir Rufo

Zitat:

Die Styles findet man auch bei WPF - also kein Alleinstellungsmerkmal von FMX

Ok, ich habe mich mit WPF noch nicht so intensiv auseinandergesetzt, aber kann ja sein das M$ das sehr weit fortgetrieben hat.

Was ich meinte bei den Styles war generell die Möglichkeit mit primitiven Vektor-Objekten zu arbeiten, sowohl für UI-Designer als
auch direkt als Komponenten im Code zur Laufzeit.
Hat das WPF genauso gelöst, werden da auch Vektorprimitive als Komponenten erzeugt ?
Weil ich finde das dies einen gewissen Charme hat, und das damit viele UI plattformunabhängig leicht abgebildet werden könnten.

Ja, das ist dann wohl ein Nachbau der nativen OS'se, aber warum nicht ?
Ich brauche ja meist nur rudimentärste Controls (Edit, Button, Memo, ListView, etc.) und die kann man doch den nativen 100% relativ leicht nachbauen.
Die Abstraktion von Messaging, Controls, Canvas ist doch vom Konzept her ganz gut umgesetzt, nur leider noch mit ein paar Fehlern.
Das Problem damit ist eher wie weiter unten beschrieben, das es nur eine 80/20 Lösung ist, also das zwar viel vorhanden ist aber nicht
Alles exakt so funktioniert wie im Original OS.

Aber wenn WPF dasselbe Vektor-Styles Konzept haben sollte, dann ist das natürlich kein Argument mehr.
Meine info dazu war halt nur das Xamarin doch nicht alles so simpel kapselt, im Gegenteil.
Aber kann sein das ich mich doch mal wieder mit Xamarin beschäftigen muss.

Trotzdem sehe ichnoch die Vorteile von Delphi:
- Konzept und Sprache ist bekannt und es ist, finde ich persönlich, recht elegant ins 21. Jahrhundert überführt (theoretisch)
- hat sehr hohe Kontinuität, wo in dem gleichen Zeitraum die M$-ler mehrere Säue durchs Dorf getrieben haben und oft alles neu umstellen mussten
- das Konzept ist meine ich auch zukunftssicher, wenn man endlich Kompatibilität herstellt (meinetwegen nur bei 20% BasisControls die man braucht)

Deswegen bin ich bei Delphi, aber wenn M$ jetzt ernsthaft auf OpenSource geht und nicht die Entwickler mit jährlichen neuen Vorgaben quält dann werden
diese Argumente weniger Wert.
M$ muss das aber erst noch beweisen.

Wie steht es eigentlich damit das Delphi ein nativer Compiler ist, und keine IML wie C# ?
Ich denke immer daran das Delhi auch endlich die Stärke von CppBuilder rausstellen sollte, um wirklich nativen Code zu Erzeugen.
Ja auch da ist C# mit allen Tricks und Kniffen weit vorne, aber ist native kompilierter Code nicht immer ein Vorteil ?
Oder kann das M$ Visual mittlerweile auch ?


Rollo

[Bambini]

Zitat:

Zitat von Rollo62 (Beitrag 1334875)

Wie steht es eigentlich damit das Delphi ein nativer Compiler ist, und keine IML wie C# ?
Ich denke immer daran das Delhi auch endlich die Stärke von CppBuilder rausstellen sollte, um wirklich nativen Code zu Erzeugen.
Ja auch da ist C# mit allen Tricks und Kniffen weit vorne, aber ist native kompilierter Code nicht immer ein Vorteil ?
Oder kann das M$ Visual mittlerweile auch ?

Kommt auch:
https://entwickler.de/online/windows...rm-191899.html

[Zacherl]

Zitat:

Zitat von Rollo62 (Beitrag 1334875)

Wie steht es eigentlich damit das Delphi ein nativer Compiler ist, und keine IML wie C# ?

Prinzipiell auf jeden Fall von Vorteil und definitiv auch meine Präferenz. Realistisch betrachtet, merkt man von der Performance her allerdings absolut keinen spürbaren Unterschied mehr zwischen nativen Anwendungen und modernen .NET Binaries.

Unter iOS wird bei Xamarin wohl sogar die AOT Kompilierung von Mono eingesetzt. Hierbei werden sämtliche möglichen Codepfade schon vorab kompiliert und nicht erst bei der ersten Ausführung eines bestimmten Branches (wie es bei JITting der Fall ist). Die Performance wird also nochmal näher an den nativen Code ranreichen.

[mkinzler]

Unter Android ( dank ART) ist AOT auch Standard (seit Android 5).

[Elvis]

Zitat:

Zitat von Zacherl (Beitrag 1334880)

Unter iOS wird bei Xamarin wohl sogar die AOT Kompilierung von Mono eingesetzt.

Muss auch, eines der Sicherheits-Features von iOS ist, dass ein Prozess einen beschreibbaren Speicherbereich nicht ausführbar machen kann. (Also kein JITting)
Nur Safari darf das für JavaScript.
OTOH, AOT-Kompilation macht für die Art, wie man Apps auf einem Mobilgerät benutzt, wesentlich mehr Sinn. Wer will schon auf den lahmen ARM warten bis er genügend Code kompostiert hat, damit man endlich etwas sieht?

Interessant wird es werden, wie sich das mit den Preisen pro Plattform weiterentwickelt. Dauerhaft kostenlos kann Sinn machen, solange man für ein MSDN bezahlt oder ein VS Professional besitzt. (Oder klein genug ist, um die Community nehmen zu dürfen)

[BugTrapper]

Jemand fragte, ob Xamarin Studio für den Mac erhalten bleibt, dazu gibt es einen Blog-Eintrag, in dem
einiges erkärt wird:

http://pumpingco.de/xamarin-free-for...mc_id=DX_59375

Ich fürchte allerdings auch, dass es mächtig Konkurrenz für Idera/Embarcadero geben wird nach der kostenlosen Veröffentlichung von Xamarin.
Z. B. wird es auch sehr schnell weitere Anleitungen, Kurse und Anleitungsvideos geben.
Und die RAD-Studio-Versionen sind sehr sehr teuer, kann ich mir ja kaum privat leisten, und schrecken bestimmt viele Schüler/Studenten, ehm, Rentner :-) ab.

Ausserdem kann man mit Xamarin auch noch Windows Apps für den Windows Store proggen. Ich glaube, dass Win10 auf Lumia Handys nochmal richtig interessant werden kann, wenn man
z. B. über ne Docking Station und externes Keyboard und Bildschirm ein vollständiges Win10, nicht nur die mobile Umgebung, laufenlassen kann. Ausserdem sind die Lumia-Handys extrem günstig gegenüber anderen Betriebssystem-Handys. Microsoft und Windows kommen zurück, und auch die Handys, meine Meinung.

M. Külshammer

[Der schöne Günther]

Ich bin auch fanatischer Windows Mobile (Lumia)-Fan, aber so realistisch einzusehen dass es für mindestens die nächsten 12 Monate weiterhin ein absolutes Randgruppen-OS bleiben wird :oops:

Continuum ist eine tolle Sache, aber irgendwie ähnlich den Elektro-Tankstellen. So lange nicht genügend Infrastruktur da ist wird das ganze noch uninteressant bleiben...

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1337388)

Ich bin auch fanatischer Windows Mobile (Lumia)-Fan, aber so realistisch einzusehen dass es für mindestens die nächsten 12 Monate weiterhin ein absolutes Randgruppen-OS bleiben wird :oops:

Continuum ist eine tolle Sache, aber irgendwie ähnlich den Elektro-Tankstellen. So lange nicht genügend Infrastruktur da ist wird das ganze noch uninteressant bleiben...

Microsoft kann ja mal bei der deutschen Regierung nachfragen, ob Windows Mobile Phones nicht subventioniert werden können :stupid:

[Darlo]

Zitat:

Zitat von Stevie (Beitrag 1337389)

Microsoft kann ja mal bei der deutschen Regierung nachfragen, ob Windows Mobile Phones nicht subventioniert werden können :stupid:

Da ist das Buget von MS sicher größer ��. Ich halte Windows mobil übrigens für unterschätz und sehe enormes Potential.

[Bambini]

Zitat:

Zitat von Darlo (Beitrag 1337402)

Zitat:

Zitat von Stevie (Beitrag 1337389)

Microsoft kann ja mal bei der deutschen Regierung nachfragen, ob Windows Mobile Phones nicht subventioniert werden können :stupid:

Da ist das Buget von MS sicher größer ��.

Sicher? Der Gewinn der 3 deutschen Automobilhersteller lag 2014 bei ca. 32 Mrd. EUR
http://de.statista.com/statistik/dat...bilhersteller/
Also ein Existenz bedrohender Zustand der ohne Subventionen nicht mehr leben kann :wink: