Firemonkey vs. Xamarin

[lowmax_5]

Hallo,

ich wollte mal Eure Meinung zum Vergleich Firemonkey versus Xamarin hören, wobei bei Letzterem nun auch die Multiplattform-Entwicklung mit dem VisualStudio möglich ist. Habt Ihr dazu schon Erfahrungen sammeln können? Wo liegen die stärken/schwächen? Ist dieses überhaupt eine ernsthafte Konkurrenz zu FM? Freue mich über eine rege Diskussion!

[Phoenix]

Xamarin ist um einiges älter als Firemonkey und hat sich als Cross-Plattform-Entwicklungsumgebung schon lange im größeren Maßstab durchgesetzt.

Anstelle eine schlechte One-Size-Fits all Einheitsbrei-Geschichte wie FMX zu bieten stellt Xamarin vernünftigerweise die nativen Plattform-APIs für eine Sprache zur Verfügung. Man arbeitet also nicht mit schlecht nachgemachten Controls, sondern mit den echten Steuerelementen jeder Plattform.

Wie gut das im allgemeinen funktioniert sieht man z.B. an den ungeheuer vielen Spielen in den Stores die mit Unity 3D erstellt wurden - und Unity basiert auf Xamarin.

[vagtler]

Multiplattform-Entwicklung unter Visual Studio ist allerdings nicht mit der kostenfreien Edition von Xamarin möglich.

Und was die Frage nach Konkurrenz betrifft lass es mich mal so formulieren: Da wo Firemonkey einen in meinen Augen eher fragwürdigen und vor allem herstellerabhängigen plattformübergreifenden Ansatz wählt, versucht Xamarin gar nicht erst irgend etwas halbgares oder disfunktionales hinzubasteln. Wie Phoenix schon ganz korrekt anmerkte, arbeitet Xamarin hier mit den nativen und somit für den Benutzer auf der jeweiligen Plattform gewohnten Steuerelementen.

Dementsprechend stellt sich für mich diese Frage gar nicht, den im Gegensatz zu Xamarin halte ich Firemonkey nicht wirklich für professionelle plattformübergreifende Softwareentwicklung geeignet.

[mkinzler]

Wobei mit den Komponenetn von D.P.F

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

auch FMX-Wrapper für die nativen Systemkomponenten vorliegen.

[lowmax_5]

Zitat:

Wobei mit den Komponenetn von D.P.F

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

auch FMX-Wrapper für die nativen Systemkomponenten vorliegen.

Wären die Wrapper-Komponenten den eine echte Option, um FMX doch einzusetzen?
Letzten Endes kommt es ja gerade bei mobilen Geräten darauf an, das der erzeugte Code schlank ist und nicht nach einer halben Stunde den Akku aussaugt, da die Komponenten gerendert werden. Hat schon jmd. die Komponenten von D.P.F. erfolgreich eingesetzt?

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

Zitat von Crocotronic (Beitrag 1248395)

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

Zitat von vagtler (Beitrag 1248397)

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:

Zitat von vagtler (Beitrag 1248397)

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.

[jensw_2000]

Xamarin habe ich mir ehrlich gesagt nie wirklich angesehen, aber wenn ich richtig informiert bin, dann verwendet es .Net und MonoTouch für iOS und OSX Applikationen.
Ohne Frage ist MonoTouch eine oft benutzte und brauchbare Lösung, um auf der Zielplattform mit den nativen SDKs zu arbeiten. Es hat aber auch große Nachteile. Zum Beispiel erhöht sich der Lernaufwand, weil man zum einen versehen muss, wie die nativen SDKs ticken und zum anderen muss man zusätzlich die Besonderheiten der dazwischenliegenden Abstraktionsschicht zur Programmiersprache C# lernen.
Weiterhin sehe ich auch einen "zeitlichen Nachteil" bei Xamarin, der dadurch entsteht, dass man bei iOS/OSX SDK bzw. MonoTouch Updates immer auf ein Xamarin Update warten muss, bevor man wirklich loslegen kann. Ebenfalls kann man nicht direkt ObjC Code anschauen und den äquivalenten C# Code dafür eintippen. Weil Standard C# u.a. keine Unterstützung für die ObjC Multipart Methodnames bietet. Man muss also immer umdenken.
In allen diesen Beziehungen ist Oxygene, dass ich seit iOS6 benutze, klar im Vorteil. Oxygene kompiliert direkt gegen die ObjC Runtime und arbeitet direkt mit den ObjC Klassen und iOS/OSX SDK's. Wenn etwas Neues kommt (im meinem Fall waren es iOS6.x /iOS7) dann braucht man "theoretisch" nur noch die neuen SDK Header in Oxygene importieren (das dauert 3 Minuten) und kann loslegen. Praktisch gab es bei der ersten iOS 7 Beta 2-3 Tage, die RemObjects gebraucht hat, um ein Fix für das neue Xcode 5 Storyboard Format bereitzustellen. Akzeptabel, wie ich finde.
Zudem kostet Oxygene nur einen Bruchteil von Xamarin, es unterstützt auch Java und das Android SDK (native Java ohne Framework Layer) und bietet zudem noch Sprachfeatures, bei denen alle anderen Sprachen deutlich hinterherhinken. Die Jungs von RO sind total engagiert dabei, dem Pre-Compiler alles beizubringen was er braucht, um das Beste aus allen Sprachen/Plattformen plattformübergreifend bereitzustellen (z.B. Properties und Delegates für Java, Linq Befehle für Objective C und Java, Multipart Methodnames für alle Plattformen, Simple Type boxing für ObjC, ...). Alles ist natürlich optional nutzbar.
Ich finde es einfach nur großartig.

