Firemonkey vs. Xamarin

[lowmax_5]

Hallo,

ich wollte mal Eure Meinung zum Vergleich Firemonkey versus Xamarin hören, wobei bei Letzterem nun auch die Multiplattform-Entwicklung mit dem VisualStudio möglich ist. Habt Ihr dazu schon Erfahrungen sammeln können? Wo liegen die stärken/schwächen? Ist dieses überhaupt eine ernsthafte Konkurrenz zu FM? Freue mich über eine rege Diskussion!

[Phoenix]

Xamarin ist um einiges älter als Firemonkey und hat sich als Cross-Plattform-Entwicklungsumgebung schon lange im größeren Maßstab durchgesetzt.

Anstelle eine schlechte One-Size-Fits all Einheitsbrei-Geschichte wie FMX zu bieten stellt Xamarin vernünftigerweise die nativen Plattform-APIs für eine Sprache zur Verfügung. Man arbeitet also nicht mit schlecht nachgemachten Controls, sondern mit den echten Steuerelementen jeder Plattform.

Wie gut das im allgemeinen funktioniert sieht man z.B. an den ungeheuer vielen Spielen in den Stores die mit Unity 3D erstellt wurden - und Unity basiert auf Xamarin.

[vagtler]

Multiplattform-Entwicklung unter Visual Studio ist allerdings nicht mit der kostenfreien Edition von Xamarin möglich.

Und was die Frage nach Konkurrenz betrifft lass es mich mal so formulieren: Da wo Firemonkey einen in meinen Augen eher fragwürdigen und vor allem herstellerabhängigen plattformübergreifenden Ansatz wählt, versucht Xamarin gar nicht erst irgend etwas halbgares oder disfunktionales hinzubasteln. Wie Phoenix schon ganz korrekt anmerkte, arbeitet Xamarin hier mit den nativen und somit für den Benutzer auf der jeweiligen Plattform gewohnten Steuerelementen.

Dementsprechend stellt sich für mich diese Frage gar nicht, den im Gegensatz zu Xamarin halte ich Firemonkey nicht wirklich für professionelle plattformübergreifende Softwareentwicklung geeignet.

[mkinzler]

Wobei mit den Komponenetn von D.P.F

http://sourceforge.net/projects/dpfdelphiios/
http://sourceforge.net/projects/dpfdelphiandroid/

auch FMX-Wrapper für die nativen Systemkomponenten vorliegen.

[lowmax_5]

Zitat:

Wobei mit den Komponenetn von D.P.F

http://sourceforge.net/projects/dpfdelphiios/
http://sourceforge.net/projects/dpfdelphiandroid/

auch FMX-Wrapper für die nativen Systemkomponenten vorliegen.

Wären die Wrapper-Komponenten den eine echte Option, um FMX doch einzusetzen?
Letzten Endes kommt es ja gerade bei mobilen Geräten darauf an, das der erzeugte Code schlank ist und nicht nach einer halben Stunde den Akku aussaugt, da die Komponenten gerendert werden. Hat schon jmd. die Komponenten von D.P.F. erfolgreich eingesetzt?

[v2afrank]

Den Beitrag von lowmax_5 kann ich voll und ganz unterschreiben. Mich würde es auch interessieren ob schon jemand etwas über den realen Einsatz von D.P.F. sagen kann. Zumindest für Iphone gibt es ja ein real World Beispiel. Leider habe ich kein IPhone um das zu testen.

[Darlo]

Ich setze die von TMS unter iOS ein. Läuft top.

[Crocotronic]

Meiner Meinung nach macht die Firemonkey-Entwicklung nur dann sinn, wenn man weiterhin mit Delphi arbeiten möchte, um jahrelang gesammelte Erfahrungen zu nutzen.
Außerdem ist das Erlernen einer neuen Sprache um Weiten aufwändiger, als sich in Firemonkey einzuarbeiten.
Wenn sich aber die Frage stellen würde, ob lieber mit Delphi XE4/5 oder Oxygene,Xamarine,..., anzufangen, dann wäre die Antwort ja wohl klar. Schon allein wegen der buggy IDE und all den Nerven, die drauf gegangen sind, würde ich von Delphi XE4/5 abraten.
Wenn man sich dann auch noch das Ergebnis einer Firemonkey-Entwicklung anguckt (ohne nativen Controls), dann würde man wahrscheinlich bereuen, überhaupt gefragt zuhaben.
Trotzdem habe ich mich für diese Entwicklung entscheiden, da Ich eben weiterhin mit Delphi programmieren will und auch keine Lust auf C-Java-Mischmasch-Sprachen habe (weshalb auch nur Oxygene für mich als Alternative in Frage käme)

[vagtler]

Zitat von Crocotronic:

[...] Außerdem ist das Erlernen einer neuen Sprache um Weiten aufwändiger, als sich in Firemonkey einzuarbeiten. [...]

Das kann ich definitiv nicht unterschreiben. Ich kann in meiner täglichen Arbeit permanent beobachten, wie leicht der Wechsel zwischen Programmiersprachen auch eher ungeübten Entwicklern fällt. Die Einarbeitung in das zugrundeliegende Framework bedeutet eigentlich den zeitraubenden Hirnschmalz. Und da bildet Firemonkey keine Ausnahme.

Nebenbei bemerkt ist tatsächlich all unseren Delphi-Entwicklern der Wechsel auf C# wirklich sehr leicht gefallen und lässt sich wirklich in wenigen Tagen messen - zumindest was die Sprache als solches betrifft.

[Crocotronic]

Zitat von vagtler:

Nebenbei bemerkt ist tatsächlich all unseren Delphi-Entwicklern der Wechsel auf C# wirklich sehr leicht gefallen und lässt sich wirklich in wenigen Tagen messen - zumindest was die Sprache als solches betrifft.

Die Sprache als solche hast du auch gelernt, wenn du dir ein C-Buch durchliest.
Aber erst wenn man es mal geschafft hat, ein großes Projekt zu vollenden, kannst du behaupten, dass man einer Sprache mächtig ist.

Zitat von vagtler:

Das kann ich definitiv nicht unterschreiben. Ich kann in meiner täglichen Arbeit permanent beobachten, wie leicht der Wechsel zwischen Programmiersprachen auch eher ungeübten Entwicklern fällt. Die Einarbeitung in das zugrundeliegende Framework bedeutet eigentlich den zeitraubenden Hirnschmalz. Und da bildet Firemonkey keine Ausnahme.

"Neue Sprache" lernen heißt ja nicht nur, die Syntax zu kennen und anwenden zu können. Viel mehr heißt es, mit Ihr zurecht zu kommen und bei Aufkommen eines Problems zu wissen, welche Mittel verwendet werden müssen. Dazu gehört auch sich mit den Bordmitteln bzw. mit sprachspezifischen Dingen (z.B. die Helferklasse in Delphi) auszukennen. Auch Tücken einer Sprache erfährst du erst mit der Zeit.
Das alles schaffst du nicht in wenigen Tagen.

Deshalb bin ich mir ziemlich sicher, dass die Mischung aus "neuer Sprache" und neuem Framework es schwerer macht, als auf bekannten Sprachkenntnissen aufzubauen.