Was ist FireMonkey?

[Darlo]

Zitat von bernau:

Daumen hoch für Firemonkey.

Ich will Firemonkey auch nicht mehr missen. Wenn die Startzeiten unter iOS noch besser werden und es TWebbrowser und TMediaPlayer
gibt, werde ich komplett umsteigen.

[Bernhard Geyer]

Zitat von Darlo:

... und es TWebbrowser und TMediaPlayer

Da TWebBrowser auf ActiveX und IE und TMediaPlayer auf die ActiveX-Schnittstelle vom Windows Media-Player aufsetzt dürfte es hiermit ein Problem bei portabler Portierung geben...

Eine alternative wäre wohl wenn delphichromiumembedded einen portable implementierung liefern würde.
Und Mediaplayer kannst du kicken wenn du diese mittels HTML5-Seite realisierst die du in delphichromiumembedded lädst.

[Phoenix]

Zitat von bernau:

Neee. Firemonkey ist der richtige Schritt. Genau auf sowas habe ich gewartet. Mir ist es egal, ob das Programm sich nicht Windows-Like oder Mac-Like anfühlt. Schön ist es doch, daß es auf jeder Plattform gleich aussieht. [...]
Daumen hoch für Firemonkey.

Zitat von Darlo:

Ich will Firemonkey auch nicht mehr missen. Wenn die Startzeiten unter iOS noch besser werden und es TWebbrowser und TMediaPlayer
gibt, werde ich komplett umsteigen.

Nein, dass es überall gleich "aussieht" ist ein Problem. Es benutzt keine nativen API's. Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC. Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen. Das haben schon viele Firmen ausprobiert, sind daran gescheitert, und nun liefert Embarcadero auch noch ein Tooling, das genau diesen massiven Fehler propagiert und Entwickler dazu verleitet viel Zeit (und damit Geld) in eine Codebasis zu stecken die unter 100%iger Garantie nicht angenommen werden wird.

Oder anders gesagt: Jeder, der seine Anwendungen mit FM entwickelt wird zwangsläufig massivste Absatzprobleme erfahren. Das Zeug ist ganz einfach nicht an den Mann zu bringen.

Die Anforderung nach Webbrowser und Mediaplayer ist dann auch gleich wieder ein Zeichen, dass die Technologie hinter Firemonkey nicht verstanden wurde. Es gibt nunmal keinen überall verfügbaren Systemintegrierten Browser. Was ist mit embedded systemen? Headless Linux-Systeme, die z.B. ihre X-Oberfläche nur über ssh-tunnel an remote X-Window-Systeme schicken?

Jede Plattform hat ihre eigenen, individuellen Eigenheiten, und die wollen bedacht werden. Deswegen sagt Marc ja auch zu Oxygene / Prism: Ja, es läuft mit MonoTouch, ja, man kann iPhone-Anwendungen damit schreiben, ja, sie benutzen sogar im Hintergrund die nativen API's und abstrahieren nur minimal (viel weniger als FM), aber um Himmels willen, nehmt lieber Objective-C.

Tests haben auch ergeben dass die inhaltlich exakt gleiche Anwendung in Objective-C und in FM geschrieben fast ausschliesslich in der Objective-C-Variante gute Bewertungen erhält und heruntergeladen wird. Die nahezu identische FM-Version geht in der Versekung unter. FM ist die falsche Technologie, und wer auf ein totes Pferd setzt reitet ziemlich flott in den Untergang.

[TiGü]

Zitat von Phoenix:

Tests haben auch ergeben dass die inhaltlich exakt gleiche Anwendung in Objective-C und in FM geschrieben fast ausschliesslich in der Objective-C-Variante gute Bewertungen erhält und heruntergeladen wird. Die nahezu identische FM-Version geht in der Versekung unter. FM ist die falsche Technologie, und wer auf ein totes Pferd setzt reitet ziemlich flott in den Untergang.

Habt ihr die intern gemacht oder ist das eine öffentliche Studie? Wenn letzteres, dann bitte einen Link dazu!

[Phoenix]

Zitat von TiGü:

Habt ihr die intern gemacht oder ist das eine öffentliche Studie? Wenn letzteres, dann bitte einen Link dazu!

Das ist eine App die ich in Objective-C, MonoTouch und FM für iOS, Java und MonoDroid für Android und in C# fürs Windows Phone gebastelt habe.

Der Renner sind die iOS-Versionen in Objective-C und MonoTouch, (vermutlich da sie sich kaum unterscheiden). Bei Android sind die Unterschiede zwischen Java und MonoDroid auch vernachlässigbar.
Die FM-Version für iOS wurde sogar seltener geladen als die Windows-Phone Ausgabe, und bei der Verbreitung von WP will das was heißen.

Da es die App aber bisher tatsächlich erst seit November gibt will ich noch etwas abwarten. Aber ich finde das schon aussagekräftig genug.

Zitat von Bernau:

Habe irgendiw das Gefühl, daß du deine RemObjects-Brille auf hast und alles andere verteufelst.

