Plattformübergreifend - Augenauswischerei ...?

[Uwe Raabe]

Kurz gesagt, wenn du auf DevExpress quasi festgelegt bist, dann musst du bei VCL bleiben. Plattformübergreifend geht bei Delphi mit bordeigenen Mitteln aber nur mit FMX. Selbst das als Zusatzprodukt verfügbare CrossVCL, mit dem VCL-Anwendungen mit Delphi auch für MacOS erstellt werden können, hat die Unterstützung von DevExpress mittlerweile eingestellt.

Natürlich kann man mit Delphi auch für MacOS entwickeln. In der Regel sind aber bestehende VCL-Programme bezüglich des User Interfaces komplett neu aufzubauen. Meistens kommt das einer kompletten Neuentwicklung schon sehr nahe.

[philipp.hofmann]

Wenn man von Anfang an mit FMX mit dem Ziel plattform übergreifend entwickelt, bietet Delphi da einem sehr viel, da bin ich eigentlich recht happy und nutze zusätzlich relativ viele TMS-Komponenten. Eine Portierung eines VCL-Projektes ist aber eine ganz andere Geschichte.

[Phoenix]

Wenn Du wirklich echte zukunftsfähige Cross-Plattform Anwendungen bauen willst, dann bist Du mit allem Nativen auf dem Holzweg. Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.
Wir machen das seit mehr als 10 Jahren extrem erfolgreich. Wir haben schon viele andere Ansätze gesehen und auch Kunden gehabt die das nicht glauben wollten und es anders versucht haben. Davon sind ausnahmslos alle gescheitert.

Oder andersum gesagt, wenn Du etwas für eine Plattform bauen willst, nimm am besten ausschließlich Tools dafür, die auch auf dieser Plattform laufen.
Willst Du für den Mac bauen, nehme Tools die auf dem Mac tun. Willst Du für Mac und Windows bauen, nehme Tools die auf Mac und Windows tun. Willst Du für Mac, Windows, Linux, Android und iOS bauen, nehme Tools die überall dort laufen. Wenn (komplexes) Entwicklungstooling dort läuft, kannst Du davon ausgehen dass auch Deine Anwendung die damit gebaut ist dort tut.

Unser Stack ist Angular fürs Frontend und .NET auf dem Backend, aber alles was JS/TS ist (React, Vue etc.) wird vorne tun und hinten kannst Du gerne auch JS/TS nehmen (Node) wenn Du nix besseres haben willst

[Rollo62]

Zitat von Phoenix:

Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.

...

aber alles was JS/TS ist (React, Vue etc.)

Damit bin ich im Prinzip völlig mit einverstanden, nur JS ist wirklich völlig plattformübergreifend.

Nur leider komme ich jedes Mal, wenn ich wieder etwas Neues/Hybrides austeste, ganz schnell an irgendwelche Grenzen.
Solange man Web-Zentrierte Apps baut, die nicht viel von der Hardware oder von den Mobil-Spezialitäten nutzen, dann mag das OK sein.
Sobald man Location, Background-Modi, Bluetooth, Sensoren, Audio, Mail, SMS, PhoneCall, Mikrofon, SpeechRecognition, usw. usw. usw. braucht,
dann gibt es mit Web-Technologie oft noch mehr Beschränkungen als rein nativ.

Egal ob Flutter, React oder Xamarin, ich finde oft sehr viel ähnliche Beiträge in den Foren dort, wo es genauso wenig Lösungen gibt wie bei Delphi.
Zuletzt hatte ich bei Flutter gesucht, wo geschrieben stand: Ja, geht im Prinzip, da gab es diese OpenSource Library ( allerdings nur ein proof-of-concept, ungepflegt), aber offiziellen Support gab es nicht.
Ok, die Entwicklung geht da natürlich rasant immer weiter, aber ein kompletter No-Brainer ist IMHO keine dieser Technologien.

Das Problem ist ja mehr politischer Natur, wenn der Zugriff durch Google/Apple unnötig verkompliziert und restriktiver gemacht wird, ohne Rücksicht auf Verluste.

Deshalb ist Delphi gar nicht so verkehrt, für solche Anwendungen.
Und bei den ganzen obskuren Problemen, die mir untergekommen sind, wenn ich dann mal über den Tellerrand schaue:
Auch Xamarin, Unity, React, Flutter, NetMAUI, ja sogar XCode und Android-Studio selbst, haben oft die gleichen Probleme an die Hardware zu kommen.