Was das Lernen betrifft...
Ich bin auch ein altes Delphi Roß. Seit Delphi 3 habe ich mir zuvor keine andere Sprache angesehen.
Der Einstieg in die iOS Entwicklung war mit Oxygene aber wirklich leicht. Das liegt daran, dass fast alle iOS SDKs gleich aufgebaut sind. Es sind einfach fast immer Delegates und Protocols(Interfaces), in Kombination mit Befehlen die Dank der Multipart Methodnames wie ein Satz lesbar ( und damit weitestgehend selbsterklärend) sind.
Zum Start habe ich mir 10-20 "Frank Jüstel XCode Videos" auf Youtube angesehen. Danach hatte ich schon ein ziemlich gutes Gefühl dafür, wie Xcode mit den iOS SDKs zusammenarbeitet. Der Einstieg in Oxygene war Dank des vertrauten Pascals und der exakten Übereinstimmung der Methodennamen und Signaturen zu den iOS SDKs wirklich easy.
Natürlich lerne ich noch jeden Tags dazu und finde auch manchmal echte "iOS Brocken" (wie das Addressbook Framework) die mich erstmal erstmal wieder runterziehen, aber solche "Probleme" hätte ich mit anderen Entwicklungssystemen sicher auch gehabt.
Der Einstieg wird auch leichter durch den "Oxydizer" von Oxygene. Das ist ein Copy&Paste Tool, mit dem man Java-, Delphi, C# oder ObjC Code in die Zwischenablage kopieren und als Oxygene Pascal wieder pasten kann. Für ObjC ist der Teil zur Zeit nur in der Beta verfügbar, funktioniert aber schon recht gut und nimmt einem schon viel Übersetzungsarbeit ab.

[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

[daywalker9]

Zitat:

Zitat von jensw_2000 (Beitrag 1248409)

Weiterhin sehe ich auch einen "zeitlichen Nachteil" bei Xamarin, der dadurch entsteht, dass man bei iOS/OSX SDK bzw. MonoTouch Updates immer auf ein Xamarin Update warten muss, bevor man wirklich loslegen kann.

Das kann ich nicht bestätigen, kurz nach release einer Beta ist auch ein Update für Xamarin da. Mit Xamarin haben wir nur gute Erfahrungen gemacht!

[jensw_2000]

Zitat:

Zitat von daywalker9 (Beitrag 1248425)

Zitat:

Zitat von jensw_2000 (Beitrag 1248409)

Weiterhin sehe ich auch einen "zeitlichen Nachteil" bei Xamarin, der dadurch entsteht, dass man bei iOS/OSX SDK bzw. MonoTouch Updates immer auf ein Xamarin Update warten muss, bevor man wirklich loslegen kann.

Das kann ich nicht bestätigen, kurz nach release einer Beta ist auch ein Update für Xamarin da. Mit Xamarin haben wir nur gute Erfahrungen gemacht!

Das kann sein, und ich möchte auch nichts anderes unterstellen. Wie gesagt, ich habe mir Xamarin nie persönlich angesehen.
Im RemObjects Talk wurde dieser Punkt durch andere Xamarin User als kleine Schwäche angemerkt.

[vagtler]

Ich finde beide Ansätze - sowohl Xamarin als auch Oxygene - sehr interessant und betrachtenswert. Wir haben uns nach einer Evaluierungsphase für Xamarin entschieden, da wir hier mehr Know How in C# als in Object Pascal haben und nahezu ausschließlich unter Mac OS X entwickeln.

Letztendlich ist es halt auch eine Entscheidung unter strategischen und ökonomischen Gesichtspunkten und Oxygene halte ich ebenfalls für eine sehr gute Lösung.

Firemonkey nicht.

[jensw_2000]

Zitat:

Zitat von vagtler (Beitrag 1248428)

Ich finde beide Ansätze - sowohl Xamarin als auch Oxygene - sehr interessant und betrachtenswert. Wir haben uns nach einer Evaluierungsphase für Xamarin entschieden, da wir hier mehr Know How in C# als in Object Pascal haben und nahezu ausschließlich unter Mac OS X entwickeln.

Letztendlich ist es halt auch eine Entscheidung unter strategischen und ökonomischen Gesichtspunkten und Oxygene halte ich ebenfalls für eine sehr gute Lösung.

Firemonkey nicht.

Das bringt es auf den Punkt. :thumb:
Alle Lösungen haben hier und da ihre Stärken, außer Eine. :wink:

[Phoenix]

Zitat:

Zitat von vagtler (Beitrag 1248397)

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.

Dazu möchte ich noch kurz meinen Senf abgeben ;-)
Ich denke, das es Delphianern per se relativ einfach gelingt, sich in C# und das .NET Framework im allgemeinen einzuarbeiten. Delphi als Sprache, die RTL und VCL tragen alle noch immer die Handschrift von Anders Hejlsberg, genauso wie C#, die CLR / BCL und FCL. Und wenn man - bildlich gesprochen - Anders' Fußstapfen in Delphi kennt, dann weiss man auch, wo man in der .NET Welt nach dem nächsten Fußabdruck schauen muss, wenn man dort weiterkommen will. Die Ähnlichkeit ist unverkennbar da. Man muss nur mal ein bisschen hinter die Fassade schauen.

