Für mich ist es angenehm genug.
Ich nutze
RAD für die visuellen Designs, und
versuche das Coding mit so wenig wie möglich Drag-und-Click Events zu bauen wie möglich.
Sondern schon mehr in die Richtung wo andere Frameworks schon sind.
MVVM und DI sind schwerer umzusetzen, aber diese sinngemäß einzubauen geht schon (DI sowieso).
Die Funktionalität verteile ich in kleine Units in meinem Framework, die gut wartbar und testbar sind, und bei Bedarf leicht austauschbar oder ergänzbar.
Die variablen Features versuche ich auszuklammern, so das neue Apps quasi "konfiguriert" werden können (ala braucht Location, braucht AudioOut, braucht WakeLock, etc.).
Die Basiscontrols Edit, Button, ListBox, ListView versuche ich über interposer Klassen zu Erweitern, und damit Bug-frei zu halten.
Auch gebe ich den Komponenten die manchmal fehlenden Basisfunktionen, die ich schon immer vermisst habe bei Delphi.
Die komplexeren Controls lasse ich links liegen, und baue mir bei Bedarf komplexeres aus TFrame zusammen.
Das Ganze wird von Version zu Version besser, und die Instabilitäten kommen zu 90% von den Platformen selbst, die eben auch extrem instabil sind (siehe iOS13 Einführung, schaut mal in die Apple-Foren).
Ich denke Flutter oder andere werden das grundsätzliche Problem mit den Platformen auch nicht beheben, aber womöglich schneller fixen.
Ich gebe zu das ist nicht ganz der native
RAD Ansatz mit FMX,
aber mit etwas Umstellung geht das sehr gut um bei FMX sein eigenes Framework herumzubauen.
Zitat
Baum-Darstellung
