Was ist FireMonkey?

[Peter-Pascal]

Hallo,

seit gestern bin ich stolzer Besitzer von Delphi XE2 und stoße auf den FireMonkey. Trotz einigem Text in der Hilfe und wenig im Internet bin ich daraus nicht ganz schlau geworden, was das eigentlich ist. Offensichtlich soll das Programmieren von Apps für das iPhone möglich sein; finde aber nirgends, wie ich die Apps auf mein Handy bekomme.

Dann heißt es Plattformübergreifend: Ersetzt es die VCL-Formularanwendungen?

Es gibt Monkey3D, weiß jemand wie mächtig das ist, ist das Entwickeln von komplexen 3D-Spielen praktisch in der IDE möglich? Ohne sich mit DirectX auseinandersetzen zu müssen? Oder ist das Programmieren mit der DirectX API dadurch nicht zu ersetzen?

Ich habe hier schon geschaut, ob jemand eine kleine Definition über FireMonkey geschrieben hat, bislang nichts gefunden, wenn doch, dann bitte ich um den Link.

Gruß Peter

[Bernhard Geyer]

Onlinehilfe schon durchgeschaut?

[Peter-Pascal]

Habe ich, werde aber in den wesentlichen Fragen nicht schlau daraus, inwieweit 3D-Anwendungen damit geschrieben werden können, bzw ob es die VCL-Anwendungen ersetzen soll?

[Morphie]

Ersetzen nicht unbedingt, es ist eine Alternative zu VCL.
Vorteil ist, dass FM nicht auf Win32 basiert und somit "quasi" auf jedes OS portiert werden könnte...
Die Oberfläche besteht aus Vektor-Grafiken usw, was das Erstellen von dynamischen hochauflösenden Oberflächen ermöglicht.

Als 3D-Engine oder ähnliches lässt sich das aber meiner Meinung nach nicht nutzen. Schau dir mal z.B. bei Youtube Demo-Videos zu Firemonkey an, dann verstehst du wohl schon, was das ist.

Edit: man könnte das mit WPF vergleichen...

[Peter-Pascal]

Danke, kann man sagen: erstmal abwarten, wie es sich entwickelt?

Aber schön wäre es schon, eine selbstbeschriebene App auf mein Handy zu bekommen, wie das geht, finde ich aber nirgends. (weiß allerdings auch noch nich, was mir fehlt an App)

Da fällt mir noch was ein, was ist eigentlich aus dem .net geworden? War doch auch Plattform übergreifend? Nur nicht so schön

[Phoenix]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147802)

Danke, kann man sagen: erstmal abwarten, wie es sich entwickelt?

Bisher würde ich sagen, FM ist eine totgeburt.

Zitat:

Zitat von Peter-Pascal (Beitrag 1147802)

Aber schön wäre es schon, eine selbstbeschriebene App auf mein Handy zu bekommen, wie das geht, finde ich aber nirgends. (weiß allerdings auch noch nich, was mir fehlt an App)

Erstmal brauchst Du einen Mac. Denn das, was bei Firemonkey fürs iPhone hinten rausfällt ist ein Projekt, was man dann auf einem Mac mit XCode (der IDE für Mac OSX und iOS) erst für das Gerät kompilieren muss und dann deployen kann. Dazu muss man dann auch Mitglied im Apple Developer Network sein, damit man hier Zertifikate bekommt um die App überhaupt zu deployen.[/QUOTE]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147802)

Da fällt mir noch was ein, was ist eigentlich aus dem .net geworden? War doch auch Plattform übergreifend? Nur nicht so schön

Was heisst hier 'Nur nicht so schön'? Das ist schon seit Jahren plattformübergreifend und so ziemlich die Eleganteste Methode, das wirklich zu betreiben.

Das heisst jetzt aber "Embarcadero Prism XE2", und kann neben dem alltäglichen .NET und Mono natürlich auch Windows Phone 7 und eben iOS als Zielplattform bedienen.
Die Java-Ausgabe der Sprache kann dann konsequenterweise auch Anwendungen für Android erzeugen, das ist aber ein separates Produkt direkt vom Hersteller und nicht von Embarcadero vertrieben wie Prism / Oxygene for .NET.

[Peter-Pascal]

Ist "Embarcadero Prism XE2" bei Delphi XE2 dabei? Bei Version Delphi 7 (glaube ich) konnte man noch wählen zwischen win32 Anwendung und .net.

