Firemonkey vs VCL

[blawen]

Ich habe kürzlich von Delphi XE auf XE5 upgedatet und bin momentan ein wenig am "spielen" mit Firemonkey.

Demnächst steht bei mir eine DB-Anwendung an, welche planmässig mindestens die nächsten 5-10 Jahre laufen soll.
Für mich stellt sich nun die Frage, auf welches Pferd ich bei einer Business-Anwendung setzen soll.

Was könnt ihr mir empfehlen?

[Phoenix]

Zitat:

Zitat von blawen (Beitrag 1248179)

Demnächst steht bei mir eine DB-Anwendung an, welche planmässig mindestens die nächsten 5-10 Jahre laufen soll.
Für mich stellt sich nun die Frage, auf welches Pferd ich bei einer Business-Anwendung setzen soll.

Komm drauf an wie 'Business' das ist. Wer ist die Zielgruppe der Anwendung? Buchhaltung oder Management? Kleinere oder größere Unternehmen?

In den nächsten 5-10 Jahren wird sich das ganze Thema auch im Business-Bereich immer mehr in Richtung Mobil / Tablet bewegen. Das Management will seine Daten immer und überall dabei haben. GUI geht immer mehr in Richtung HTML5 / CSS3 / JS. Usability-Mäßig steht eine gut(!) gemachte Webanwendung einer lokalen Applikation in nichts mehr nach. Ich würde also eher ein SPA-Framework heranziehen und das Middle-Tier als eine Sammlung von Web-Services anbieten. Darauf dann ein auch eine klassische Desktop-Anwendung als GUI anzudocken ist keine große Schwierigkeit.

[blawen]

Zielgruppe ist zum einen unsere Werkstatt (Verwaltung von internen Reparaturen) und das untere und mittlere Kader (Statistiken, etc.).
In einer späteren Ausbauphase kann es sein, dass noch externe Reparauren (ext. Kunden) eingebunden werden. In diesem Fall wird zusätzlich noch die Buchhaltung beteiligt sein.

[stahli]

Mit FMX kannst Du nicht wissen, wie weit Du kommst.
Es kann an allen möglichen und unmöglichen Ecken klemmen, bis hin zu IDE-Abstürzen (Stand jedenfalls bei XE3).
Bugs wirst Du nur durch Kauf neuerer Versionen gefixt bekommen.

Ich würde vielleicht mit FMX erste Ansätze versuchen und wenn es zu oft Probleme gibt lieber alles neu mit der VCL machen.

[Der schöne Günther]

Ich hätte auch Schwierigkeiten, mich in deinem Fall für Firemonkey auf dem Desktop motivieren zu lassen. Macs werdet Ihr da unten sicher nicht einsetzen. Und sonst? Will man das als native Anwendung auf einem iOS oder Android-Gerät umsetzen muss die Oberfläche eh neu.

Auf Windows habe ich mit Firemonkey ab und zu etwas herumprobiert, kann mich aber wirklich nicht überzeugen. Elementarste Funktionen fehlen (ganze Wörter markieren mit Shift+Strg+Pfeil, ...) oder verhalten sich anders, als man auf Windows eigentlich gewohnt ist.

Ich habe einmal versucht, eine normale DBGrid-ähnliche Anwendung in FM zu realisieren: Das Ergebis sieht man hier. Ich bin kein deprimierter Hasser, aber unter Windows kann mich das ganze wirklich nicht überzeugen.

[Headbucket]

Hallo,

seit der Threaderstellung sind nun fast 2 Jahre vergangen. Mich würde mal interessieren, ob und wie sich eure Meinung inzwischen zu FireMonkey verändert hat.

Wir stehen im Moment auch vor der Entscheidung "VCL vs FireMonkey" für ein Projekt, welches viele Jahre im Einsatz sein soll.
Multiplatform ist eigentlich kein Thema für uns.
Gibt es inzwischen trotzdem Gründe, weshalb man lieber FireMonkey anstatt VCL wählen sollte?

