Firemonkey vs. Xamarin

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

**stahli**

Nicht-Native Controls stören mich auch nicht - da schließe ich mich an.

Den Rest kann ich nicht nachvollziehen weil ich mir XE6 nicht leisten kann. Habe 2012 1.600 Eu "umsonst" ausgegeben. Das muss ich erst wieder ansparen.

"Umsonst" soll hier heißen, ich hätte bei XE bleiben können weil die Änderungen, die mir XE3 versprochen hat (FMX, LiveBindings usw) produktiv nichts gebracht haben.

Wenn XE2 oder 3 das Niveau von XE6 gehabt hätten oder die Käufer und Besitzer dieser "alten" Versionen XE6 als Fehlerupdate kostenfrei bekämen, dann wäre das eine andere Grundlage.

So wie es aktuell läuft finde ich es inakzeptabel.

PS: Und das Grundproblem besteht immer noch ... wer nicht für mobile Geräte entwickelt kann mit XE6 nicht viel anfangen, bzw. nicht mehr als mit XE.

Zitat von Mavarik:

Welche der Kritiker an FMX hat mit der aktuellen Version (XE6.1) mal eine App für Android, iOS und Windows geschrieben?

Nö. Werde ich auch nicht.

Zitat von Mavarik:

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.

Seit XE2 habe ich aber schon dafür gezahlt und FMX war nirgends besser oder gleichwertig mit anderen Lösungen.

Zitat von Mavarik:

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

Da kann man nichts gegen sagen. Jeder hat seine eigenen Maßstäbe für Qualität und Useability.

Dem gegenüber steht: "Visual Studio Pro mit RemObjects C# und Oxygene"
Da drin ist alles was ich brauche. Nativ für Windows,Java incl. Android, iOS, OSX, Windows Phone, Web.

Zitat von Mavarik:

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

Zu 95% will ich den alten Code garnicht mehr übernehmen. Das .Net Framework bietet für Windows alles, was man sich mit Delphi mühsam selbst bauen musste. Falls doch mal etwas fehlt: NuGet - Paket suchen - Lizenz anschauen - Paket installieren und fertig ist die Arbeit.
Die 3rd Party Komponenten wie DevExpress sind für .Net auch Jahrzehnte gegenüber Delphi Schwesterkomponenten voraus.
Auf anderen Plattformen (hier besonders iOS), gibt es so geniale SDKs und APIs, die keinen Wrapper brauchen. Mit den nativen SDKs gibt es kaum etwas, das man nicht mit ein paar wenigen Zeilen Code mit Bordmitteln lösen kann. Falls doch etwas fehlt haben es andere bereits gelöst und man findet seine fertige Arbeit in Stackoverflow & Co.
Die neuen iOS8 SDK benutze ich auch schon seit kurz nach der WWDC. Da muss ich jetzt nicht bis zum Herbst warten, bis EMBT wieder Geld braucht und XE7 mit iOS 8 Skin rausbringt

Zitat von Mavarik:

Gibt es eine bessere Empfehlung?[/B]

Zitat von Mavarik:

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.

Bin doch schon nur noch ganz selten hier... und verkneife mit alle Crossplattform Posts.
Hier musste ich kurz nochmal drauf antworten.

Zitat von Mavarik:

Hab Euch alle Lieb...

[/QUOTE]
Ich auch.

**greenmile**

Ich bin ja ein großer Kritiker, was FMX betrifft. Ich bin mehrmals auf die ... gefallen, habe mir blutige Nasen bei Auftragsentwicklungen geholt. FMX war einfach Schrott, Punkt. Der Compiler ist ok, der Rest für die Tonne. Allerdings musste ich jetzt ein Projekt in Android UND iOS umsetzen. Ich habe einen Wartungsvertrag, daher habe ich sowieso XE6 und habe ihm eine Chance gegeben. Vielmehr musste ich es.

Ergebnis: Es hat sich viel getan. Mit XE6 kann man endlich halbwegs gut arbeiten, auch wenn man nicht vergessen darf: Ich freue mich über etwas, was schon von Anfang an hätte so sein müssen; und bei Microsoft auch so ist. Bei all der Euphorie darf man nie vergessen: Solche Hauer, wie sich Embarcadero mit FMX, Mobile und co geleistet hat, hätte sich Microsoft niemals geleistet. Daran erkennt man, bei wem die professionellen Entwickler zu Hause sind.

Zitat von Mavarik:

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

- Ja
- Ja, eindeutig fressen die Strom, mein iPad war über Nacht leer. In Standby!
- Mich stört das sehr wohl!

Zitat von Mavarik:

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 genau das ist es, was mich daran fasziniert und weswegen ich eine Delphi Wartung habe.

Aber @ ME: Der Stahli ist ja nun recht aktiv und baut auch Dinge, die nicht ganz alltäglich sein (sein Framework). Kann man ihm nicht aus Nettigkeit eine XE6 Pro geben? Oder für einen symbolischen Wert von 50 EUR? Wäre für Euch echt Imagepflege.

**cookie22**

Zitat von Mavarik:

FMX Programme brauchen zu viel Strom? Hab ich noch nicht testen können, aber Theoretisch müsste es eigentlich sein. (Egal?)

Es ist dir also egal, wenn der Akku deiner Kunden nur halb so lange hält, weil FMX Strom ohne Ende frisst?

Zitat von Mavarik:

FMX Programme haben "nachgebildete" Controls! Na und? Also meine User merken das eh nicht und wenn ist es Ihnen egal...

Ich persönlich hasse die Programmierer, die auf die User Experience ihrer Kunden nichts geben.

Gerade unter MacOS X sehen FMX Apps einfach nur gruselig aus. Emba hat es in 5 Versionen nicht geschafft einen annähernd Native aussehenden Skin beizufügen. Und das so etwas nicht von der Community kommt zeigt, wie wenig Leute eigentlich noch an Delhi interessiert sind.

Schade, dass Emba nicht aus Fehlern lernt.

Zitat von greenmile:

Aber @ ME: Der Stahli ist ja nun recht aktiv und baut auch Dinge, die nicht ganz alltäglich sein (sein Framework). Kann man ihm nicht aus Nettigkeit eine XE6 Pro geben? Oder für einen symbolischen Wert von 50 EUR? Wäre für Euch echt Imagepflege.

Du glaubst doch nicht im Ernst, dass Emba irgendetwas freiwillig kostenlos raus gibt. Nachwuchs und Enthusiasten zu supporten passt einfach nicht in das Konzept, welches Emba seit Jahren fährt. Die würden sich lieber einen Finger abschneiden, bevor die auch nur ein Delphi for Free rausgeben und etwas positive Werbung für sich machen.

Ich würds Stahli gönnen, soviel Zeit wie er in seine FMX-Experimente gesteckt hat.