Ich würde mir wünschen, einfach nur eine App mit einem DB-View machen zu müssen, eventuell noch mit REST-API,
aber meistens kommt dann doch noch sehr viel obendrauf.

[jik]

Zitat:

himitsu schrieb: Weil du kein Bild dafür hochgeladen hast
Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

Genau dorthin würde ich gern, aber ich finde es beim Profil nicht (siehe hier) und außer neben Willkommen, xyz finde ich nichts. Seltsamerweise konnte ich früher mal das Bild einfügen, kann es jetzt aber nicht mehr ändern. Und Signatur finde ich auch nicht.

Zitat:

jaenicke schrieb: Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt.

Bei plattformübergreifend vermutlich schon. Wir hatten uns selbst seinerzeit eine Schnittstelle zu Pervasive (live und SQL) geschaffen mit abgeleiteten Komponenten. Das war auf jeden Fall angenehmer, als Daten und GUI komplett zu trennen. So hatten wir eine Applikation, aber die wurde dadurch etwas krakelig.

Zitat:

Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

Meines Wissens ist TVirtualStringTree plattformübergreifend. Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern. Diesbezüglich war die Treelist von Developer Express optimal. Für eine gescheite TreeView würde ich auch gern was zahlen. Ist die von TMS nicht so etwas?

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

[jaenicke]

Zitat von jik:

Meines Wissens ist TVirtualStringTree plattformübergreifend.

Die von Lazarus wohl ja, inwieweit weiß ich nicht. Und die FMX Version wohl auch, aber die ist noch nicht so weit. Das Hauptprojekt ist rein für Windows.

Zitat von jik:

Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern.

Seit Generics unterstützt werden braucht man direkt keine Pointer mehr (fand ich allerdings auch nicht schlimm). Und Records muss man auch nicht nutzen. Ich habe die Komponente meistens generisch mit Klassen verwendet. (Vor der offiziellen Unterstützung hatte ich die Generics selbst drüber gebaut.)

Zitat von jik:

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Weil du unter den mobilen Plattformen keinen länger laufenden Code in einem Buttonklick drin haben darfst. Unter Windows ist das nur unangenehm für den Benutzer, unter Android oder iOS kommst du mit solch einem Code nicht in den AppStore.

[bernhard_LA]

ich hatte die (Sisyphos-)Aufgabe vor einigen Jahren unsere Anwendung auch unter LINUX bereitzustellen. Ca. 1 Mio Zeilen Quellcode alles mit VCL programmiert und keine TestCases.
Die Strategie für Cross-Plattform bei uns:

• GUI Code von BL-Logik Trennen ....
• Code Refaktoring nch MVVM (https://de.wikipedia.org/wiki/Model_View_ViewModel) oder vergleichbaren Ansatz
• beide Plattformen unterstützen über compiler switches ( dann kann man immer auf die lauffähige VCL Version zugreifen)
• testcase einführen wann immer es geht
• zu allen Überfluss haben wir auch 2 DB Interface in der Compiler Switch Option {$IFDEF Framework_ADO } und {$IFDEF Framework_Firedax }

Delphi-Quellcode:

uses
  types,
  classes,
  SysUtils,
{$IFDEF FrameWork_VCL}
  vcl.Graphics,
  .....
{$ENDIF}
{$IFDEF FrameWork_FMX}
  FMX.Graphics,
  .....
{$ENDIF}



....

[Mavarik]

Zitat von jik:

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Ganz einfach...

Die Style-Animationen in FMX werden über "Timer" gelöst. Diese laufen nur, wenn die Ausführung in der Application-Loop läuft.

Wenn Du also - damit der User nicht 2x auf einen Button klickt - den Button disablen willst, wird es erst dargestellt, wenn die Ausführung wieder in Application-Loop läuft.

Im OnClick

• Button disablen
• Thread starten
• Am Ende von Thread eine Queue-Proc und darin den Button wieder enablen.

Oder einfach den Idleworker aus meinem FDK verwenden.

Wenn der Application.OnIdle event feuert, ist alles auf dem Bildschirm gemalt und Du kannst andere Sachen machen.

Mavarik

PS.: Nicht so "tragisch" auf FMX_Windows.