Was ist FireMonkey?

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

[Phoenix]

Zitat von Bernhard Geyer:

Echt? Beispiel? Schaut gleich aus und lässt sich gleich bedienen. Oder hatte die FM-Version aufgrund der noch vorhandenen Einschränkungen doch einige Visuelle und Spürbare Nachteile?

Nicht hatte sondern hat. Ich sag nur generelles Layout und Slider...
Das Ding fühlt sich tatsächlich eklig an, reagiert blöd bis zum Teil gar nicht (weil das Control mist ist) und ist zudem noch rotzlahm beim Startup. Und das auf einem 4S.

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

[Bernhard Geyer]

Zitat von Phoenix:

Zitat von Bernhard Geyer:

Echt? Beispiel? Schaut gleich aus und lässt sich gleich bedienen. Oder hatte die FM-Version aufgrund der noch vorhandenen Einschränkungen doch einige Visuelle und Spürbare Nachteile?

Nicht hatte sondern hat. Ich sag nur generelles Layout und Slider...
Das Ding fühlt sich tatsächlich eklig an, reagiert blöd bis zum Teil gar nicht (weil das Control mist ist) und ist zudem noch rotzlahm beim Startup. Und das auf einem 4S.

Das ist aber ein Implementierungsfehler/-mängel. Wenn die Controls solche schlechte UserExperience haben dann ist nicht grundsätzlich die Idee dahinter falsch.
Die Realisierung muss "nur" besser werden. Kann man evtl. mit den ersten Jahren bei Java und GUI-Bibliothek vergleichen. Am Anfang waren sie entweder langsam oder zu unflexibel. Mittlerweile kann man aber mit Swing Apps erstellen die sich nicht von normalen Win32-Apps unter Windows, Mac-Apps unter MacOS, ... unterscheiden. Die Frage ist aber ob Sie das hin bekommen oder nicht wieder nach kurzer zeit aufgeben. Aber wie schon mal gesagt. Ein nochmaliges Aufgeben einer Multi-Plattform GUI wäre der entgültige Tod für Delphi - Vor allem da ja bald Windows auf ARM kommen soll ...

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

[Darlo]

Zitat von Phoenix:

Die Anforderung nach Webbrowser und Mediaplayer ist dann auch gleich wieder ein Zeichen, dass die Technologie hinter Firemonkey nicht verstanden wurde.

Danke. Sehe ich zwar anders, habe bei solchen Aussagen aber keine Böcke näher drauf einzugehen.

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

Das kann ich wiederlegen. Gerade weil die Anwendung unter Windows, OS X und iOS gleich aussieht und einige nette Spielereien machbar sind, entwickeln wir gerde eine individuelle Lösung für mehrere tausend User.

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.

Und viele Windows nutzer freuen sich wenn man eine Software wie einen Mac/iPad bedienen kann. Mit Firemonkey kann man einen sehr guten Mix für alle OS erzielen.

Das ist meine Meinung, bin für andere Ansichten offen, aber wenns geht nicht gleich angreifend werden.

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

[Stevie]

Zitat von Bernhard Geyer:

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

Und die Entwickler, die sich mit allen davon gleich gut auskennen

[Darlo]

Glaubensdiskusion hin oder her. Aber warum ist Java den so verbreitet? Bestimmt nicht weil es performant, optisch schön und dazu noch ne übersichtliche Sprache ist.

[Bernhard Geyer]

Zitat von Darlo:

Glaubensdiskusion hin oder her. Aber warum ist Java den so verbreitet? Bestimmt nicht weil es performant,

Java ist nicht langsamer als Delphi. Aufgrund der GC kann es auch teilweise schneller sein. In der c't gabs mal performance-Tests zwischen C++/Java/Delphi und C#.

Einfaches Fazit: Nur bei Numbercrunshing war C## schneller.
Bei allen anderen Dingen, vor allem bei Grundkonzepten von OO war C++ letzter und die anderen drei Sprachen ähnlich schnell.

Zitat von Darlo:

optisch schön

Wie soll eine Programmiersprache optisch schön sein? Wenn du damit erzeugte GUI's meinst. Mit Swing kannst du problemlos Apps erstellen die genauso schön oder hässlich sind wie Delphi/C++/...-Anwendungen. Dieses Vorurteil hält sich weil bei vielen (kostenlosen opensource-apps) einfach nicht viel zeit auf eine schöne GUI gelegt wird.

Zitat von Darlo:

und dazu noch ne übersichtliche Sprache ist.

Ok. Es gibt einige Sprachefeatures die ich bei Delphi schöner finde. Vor allem Properties vermiss ich (Jedesmal setXX und getXX aufzurufen finde ich blöd).