Kann man die Meinung vertreten, wenn ich Programme für Windows schreibe, ist nach wie vor VCL-Anwendung für win32 bzw. win64 die erste Wahl?

[Bernhard Geyer]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147811)

Ist "Embarcadero Prism XE2" bei Delphi XE2 dabei? Bei Version Delphi 7 (glaube ich) konnte man noch wählen zwischen win32 Anwendung und .net.

Nee. Das gabs erst ab Delphi 2005.

Zitat:

Zitat von Peter-Pascal (Beitrag 1147811)

Kann man die Meinung vertreten, wenn ich Programme für Windows schreibe, ist nach wie vor VCL-Anwendung für win32 bzw. win64 die erste Wahl?

Nicht unbedingt. Wenn Win8 auch ARM-Prozessoren unterstützt könnte es mit VCL nicht mehr möglich sein dafür zu kompilieren.

[Phoenix]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147811)

Ist "Embarcadero Prism XE2" bei Delphi XE2 dabei? Bei Version Delphi 7 (glaube ich) konnte man noch wählen zwischen win32 Anwendung und .net.

Delphi 8 war das erste Delphi, das .NET konnte (und nur .NET). Delphi 2005 bot dann das erste mal die Wahl.

Prism ist Teil des RAD Studio XE2, so wie Delphi und der C++ Builder auch. Also nur wenn Du das Paket hast, ist Prism dabei.

Zitat:

Zitat von Peter-Pascal (Beitrag 1147811)

Kann man die Meinung vertreten, wenn ich Programme für Windows schreibe, ist nach wie vor VCL-Anwendung für win32 bzw. win64 die erste Wahl?

Ich würde Windows-Applikationen zwar auch in .NET schreiben (ist seit etlichen Jahren meine Haupt-Plattform, die ich wie meine Westentasche kenne), aber wenn es kein .NET oder Mono geben würde, dann würde ich sicher eher den Rückschritt zur VCL machen als etwas anderes zu nehmen.

FireMonkey hat als Technologie die unterstützten Plattformen nicht verstanden, was letztlich dazu führt, dass sich eine FM-Anwendung überall (auf Windows, auf dem Mac, erst recht auf iOS) falsch anfühlt.

Zum Beispiel ignoriert FM die kompletten OS-Theme-Einstellungen, was dazu führt das Personen mit einer starken Kontrast-Sehschwäche (wir haben hier zwei Kollegen, die haben TV-Große Bildschirme und massive Schriftgrößen) diese Anwendungen gar nicht bedienen können. Das ist ein absolutes No-Go.

[Peter-Pascal]

Danke, verstehe jetzt einiges besser

[Darlo]

Zitat:

Zitat von Phoenix (Beitrag 1147807)

Bisher würde ich sagen, FM ist eine totgeburt.

Das sehe ich bisschen anders, im schlimmsten Fall eine Frühgeburt.
Ich bin relativ begeistert und in Hoffnung, dass fehlende Funktionen zeitnah implementiert werden.

Gruß

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1147898)

Zitat:

Zitat von Phoenix (Beitrag 1147807)

Bisher würde ich sagen, FM ist eine totgeburt.

Das sehe ich bisschen anders, im schlimmsten Fall eine Frühgeburt.
Ich bin relativ begeistert und in Hoffnung, dass fehlende Funktionen zeitnah implementiert werden.

WEnn FM eine Totgeburt sein soll, was war dann VCL.NET bzw. CLX?:gruebel:

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147904)

WEnn FM eine Totgeburt sein soll, was war dann VCL.NET bzw. CLX?:gruebel:

Genau das gleiche. Die CLX war kurz vor meinem richtigen Delphi-Einstieg - ich hab da ja nur das Ende von mitbekommen, aber dass die VCL.NET nix wird hab ich gleich gesagt.

[Peter-Pascal]

Es ist schwer abzuschätzen, was sich durchsetzen wird. Meines Erachtens nach hat sich VCL mit Win32 (Win64 ist hoffentlich identisch) bewährt. Der FireMonkey klingt sehr interessant, aber so richtig weiß ich nicht, wofür ich ihn brauchen soll. Irgendwo steht für Geschäftsanwendungen, das kann ich mir am allerwenigsten vorstellen.

Bislang bin ich etwas enttäuscht von Delphi XE2, denn wer sich nicht für den FireMonkey interessiert benötigt diese Version eigentlich nicht. Denn sonst habe ich nicht viel Neues in Delphi entdeckt, oder?

[Bernhard Geyer]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147910)