Bietet die VCL heute noch immer Vorteile? Läuft FireMonkey inzwischen stabiler und man stößt nicht ständig an irgendwelche Grenzen?
Wir haben etwas Angst, dass die VCL nicht mehr groß weiterentwickelt wird. Bereits in den letzten Updates gab es nur noch wenige Neuerungen für die VCL. Vllt ist sie aber auch einfach ausgereift?

Grüße
Headbucket

[jaenicke]

Wir haben VCL und Firemonkey austauschbar als Oberfläche. Beide haben Vorteile, die Firemonkey GUI hat schöne Effekte, die VCL Oberfläche ist eher im Windows 10 Stil schlicht und elegant. Von der Funktionalität her unterscheiden sich die Oberflächen bei uns nicht.

Für Firemonkey bekommst du weniger kostenlose Komponenten, wenn das eine Rolle spielt. Wenn du zum Beispiel eine erweiterte Baum- oder Listenkomponente benötigst, musst du sie für Firemonkey vermutlich kaufen während es für die VCL z.B. die VirtualTrees kostenlos gibt.

Probleme hatte ich ansonsten mit Firemonkey mittlerweile keine mehr.

[Mavarik]

Für ein neues Projekt solltest Du nicht Fragen "Firemonkey oder VCL", sondern eher Programm von GUI trennen so das der unterschied lediglich ein Paar "dumme" Formulare sind.

Da Frage muss also lauten: "Klick mich zusammen RAD oder MVVM"!

Mit Delphi 10 läuft es übrigens alles sehr stabil.

[stahli]

@jaenicke+Mavarik

Die Trennung GUI + BL ist immer sinnvoll.
Die Frage ist dann nur, wie man die Kommunikation der Ebenen löst.

Die LiveBindings lösen (falls sie zwischenzeitlich stabil laufen sollten) ja auch nur einen Teilbereich.
Mavarik, kann man inzwischen mal etwas von Deinem MVVM-Framework sehen? (Mich persönlich würde lediglich ein Video interessieren, weil ich mir FMX nicht mehr arbeite.)


@Headbucket
Wie stabil und performant FMX inzwischen läuft kann ich nicht beurteilen.
Wenn Du aber noch XE8 nutzt würde ich keine Experimente eingehen.
Wenn FMX dann nur mit aktiver Subscription.

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1329945)

Mavarik, kann man inzwischen mal etwas von Deinem MVVM-Framework sehen? (Mich persönlich würde lediglich ein Video interessieren, weil ich mir FMX nicht mehr arbeite.)

Sowie ich/wir das FDK fertig haben, kommt das alles... Tutorials & Videos stehen jedoch auf letzter Position meiner #Todo-Liste.

Zitat:

Zitat von stahli (Beitrag 1329945)

Wenn Du aber noch XE8 nutzt würde ich keine Experimente eingehen.
Wenn FMX dann nur mit aktiver Subscription.

+1

[Bambini]

Zitat:

Zitat von Headbucket (Beitrag 1329915)

Multiplatform ist eigentlich kein Thema für uns.
Gibt es inzwischen trotzdem Gründe, weshalb man lieber FireMonkey anstatt VCL wählen sollte?

Wenn es nur für Windows und Multiplatform kein Thema ist, dann ist VCL immer noch die beste Wahl.

[jaenicke]

Zitat:

Zitat von Bambini (Beitrag 1330413)

Wenn es nur für Windows und Multiplatform kein Thema ist, dann ist VCL immer noch die beste Wahl.

So allgemein kann man das nicht sagen. Hast du schon einmal mit der VCL versucht Alpha-Transparenzen oder gedrehte Texte und Controls usw. umzusetzen? Ich schon, habe am Ende alles selbst gezeichnet, da ist Firemonkey der deutlich bessere Weg...

[Rollo62]

Ich sehe es mal ganz pragmatisch:

GESTERN:
VCL ==> Windows als ==> alles wunderbar, kann ich mit etwas Glück noch 2-3 Jahre weiterbetreiben
C/S ==> TDataset

HEUTE :
FMX statt VCL ==> Windows alt /OSX/iOS/Android, wenn man es braucht (so wie ich)
C/S, Cloud ==> TDataset, Livebindings sind möglich