[Buddelfish]

Na, und dann ist Delphi eine Programmiersprache und C# auch. Ich würde eher die vielen 'Aha! So einfach kann man das machen!' und 'Oh Mann, hab ich mir in Delphi dafür einen abgebrochen' Erlebnisse dazu zählen. Vor allen Dingen Linq, Expressions, diverse ORM etc.

Java ist natürlich Anders (Hejlsberg ;-) aber auch hübsch.

Aber klar: Buttons, Events, Formulare. Irgendwie kennt man das. Aber das ist WinForms und so ein wenig ist das wie die VCL.

Aber vielleicht hast Du Recht und die Tatsache, das man C# einfach einfacher findet, liegt an der Handschrift vom Hejlsberg, ohne das man das merkt. Wobei ich mich frage, wo die konkrete Handschrift ist? Die an Java angelegte Syntax kann es nicht sein, die .NET-API hat gar nichts mit der VCL zu tun, Linq ist kein Delphi, äh.. was bleibt denn?

So: Das war mein Senf.

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

Zitat von squetk (Beitrag 1248479)

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! :-D

[Phoenix]

Zitat:

Zitat von lowmax_5 (Beitrag 1248499)

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:

Zitat von lowmax_5 (Beitrag 1251686)

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:

Zitat von Union (Beitrag 1248497)

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.

:thumb:

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

[mkinzler]

Zitat:

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.

Es gibt auch Erweiterungen and der RTL/VCL. Der Großteil der Änderungen wurde aber an FMX gemacht.

[jensw_2000]

Zitat:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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

Zitat von Mavarik (Beitrag 1262980)

Gibt es eine bessere Empfehlung?[/B]

Zitat:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von Mavarik (Beitrag 1262980)

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:

Zitat von greenmile (Beitrag 1263014)

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.

[greenmile]

Die Hoffnung stirbt zuletzt und da sie in XE6 zumindest umfangreiches Bugfix betrieben haben könnte es ja sein, dass Weihnachten und Ostern tatsächlich mal auf denselben Tag fallen.

[mkinzler]

Zitat:

Du glaubst doch nicht im Ernst, dass Emba irgendetwas freiwillig kostenlos raus gibt.

Doch AppMethod free forever; aber nur für Android und C++.
Was zeigt das EMBT das

Zitat:

wie wenig Leute eigentlich noch an Delhi interessiert sind.

ähnlich sieht wie Du. Delphi heißt bei AppMethod ja schon OP und nicht mehr Delphi!

[Mavarik]

Zitat:

Zitat von cookie22 (Beitrag 1263025)

Zitat:

Zitat von Mavarik (Beitrag 1262980)

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.

Ich könnte meinen Kunden 2 Apps neben einander halten einmal mit Nativen einmal mit FMX... die würden keinen unterschied sehen.

Außerdem nehme ich sowieso meinen eigenen Skin, damit es auf iOS und Android gleich aus sieht...

Mein App... Meine Regeln...

Mavarik