Dann würde ich ja sagen, dass Oxygene immer das Mittel der Wahl wäre, aber das sage ich nicht. Ich bin ja auch mit Marc nicht einer Meinung was Objective C vs. Mono auf iOS und dem Mac angeht. Er ist ja ein starker Verfechter von Mac & iOS -> Objective-C, auch wenn Oxygene/Prism das mit MonoMac und dem kommerziellen MonoTouch kann (und ich das sehr elegant finde).

Ich bin lediglich der Meinung das eine Abstraktionsschicht immer den kleinsten gemeinsamen Nenner bedeutet (das hast Du ja auch selber gesagt:

Zitat:

Viele Platformen zu bedienen bedeutet kleinster gemeinsammer Nenner. Wenn das berücksichtigt wird, dann gibt's weniger Probleme.

), und der kleinste Gemeinsame Nenner ist eben zu wenig, weil die Anwender ihre Plattform voll ausreizen wollen. Das geht nur, wenn eine Anwendung das auch bietet (z.B. der neue Full-screen Modus in OS-X Lion).

Und ausserdem (Wiederholungsmodus an) ist das bei RO eher ein Hobby als ein Nebenjob. Ich mach das, weil ich Spass an Pascal habe und so neben meinem Hauptjob auch noch weiter auf Konferenzen gehen kann. Das hat nichts mit Plattformen und Technologien zu tun, und erst recht nicht mit Beeinflussung. Wenn ich was kacke finde, egal woran, auch an RO-Produkten, dann sage ich das auch frei raus.

[bernau]

Zitat von Phoenix:

Nein, dass es überall gleich "aussieht" ist ein Problem. Es benutzt keine nativen API's. Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC. Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Habe ich andere Erfahrungen mit gemacht.

Zitat von Phoenix:

Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen. Das haben schon viele Firmen ausprobiert, sind daran gescheitert, und nun liefert Embarcadero auch noch ein Tooling, das genau diesen massiven Fehler propagiert und Entwickler dazu verleitet viel Zeit (und damit Geld) in eine Codebasis zu stecken die unter 100%iger Garantie nicht angenommen werden wird.

Oder anders gesagt: Jeder, der seine Anwendungen mit FM entwickelt wird zwangsläufig massivste Absatzprobleme erfahren. Das Zeug ist ganz einfach nicht an den Mann zu bringen.

Auch hier deine persönliche Meinung. Oder kannst du das irgenwo belegen?

Zitat von Phoenix:

Die Anforderung nach Webbrowser und Mediaplayer ist dann auch gleich wieder ein Zeichen, dass die Technologie hinter Firemonkey nicht verstanden wurde. Es gibt nunmal keinen überall verfügbaren Systemintegrierten Browser. Was ist mit embedded systemen? Headless Linux-Systeme, die z.B. ihre X-Oberfläche nur über ssh-tunnel an remote X-Window-Systeme schicken?

Jede Plattform hat ihre eigenen, individuellen Eigenheiten, und die wollen bedacht werden. Deswegen sagt Marc ja auch zu Oxygene / Prism: Ja, es läuft mit MonoTouch, ja, man kann iPhone-Anwendungen damit schreiben, ja, sie benutzen sogar im Hintergrund die nativen API's und abstrahieren nur minimal (viel weniger als FM), aber um Himmels willen, nehmt lieber Objective-C.

Bei solchen Sachen hast du immer ein Problem. Egal ob mit FM, Oxygene, oder sonst was. Irgendwo müssen Abstriche gemacht werden. Viele Platformen zu bedienen bedeutet kleinster gemeinsammer Nenner. Wenn das berücksichtigt wird, dann gibt's weniger Probleme.

Zitat von Phoenix:

Tests haben auch ergeben dass die inhaltlich exakt gleiche Anwendung in Objective-C und in FM geschrieben fast ausschliesslich in der Objective-C-Variante gute Bewertungen erhält und heruntergeladen wird. Die nahezu identische FM-Version geht in der Versekung unter. FM ist die falsche Technologie, und wer auf ein totes Pferd setzt reitet ziemlich flott in den Untergang.

Ach. Habe noch nie ein Vergelichstest in dieser Art gesehen. Hast du einen Link? Firemonkey gibt's noch nicht so lange. Geschweige die damit erstellten Programme. Wie können dann jetzt schon seriöse Vergleiche durchgeführt werden?

Habe irgendiw das Gefühl, daß du deine RemObjects-Brille auf hast und alles andere verteufelst.

[MEissing]

Zitat von Phoenix:

Deswegen sagt Marc ja auch

Wer ist dieser "Marc"? Muss man den kennen?

GD&RVF

[Daniel]

Ich denke, das führt jetzt ein wenig zu weit. Und wir sollten versuchen, aus persönlichen Ansichten nicht gleich "Tatsachen" formulieren zu wollen. Gerade die als vermeintlich absolut unausweichliche Konsequenz formulierte These mit den Absatzproblemen halte ich sogar für höchst kritisch, da sie nicht belegbar ist (weder in der einen noch in der anderen Richtung).