MORGEN :
FMX ==> Windows neu + CrossPlatform ==> Crossplatform wird sich mehr angleichen, Win neu wird man bald nicht mehr wiedererkennen
C/S, Cloud, Linux Server, interne Berechnungen ==> LiveBindings


Windows Universal App wird sicher einiges von Android/iOS übernehmen, Desktop wird weniger Wichtig.
Auch Windows Motto ist Cloud first, Mobile first ...


Ich würde jedem empfehlen sich schon heute mit FMX zu beschäftigen, läuft unter Rx10 Subscription bereits ziemlich stabil wenn man nicht
alle Exotenkomponenten anpacken muss.
Fmx ist der beste Weg für Delphianer ins neue Jahrtausend.

Jedenfalls finde ich das Konzept von FMX und sogar von LiveBindings genau richtig, auch wenn es heute noch hakelt und Emba hier
und da mal was ausprobiert.
Emba hat sich die richtigen Konzepte abgeschaut und ist meiner Meinug nach auf einem guten Weg.
Aber wer sich zu spät damit befasst dem wird u.U. der Zug wegfahren.

Das Framework ist jetzt schon sehr mächtig, und immer mehr Code wandert ins System.xxx wo es von Fmx und Vcl genutzt werden kann,
so das ich viele hingewurstelte ZusatzKomponenten wie Jedi konsequent rauswerfe und lieber ein aufgeräumtes Fmx benutze.
Immer mehr BasicCode wird da mit den richtigen Patterns umgesetzt (ExpressionParser, Tasks, Parallel, SystemInfo, PlatformServices, etc. etc.),
so dass man eigentlich kaum noch 3rd Party für den täglichen Bedarf braucht.
Da tut die Lernkurve nur einmal etwas weh, aber ich denke sehr bald in der Zukunft wird sich das wieder auszahlen:

Zitat:

Ein Code auf allen Plattformen

funktioniert wirklich, soweit ich das Bestätigen kann.
Ich fände es super wenn möglichst viele sich schon damit auseinander setzen würden statt zu resignieren,
umso schneller kann es noch besser wereden.

Denn mir ist eines völlig klar: VCL wird FMX langfristig nicht verdrängen, eher umgekehrt.
Und bald wird hier jeder nur noch mit Phones, Tablets und Smartwatches rumlaufen, da frage ich mich welche VCL App da laufen wird :wink:

Rollo

[warschonweg]

Was zu der Frage führt, wieso es noch kein Qt5 für Delphi gibt.

[Bambini]

Zitat:

Zitat von jaenicke (Beitrag 1330581)

Zitat:

Zitat von Bambini (Beitrag 1330413)

Wenn es nur für Windows und Multiplatform kein Thema ist, dann ist VCL immer noch die beste Wahl.

So allgemein kann man das nicht sagen. Hast du schon einmal mit der VCL versucht Alpha-Transparenzen oder gedrehte Texte und Controls usw. umzusetzen? Ich schon, habe am Ende alles selbst gezeichnet, da ist Firemonkey der deutlich bessere Weg...

Mit Sicherheit gibt es Bereiche die in FMX "hübscher" gelöst ist, aber auch sehr umständlich wie z.B. die Stylebooks und es fehlen weiterhin noch einige wichtige Controls, wie z.B. ein RTF Editor. Einige wenige 3rd Party Toolhersteller (TMS) springen da in die Bresche, aber der Funktionsumfang bleibt immer noch sehr hinter den VCL Möglichkeiten zurück. Viele der Toolhersteller folgen den FMX Zug überhaupt nicht, wie z.B. DevExpress oder WPTools. So gibt es z.B. für FMX Programme unter Windows immer noch keine Ribbons.
Schaut man sich mal die schickeren FMX DB Grids von woll2woll oder Devmachines an, sieht man schon an den einfachen Demos, dass das noch nicht fertig ist.

