Firemonkey vs. Xamarin

[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.

[creed steiger]

Qt wäre auch noch eine Option

http://blog.qt.digia.com/blog/2013/1...tores-with-qt/

pros:Qt gibts schon lange,genug Manpower,gutes Framework,dual licensing
cons:kein Pascal

[Mr.Mobile]

Vorab: Ich kenne Firemonkey nicht, aber dafür Xamarin schon seit der Novell-Zeit und möchte meinen "Senf" dazu beitragen.

Wie schon erwähnt bin ich seit der ersten Stunde von MonoTouch und Mono4Android (heute: Xamarin.iOS und Xamarin.Android) dabei. Auf irgendwelche Updates warten muss man gar nicht, da Xamarin max. 24h nach der offiziellen Launch der Hersteller-SDK-Versionen Ihre Tools in den Stable-Channel nimmt. Davor sind diese entweder im Alpha oder Beta-Channel zu finden.

Des Weiteren sollte man nicht vergessen, dass Xamarin im Moment den gleichen gemeinsamen Nenner C# anbietet und somit Code Sharing von bis zu 80% Prozent über iOS, Android und Windows Phone ermöglicht. Klar sollte aber auch sein, dass die GUI immer redundant für alle Plattformen geschrieben werden muss. Wenn man es geschickt anstellt, kann man die UI sehr "dumm" halten und somit einen sehr gut wattbaren und Performance App entwickeln. Hierzu möchte ich noch dazu sagen, dass sowohl Xamarin.iOS und Xamarin.Android native Packages erzeugt und keine virtualisierte APK / IPA erstellt.

Alles was man mit Objective-C oder JAVA auf der jeweiligen Plattform machen kann, ist auch mit Xamarin zu 100% möglich. Auch das benutzen von schon vorhandenen nativen Controls / Libraries.

Ich selber benutze Xamarin.iOS und Xamarin.Android sehr erfolgreich in meinen Projekten, die nicht nur kleine beinhalten.

[squetk]

Da sich die Kritik an FireMonkey scheinbar hauptsächlich an der Tatsache festmachen lässt, dass per default nicht die nativen Controls unterstützt werden:
Warum wäre von FM in der Kombination mit der Nutzung nativer Controls (z.B. von TMS o.ä.) abzuraten?

Mir geht es dabei nicht um die Entwicklung von Spiele-Apps sondern um Business-Apps. Auf den ersten Blick scheint Delphi mit FM dafür eine interessante Lösung zu sein.

[lowmax_5]

Ich wollte gerne den Thread nochmal aufgreifen und fragen ob praktische Erfahrungen mit FMX auf mobilen Plattformen im Businessbereich vorliegen, um schnelle und lauffährige Anwendungen für IOS und Anroid zu erzeugen. Gerne auch mit den Komponenten von D.P.F

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

Wichtig ist, dass die Anwendungen schlank sind und durch das Rendering nicht den Akku leersaugen - also 'echt' mobiltauglich.

Für uns wäre dieses eine grundlegende Richtungsentscheidung hinsichtlich FMX bzw. Xamarin.

[RWarnecke]

Du musst aufpassen, wenn Du die nativen Delphi for iOS Komponenten nutzen willst (D.P.F. Components / TMS iCL). Diese Komponenten dürfen nicht mit den FMX-Komponenten in einer Form gemischt werden. Dieses bezieht sich nur auf die visuellen Komponenten.