Firemonkey vs. Xamarin

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

[Union]

Zitat von squetk:

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.

Ja, das scheint es zu sein. Bei der Entwicklung mit FMX habe ich ein 90/10 - Problem festgestellt. Die ersten 90% gehen ganz toll, und man benötigt dafür nur 10% der veranschlagten Zeit. Für die restlichen 10% benötigt man dann 500% der ursprünglich geplanten Zeit. Das sind oft Kleinigkeiten und Selbstverständlichkeiten die nicht so funktionieren wie gewollt oder auf den verschiedenen Plattformen doch nicht einheitlich gelöst wurden.

[greenmile]

Zitat von Union:

Bei der Entwicklung mit FMX habe ich ein 90/10 - Problem festgestellt. Die ersten 90% gehen ganz toll, und man benötigt dafür nur 10% der veranschlagten Zeit. Für die restlichen 10% benötigt man dann 500% der ursprünglich geplanten Zeit. Das sind oft Kleinigkeiten und Selbstverständlichkeiten die nicht so funktionieren wie gewollt oder auf den verschiedenen Plattformen doch nicht einheitlich gelöst wurden.

[lowmax_5]

Zitat:

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.

Diese Frage hätte ich exakt auch so gestellt.
Es würde mir bei einer Firemonkey-Business-Anwendung darum gehen die 'guten Features' von Delphi zu kombinieren mit einem einfachen Plattform Unterstützung. Die Geschwindigkeit der Entwicklung wäre hierbei ein entscheidender Vorteil. Es ist hierbei sicherlich nicht notwendig, dass letzte und aktuellste Feature der mobilen Geräte zu nutzen, sondern Basisfunktionen - gerne mit nativen Controls. Das was wann dabei herauskommt muss dann allerdings gut laufen und die Performance der vorhandenen Hardware entsprechend nutzen.

Es wäre kein Problem pro Gerätetyp z.B. ein separates Form zu haben, was entsprechend optimiert ist. Da steckt sowieso nicht der grosse Zeitaufwand drin. Aber diese Forms würden innerhalb einer Projektgruppe die gleiche dahinterstehende Anwendungslogik nutzen und da würde ich einen entscheidenden Vorteil von FMX sehen.

Wenn ich dann x-mal F9 drücken dürfte wäre ich vollkommen zufrieden!

[Phoenix]

Zitat von lowmax_5:

Es wäre kein Problem pro Gerätetyp z.B. ein separates Form zu haben,...

Pro Gerätetyp. Also für iOS, Android, Windows Phone (whoops), Windows RT Tablets (whoops)...

Dadurch das Embarcadero hier auf eine *sehr* einsamen Insel lebt und eine *sehr* kleine Nische bedient, ist man was die Zukunftsfähigkeit angeht derzeit extrem stark vom Wohlwollen Marco Cantu's abhängig. Wenn er als Product Manager meint, Windows Phone oder Win RT seien nicht so wichtig (egal was die Zahlen sagen), dann ist das eben so.

Ich würde eine Technologieentscheidung auch immer anhand einer Risikoanalyse treffen.
* Wie hoch ist das Risiko, das wichtige Bugs nicht gefixt werden?
* Wenn Kommerziell: Wie gut / schnell reagiert das Unternehmen auf meine Bedürfnisse?
* Wie viel Support kann ich zu meinen Problemen von der Community bekommen?
* Falls OpenSource: Wie aktiv ist ein Projekt? Kann ich im Notfall selber eingreifen?

Wenn ich mir so anschaue, wie agil Xamarin auf seine User eingeht, und wie Embarcadero gegenüber den Wünschen seinen Kunden reagiert, wie viele Leute bei Xamarin an der Toolsuite arbeiten und wieviele bei Embarcadero an Delphi arbeiten, wie aktiv z.B. Phonegap ist und wie schnell man hier auch mal selber ggf. notwendige Sachen bauen kann, dann ergibt sich da ein sehr eindeutiges Ranking was mögliche Technologien für Shared-Source Mobile Projekte angeht.

Die Masse da draussen setzt auf Xamarin oder Phonegap. Die Firemonkey-Entwickler kann man hingegen abzählen. Was machst Du, wenn Embarcadero feststellt, das Firemonkey nicht genug Tritt fasst und es dann auf einmal wie Delphi for .NET oder wie Kylix behandelt?