Firemonkey vs. Xamarin

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

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

[squetk]

Danke Phoenix - super Antwort!

Ich denke, wenn sich FireMonkey in Zukunft nicht ausreichend verkaufen sollte, wäre dies das schon seit Jahren herbeigeredete Aus für Delphi als Entwicklungsumgebung. Aber das werden auch die Jungs bei Embarcadero wissen und diesem Punkt auch die entsprechende Priorität einräumen.
Aber die Verkaufszahlen sollen ja nicht sooo schlecht sein...

Eine Alternative wäre für mich nur PhoneGap, Xamarin ist schlichtweg zu teuer.

[lowmax_5]

Zitat:

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?

@Phoenix: Das sind natürlich wichtige Argumente, doch bin ich mir gerade bei den grossen Playern nicht immer sicher, ob die eingesetzte Technologie nicht abgekündigt bzw. erneuert wird. Beispiele gab es in der Vergangenheit genug, ohne hier weiter in die Tiefe zu gehen.
Für Emb ist der Erfolg von FMX sicherlich überlebenswichtig, so dass sie im eigenen Interesse das Produkt so 'Rund' machen, dass es in der Nische erfolgreich sein kann.


@All:Gibt es bereits erfolgreiche Projekte mit FMX und nativen Komponenten für IPhone,IPad & Android, wo man wirklich sagen kann, dass diese in der Praxis funktionieren und somit eine Option neben Xamarin darstellen?

[vagtler]

Sehr sehenswert ist übrigens das Video auf Channel 9 zu Xamarin: http://channel9.msdn.com/Shows/Visua...t-With-Xamarin

Spannend finde ich auch die Ankündigung, dass Storyboarding für Visual Studio kommen wird...

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

[Bambini]

Zitat von lowmax_5:

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.

Auch wenn man nur die native Controls verwendet, ist die Anwendung ".EXE" nicht schlank.
Durch die Verwendung der FMX.Forms kommt der gesamte FMX und RTTI overhead mit hinein und bläht die einfachste Anwendung auf mindestens 8 MB auf.

Auf der letzten XE6 Roadshow von Embarcadero wurde diese Thema angesprochen und man ist sich dieses Problems bewusst und arbeitet daran. Evtl. kommt in den nächsten Versionen Besserung.

Da Cross-Plattform (MacOS) breits seit XE2 enthalten ist und gravierende Probleme mit XE6 immer noch nicht gelöst wurden, würde ich die Luft nicht zu lange anhalten, dass sich dies in den kommenden Versionen entscheidend ändert.

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