FireMonkey hatte ohne Zweifel einen schwierigen Start. Es ist seither eine Menge an Arbeit eingeflossen, noch reichlich Arbeit liegt vor den Entwicklern. Das Für und Wider einer plattform-übergreifenden GUI ist schon oft diskutiert worden. Diese Diskussion möchte ich nicht abwürgen, doch möchte ich an dieser Stelle mit dieser Diskussion wenigstens nicht wieder bei Null anfangen müssen. Wir würden uns ewig im Kreise drehen.

@Sebastian: Aus Deiner Wortwahl lässt sich herauslesen, dass Du Dich gerade "in Fahrt" geschrieben hast. Darf ich Dir einen Tee, ein Plätzchen und frische Brise zum Durchatmen servieren?

[Phoenix]

Zitat von Daniel:

@Sebastian: Aus Deiner Wortwahl lässt sich herauslesen, dass Du Dich gerade "in Fahrt" geschrieben hast. Darf ich Dir einen Tee, ein Plätzchen und frische Brise zum Durchatmen servieren?

Überhaupt nicht
War lediglich auf dem Sprung in den Zug. Jetzt bin ich grad "in Fahrt" auf dem Weg nach Hause. Und Tee und Plätzchen gibts hier im Bordrestaurant.

Mehr als Warnen kann ich nicht. Wenn jemand wirklich voll auf FM setzt wird er früher oder später merken, was er sich da angelacht hat.

Ich habe nur schon mehrfach leidsam erfahren, was es heisst auf irgendwelche wie auch immer gearteten Abstraktionsschichten zu setzen (das letzte mal bei mir war das .NET Entity Framework und die Telerik Web-Komponenten). Der Schmerz das hinterher wieder rauszuwerfen und doch mit YAGNI selber zu machen ist jedes mal nahezu gleich groß und vermeidbar gewesen, wenn man es gleich selber mit den jeweils richtigen / nativen Tools gemacht hätte.

Wir basteln jetzt auf der Arbeit einen eigenen Datenbanklayer, weil das EF zu lahm ist und Statements generiert die die Datenbank nicht versteht und die Controls selber mit jQuery, weil die Telerik-Controls zu lahm sind und in bestimmten Kombinationen miteinander integriert grandios versagen.

Den Leuten die voll auf FM setzen werden irgendwann merken dass eine solche Abstraktionsschicht eben nur genau das ist. Eine zusätzliche Schicht mit potentiell fehlerhaftem Code (= jeder Code hat Fehler, egal von wem, siehe meine anderen Beispiele oben, FM ist eben auch keine Ausnahme), die zwar vieles kann, nicht nicht alle benötigten Use-Cases von einem selber abdeckt und dennoch mit Use-Cases die man selber NICHT braucht umgehen können müssen, und deswegen schwierig anpassbar ist.

Ich will damit eigentlich nur sagen, dass jede Art von zusätzlicher Abstraktionsschicht mist ist, und dies besonders auf Schichten zutrifft, die eine so dermaßen große Fläche wie eine komplette Plattform abstrahieren müssen. Wenn das schon bei X-Browser Webkomponenten und DB-Abstraktionsschichten zu derben Problemen führt, dann ist das Problem bei Plattformen wie sie unterschiedlicher nicht sein könnten nicht kleiner, sondern größer.

[Bernhard Geyer]

Zitat von Phoenix:

Mehr als Warnen kann ich nicht. Wenn jemand wirklich voll auf FM setzt wird er früher oder später merken, was er sich da angelacht hat.

M. E. muss man sich überlegen bei einem großen Umbau ob man sich noch Desktop-Anwendungen antun will? Wieso nicht gleich eine reine Web-Lösung.

Zitat von Phoenix:

Ich habe nur schon mehrfach leidsam erfahren, was es heisst auf irgendwelche wie auch immer gearteten Abstraktionsschichten zu setzen

Eigentlich setzt man mit Delphi zu 100% auf Abstraktionsschicht. VCL - Abstrahiert GUI-Layer. Früher BDE - jetzt ADO/dbExpress: ereinheitlich teilweise den DB-Zugriff.

Zitat von Phoenix:

... gleich selber mit den jeweils richtigen / nativen Tools gemacht hätte.

Ich denke das ist das wichtigst: Prüfe es selbst und verlass dich nicht auf Marketing-Aussagen. Trifft aber auf jedliche Komponente/Framework/... zu.

Zitat von Phoenix:

Den Leuten die voll auf FM setzen werden irgendwann merken dass eine solche Abstraktionsschicht eben nur genau das ist. Eine zusätzliche Schicht mit potentiell fehlerhaftem Code

Die Frage ist was ist konstengünstiger: Eine zwischenschicht mit Fehlern oder 4 Implementierungen mit Fehlern (Objective-C - iOS, .NET - Windows Phone, ...)