Wenn man nur für Windows entwickelt, ist VCL die erste Wahl.
Die Wahrscheinlichkeit das man mit der VCL die nächsten Windows Versionen bedienen kann - das zeigten die Jahre - ist sehr hoch.
Bei FMX steht diese Beweis noch aus ...

[Sherlock]

Zitat:

Zitat von warschonweg (Beitrag 1330588)

Was zu der Frage führt, wieso es noch kein Qt5 für Delphi gibt.

Weil Delphi auf halbwegs native Controls zugreifen kann, und nicht auf systemfremde Dinger angewiesen ist, die unbedarfte Anwender in die Irre führen. Weshalb ich auch weiterhin (für Windows) die VCL favorisiere.

Sherlock

[Bambini]

Zitat:

Zitat von Rollo62 (Beitrag 1330583)

Jedenfalls finde ich das Konzept von FMX und sogar von LiveBindings genau richtig, auch wenn es heute noch hakelt und Emba hier
und da mal was ausprobiert.
Emba hat sich die richtigen Konzepte abgeschaut und ist meiner Meinug nach auf einem guten Weg.

Gab es Livebinding nicht schon vor FMX?
Schaut man sich mal an was das standard Grid mit Livebinding an einen TDataset macht: Es erzeugt für jede Datensatz ein neuen Satz von TControls:gruebel: Ob das ein richtiges Konzept ist:gruebel:
Zumal Delphi mit seinen TDataSet-TDataSource seit Delphi 1 schon ein gutes Konzept hat?

[bra]

Was man nicht außer Acht lassen sollte, dass FMX immer noch in der Entwicklung steckt und sich immer mal wieder was ändern kann, sprich man hat immer wieder mehr oder weniger Anpassungsaufwand. Leider ändert sich auch das Design der Styles bei jeder Version mehr oder weniger leicht, was zum Teil auch Anpassungsaufwand nach sich zieht.

Bei der VCL ist halt alles nativ Windows, hier muss man nichts anpassen.

[Mavarik]

Zitat:

Zitat von bra (Beitrag 1330622)

Bei der VCL ist halt alles nativ Windows, hier muss man nichts anpassen.

Seit Windows 95 entwickele ich mit Delphi meine Software die vorher auf DOS lief...
Natürlich - wie jeder zu dieser Zeit - RAD... Butten drauf, Doppelklick code rein...
Daher stellt sich für diese Anwendung nicht mehr die Frage...

Aber hätte ich für jede Nachfrage: "Läuft das auch auf Apple" eine Mark bekommen, bräuchte ich heute nicht mehr zu arbeiten...

Das los lösen von eine direkten Verbindung zur VCL ist sicherlich das richtige Konzept... Und FMX ist auf dem besten Wege...

[bra]

Zitat:

Zitat von Mavarik (Beitrag 1330624)

Aber hätte ich für jede Nachfrage: "Läuft das auch auf Apple" eine Mark bekommen, bräuchte ich heute nicht mehr zu arbeiten...

Letztlich kommt es aber auf die Zielgruppe an. Bei uns ist der Mac z.B. kein Thema, weil nicht existent. Nur für unsere App brauchen wir halt die Multi-Plattform.

[Mavarik]

Zitat:

Zitat von bra (Beitrag 1330625)

Bei uns ist der Mac z.B. kein Thema, weil nicht existent.

Wir verkaufen mittlerweile Macbooks mit Windows, weil wir es leid waren... Die Dinger sind halt besser...

[warschonweg]

Zitat:

Zitat von Sherlock (Beitrag 1330616)

Weil Delphi auf halbwegs native Controls zugreifen kann, und nicht auf systemfremde Dinger angewiesen ist, die unbedarfte Anwender in die Irre führen. Weshalb ich auch weiterhin (für Windows) die VCL favorisiere.

Da Delphi aber den Ansatz, nur für Windows von Bedeutung sein zu wollen, aufgegeben hat, wäre doch ein "systemübergreifendes" Framework nicht verkehrt. Firemonkey statt Qt5 invalidiert meine Frage ja nicht. :?

[Mavarik]

Zitat:

Zitat von warschonweg (Beitrag 1330630)

