Firemonkey vs. Xamarin

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

[Thomas_K]

Ich bin der glückliche Nutznießer einer Rad Studio Pro mit ‚Maintenance and Support‘ Lizenz, welche die Mobile Packs mit einschließt, die in einer „Testumgebung“ läuft, zusammen mit ein einfaches Android Tablet und einen älteres iPhone. Bei der Gelegenheit arbeite ich mich erstmal grundsächlich in der App Programmierung ein.

Ich muss gestehen ich hatte noch nicht die Zeit mich mit Xamarin näher zu beschäftigen, doch Emb muss da erstmal „catch up“ spielen und das auf mehren Ebenen. Delphi unterstützt keine Intel CPU für Android und Windows Phone Apps lassen sich auch keine erstellen, beides ist mit Xamarin bzw. mit VS heute möglich. Fairer weise muss man sagen, diese Punkte stehen auch auf der Delphi Roadmap und vielleicht in einem Jahr ist das alles möglich – nur nützt dann einem ein Delphi XE6 mit Mobile Pack wenig.

Die Standard FMX Controls sind nur bis zu einem bestimmten Punkt für Apps angepasst, will man zu Bespiel ein Picker verwenden, muss man eine FMX Combobox nehmen die aber keine Hinttext Funktion besitzt, so das man gezwungen ist eine Text Komponente daneben zusetzen, so das einen Schnell der Platzt ausgeht und zumindest auf iOS ungewohnt aussieht. Man muss die Combobox auch genau treffen, sonst gibt es keine Reaktion, was meine Testanwender auch nicht so toll finden.

Geworben wird das der Code direkt in der CPU läuft wird und so schnell ausgeführt wird, in der Praxis ist da auf einfacher bzw. älter Hardware wenig zu spüren. Apps brauchen relativ lange zum Starten, das Wechseln auf eine andere Seite in einem Tab Komponente kann schon mal 1 bis 2 Sekunden dauern. Slide Animation laufen Höchsten Falls stocken, Workarounds sind im Internet nur schlecht erklärt und was bringt einem eine relative weiche Animation, wenn die erst merklich verzögert startet?

Meiner Meinung muss sich Embarcadero anstrengen, viele Ecken und Kanten zu glätten damit das ganze ein Runde Sache wird. Sie können jetzt zeigen wie schnell sie auf Änderungen des Marktes reagieren können, wenn sie aber der Meinung sind sie haben die Zeit die Kundschaft warten zulassen, schnapp die mit viel mühe geöffnet Tür des Mobilmarktes einfach wieder zu !(bang)

[Mavarik]

hmm...

Welche der Kritiker an FMX hat mit der aktuellen Version (XE6.1) mal eine App für Android, iOS und Windows geschrieben?
Von der ersten Version bis heute, hat FMX einen gewaltigen Sprung gemacht. Einige Schachen funktionierten selbst mit XE5 noch nicht, die jetzt problemlos und sehr performat laufen.

FMX Programme sind zu groß? Ja, hier könnte der Linker noch besser optimieren.
FMX Programme brauchen zu viel Strom? Hab ich noch nicht testen können, aber Theoretisch müsste es eigentlich sein. (Egal?)
FMX Programme haben "nachgebildete" Controls! Na und? Also meine User merken das eh nicht und wenn ist es Ihnen egal...

Dem gegenüber steht:

Ich schreibe mir "meine" Lib mit dem ein oder anderen IFDEF, fertig.
Hier drin ist alles was ich brauche inkl. SQLite Interface für alle Plattformen inkl. Win32/64

Und dann?

Wenn ich mich an die kleinen unterschiede zur VCL und zur VCL-Maus Programmierung gewöhnt habe, programmiere ich mit 99% meiner
VCL Programmiergeschwindigkeit meine Apps für (zur Zeit) 3 Plattformen. Geil.

- Ich kann auf meinem PC testen.
- Dabei nutze ich den "normalen" Compiler&Linker der in wenigen Sekunden die App übersetzt.
- Plattform spezifische Sachen kann ich, wenn nötig direkt auf alle Plattformen testen.
- Ich brauche eine Routine? Dann lade ich eine Unit aus meinem reichen Fundus, der sich seit über 30 Jahren angesammelt hat. Zu 95% kann ich den Code so übernehmen. Gelegentlich einen Postmessage ersetzen oder wegen Arc ne Kleinigkeit anpassen, fertig.

Mit FMX Geld verdienen? Klar warum nicht. Meine Apps sind als zusätzlichen Service für meine PC-Software-Kunden gedacht. Hierbei ist/war also oberstes Gebot mit möglichst wenig Aufwand diese Apps zu erstellen, da ich die Apps nicht verkaufen kann...

Also gab es für mich keine Alternative und mit FMX konnte ich problemlos mein Ziel erreichen.

Gibt es eine bessere Empfehlung?

Vielleicht sollte ich mir doch mal die Zeit nehmen und einen Vortrag für die Delphitage erstellen...

Mavarik

[LUFTMACH=ON]

PS.: @alle "Nestbeschmutzer" die meinen XYZ wäre doch viel besser geeignet oder FMX wäre nicht professionell genug:
Was macht Ihr dann hier im Forum? Wenn das andere so toll ist schreib doch da im Forum.

[LUFTMACH=OFF]

Hab Euch alle Lieb...

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