Bislang bin ich etwas enttäuscht von Delphi XE2, denn wer sich nicht für den FireMonkey interessiert benötigt diese Version eigentlich nicht. Denn sonst habe ich nicht viel Neues in Delphi entdeckt, oder?

Ist die Möglichkeit 64-Bit Apps zu erstellen nichts was man brauchen könnte?
Oder das man Theming-Support hat ohne auf 3th-Party kompos zurückgreifen zu müssen (ElPack unterstützt mit letzten Build auch die XE2-Eingebaute Theming-Engine)?

Also es sind schon einige Sachen die ein Update lohnen. Wenn man natürlich all diese Features nicht benötigt das benötigt man vermutlich auch kein XE2.

[Peter-Pascal]

Da hast Du sicherlich recht, insoweit ist mein Urteil überzogen. Allein die verbesserte Installation von VCL-Komponenten ist schon eine Erleichterung. Ich habe viele Komponenten. Und da bald ein 64-Bit PC ansteht, ist genau das auch der Grund für ein Update.

Was ist Theming bzw. Theming-Engine?

[Daniel]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147913)

Was ist Theming bzw. Theming-Engine?

Bunt. Und mit Farbe:
http://theroadtodelphi.wordpress.com...styles-part-i/
http://theroadtodelphi.wordpress.com...tyles-part-ii/


Es geht dabei darum, einer VCL- oder FireMonkey-Anwendung ein komplett anderes Design verpassen zu können.

[Bernhard Geyer]

Zitat:

Zitat von Peter-Pascal (Beitrag 1147913)

Und da bald ein 64-Bit PC ansteht, ist genau das auch der Grund für ein Update.

Das eigentlich nicht. Unser D6 läuft wunderbar unter Win7-x64 :-)

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147917)

Das eigentlich nicht. Unser D6 läuft wunderbar unter Win7-x64 :-)

Es geht nur um die wenigen Projekte, welche wirklich mal mehr als 2-3 GB RAM benötigen.
Und um Plugins/DLLs, welche in andere Prozesse rein sollen, welche 64 Bit ist ... mit einer 32 Bit DLL kann man in einer 64 Bit App nichts anfangen.

Aber ansonsten ist alle davor nutzbar, jenachdem welche Features man gerne nutzen möchte.
Wer will, der kann auch ganz gerne noch mit D2 arbeiten. (nur D1 ist seit Win7 x64 nicht mehr nutzbar, da keine 16 Bit mehr unterstützt werden)

[bernau]

Zitat:

Zitat von Phoenix (Beitrag 1147807)

Zitat:

Zitat von Peter-Pascal (Beitrag 1147802)

Danke, kann man sagen: erstmal abwarten, wie es sich entwickelt?

Bisher würde ich sagen, FM ist eine totgeburt.

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. Es hat sich doch eingebürgert, daß viele Programme ein eigenes aussehen bekommen und nicht die Windows-Themes übernehmnen. Ich wünsche nur, daß die Bugs entfernt werden. Dann wird Firemonkey die Grundlage aller meiner (neuen) Programme werden.

Daumen hoch für Firemonkey.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1147919)

Wer will, der kann auch ganz gerne noch mit D2 arbeiten. (nur D1 ist seit Win7 x64 nicht mehr nutzbar, da keine 16 Bit mehr unterstützt werden)

Delphi 2007 sollte es schon sein, damit die gröbsten Fehler, die seit XP und vor allem Vista auftreten, behoben sind. Wobei ich schon gesehen habe, dass es bei mit Delphi 7 geschriebenen Anwendungen auch mal zwei Versionen gibt: bis XP und ab Vista. Und das nur wegen der bis Delphi 2005 fehlerhaften Randberechnung. ;-)

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1147919)

Es geht nur um die wenigen Projekte, welche wirklich mal mehr als 2-3 GB RAM benötigen.
Und um Plugins/DLLs, welche in andere Prozesse rein sollen, welche 64 Bit ist ... mit einer 32 Bit DLL kann man in einer 64 Bit App nichts anfangen.

Wir hatten schon den ersten Kunden mit dem Wunsch (Anforderung?) das wir doch bitte die Apps in 64-Bit bereit stellen sollten. Er will eigentlich nur noch 64-Bit Anwendungen einsetzen auch wenn hier kein Vorteil gegeben wäre. :roll:

Zitat:

Zitat von himitsu (Beitrag 1147919)

Aber ansonsten ist alle davor nutzbar, jenachdem welche Features man gerne nutzen möchte.
Wer will, der kann auch ganz gerne noch mit D2 arbeiten.