Da Delphi aber den Ansatz, nur für Windows von Bedeutung sein zu wollen, aufgegeben hat, wäre doch ein "systemübergreifendes" Framework nicht verkehrt.

Eben...

Die Roadmap stellt ja Konsolen/Server App's für Linux in Aussicht...

Dann ist der Schritt - auch wenn ich Linux-Desktop nicht brauche, nice to have - nicht mehr so fern...

[Bambini]

Zitat:

Zitat von Mavarik (Beitrag 1330626)

Zitat:

Zitat von bra (Beitrag 1330625)

Bei uns ist der Mac z.B. kein Thema, weil nicht existent.

Wir verkaufen mittlerweile Macbooks mit Windows, weil wir es leid waren... Die Dinger sind halt besser...

Dann kann man zumindest sagen: Mein Programm läuft auf dem Mac:) ... aber ob das der Kunde gemeint hat?

[Rollo62]

Zitat:

aber der Funktionsumfang bleibt immer noch sehr hinter den VCL Möglichkeiten zurück

Vielleicht ist das auch gut so.
Keiner braucht 20 verschiedene Editcontrols.

Ok, ok, ich vermisse ein gescheites Grid auch schon lange.
Damals sagte man mir das Emba den 3rd PartyEntwicklern auch noch Luft lassen wollte.

Aber ich komme mit einem Minimalset an Komponenten erstmal wunderbar aus, und die verschachtelbaren Primitiven,
wie TCircle, TRect, TText sind super.

Wenn ich ehrlich bin benutze ich von dem ganzen TMS nur 10%, und von DevExpress nur 12%, so ungefähr.
Und habe ständig das Updatedesater bei einer neuen Version.

Da ist für mich weniger ehere mehr.

Naturlich kann es dann immer noch Spezielkomponenten geben, aber ich habe mittlerweile meine Arbeitsweise komplett geändert und versuche erstmal alles mit "Hausmitteln" zu lösen.
Ich meine ich fahre ganz gut dabei.


Funktionsumfang bleibt hinter VCL ?
- Ja natürlich, aber ich erreiche doch im Gegenzug Milliarden mehr Geräte.
Wer es niemals brauchen wird kann ja happy sein, ich habe auch noch 15 Jahre alte Schätzchen am Laufen wo ich bei
jeder neuen Win Version zittere ob ich die noch rüberretten kann.
- Minimaldesign ist in, siehe Google und Apple.
Windows wird damit kommen (siehe Edge).

Ich hoffe ja nur das nicht alle gleich die Flinte ins Korn werfen sondern offen für Neues sind.

Livebindings
- Ja ist vieles noch nicht ausgegoren, alles noch nicht ganz rund bei allen Komponenten.
Aber der Unterbau lässt hoffen, schaut euch mal von Steve Ball die Serie an mit LiveBindings per Hand zu
programmieren.
Ich glaube das wird die Zukunft sein, weil ich auch dem LB-Designer nicht 100% traue.
Aber Bindings in Code, mit vielen zusätzlichen Möglichkeiten, das könnte ich mir vorstellen.
- Ja und ja, es ist nicht mehr so einfach Drag and Drop, aber ich glaube alle (Java, JS, PHP, etc.) habens ähnlich
schwer, und es kommen doch fantastische Dinge dabei heraus.
Vielleicht ist DnD ja auch eine Sackgasse in der Delphi gefangen war ?
Man könnte ja an neuen und besseren Konzepten für Livebindings RAD arbeiten, ala TDataset unter VCL.
Ich glaube jedenfalls das dies mal kommen wird.


Rollo

[Bambini]

Zitat:

Zitat von Rollo62 (Beitrag 1330660)

Funktionsumfang bleibt hinter VCL ?
- Ja natürlich, aber ich erreiche doch im Gegenzug Milliarden mehr Geräte.

Das ist ja gerade das Problem, man tanzt auf den verschiedensten Hochzeiten, aber auf keiner mehr richtig.
Der Mac OS User will eben ein Programm das nach Mac aussieht und anfühlt und das geht zur Zeit mit FMX nur sehr begrenzt.