Das D2 noch keine COM/ActiveX-Unterstützung hatte würde man hier doch mittlerweile auf viel Verzichten.

[Darlo]

Zitat:

Zitat von bernau (Beitrag 1147930)

Daumen hoch für Firemonkey.

:thumb:

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:

Zitat von Darlo (Beitrag 1147953)

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

Zitat von bernau (Beitrag 1147930)

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:

Zitat von Darlo (Beitrag 1147953)

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:

Zitat von Phoenix (Beitrag 1147970)

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!

[bernau]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

Deswegen sagt Marc ja auch

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

GD&RVF

[jaenicke]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Bei beiden habe ich bisher eher eine andere Erfahrung gemacht. Beim Mac ging es fast allen, die ich kenne (gut, sind nur 14 Leute) nur darum, dass erstens ein Apfel drauf ist, weil es cool ist und zweitens darum, dass man sich um nicht viel kümmern muss und es einfach läuft.
Und bei Linux höre ich eher, dass die Oberfläche zwar nicht schön aussieht, aber einfach nur funktioniert und genau das auch das wichtigste ist. sprich: Wie es aussieht, ist egal. Daher ja auch der Ausdruck "Klickibunti" für Windows.

Ich weiß nicht woher du deine Ansicht hast, aber mit denen der Personen, die ich kenne, stimmen diese absolut nicht überein.

Und was FireMonkey angeht:
Wir werden ziemlich sicher mittelfristig in der Firma auch in diese Richtung gehen, aber das erfordert natürlich erst einmal viel Planung.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Nein, dass es überall gleich "aussieht" ist ein Problem.

Das es überall gleich aussehen muss ist für manchen (Firma, Cooperate Design - "Unsere Webseite hat Lila als Hauptfarbe - wir wollen auch Lila Buttons") ein Problem.
Und wie ich sehe kann man bei FM auch ohne Custom-Theme arbeiten. Wenn hier der native Look nur (gut) Emuliert wird - was solls. Solange diese Emulation nicht permanent 100% CPU-Load verursacht ...

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Es benutzt keine nativen API's.

Ega. Solange es sich gut anfühlt.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC.

Und was macht das anders aus? Das man nur eine Maustaste hat und bald mit 200 Fuchtel-Gesten den Mac bedient? Ich denke 90% der User werden nicht konkret die Unterschiede die von vorteil sind bis auf allgemeine Aussagen definieren können. Und diese Aussagen werden sich primär auf das OS und nicht auf eine Anwendung beziehen.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Und. Sollen sie doch. Wenn diese 1% der PC-Gemeinde (die oft auch nur kostenlose open-source Lösungen akzeptiert) mein Programm nicht will - was solls.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen.

Das Akzeptier ich. Sie darf sich nicht als Fremdkörper anfühlen (So wie manche Adobe-SW heutzutage auf Windows). Aber ob sie nun native API's verwendet um einen Button zu zeichnen oder nicht - wird bis auf Technikverliebte keinen Interessieren. Es wurde doch auch schon ein paar FM-Apps für iOS gezeigt und sie sahen nicht schlecht aus.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Diese 100% Garantie sehe ich nicht.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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?

Ich denke nicht das de Fragesteller einen Browser für eine "Oberflächen-Loses" System haben will. Und TWebBrowser hätte bei einer Delphi-Consolenanwendung auch nix verloren.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Und wieder Anfangene für jede Plattform eigenen Code zu schreiben (und zu pflegen) Objective-C für iOS, .NET für Windows Phone, Java/Dalkin für Android und dann nach Delphi für Win32.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

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?

[Phoenix]

Zitat:

Zitat von TiGü (Beitrag 1147974)

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:

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:

Zitat von Bernhard Geyer (Beitrag 1147983)

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:

Zitat von Phoenix (Beitrag 1147985)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147983)

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:

Zitat von Daniel (Beitrag 1147987)

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

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147970)

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:

Zitat von Phoenix (Beitrag 1147998)

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:

Zitat von Phoenix (Beitrag 1147998)

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:

Zitat von Phoenix (Beitrag 1147998)

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

Zitat von Phoenix (Beitrag 1147998)

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:

Zitat von Bernhard Geyer (Beitrag 1148010)

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:

Zitat von Darlo (Beitrag 1148052)

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:

Zitat von Darlo (Beitrag 1148052)

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:

Zitat von Darlo (Beitrag 1148052)

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