Aufruf: Was braucht Firemonkey

[Mavarik]

Hallo Zusammen.

Gemäß meinem Vorschlag an Embarcadero greife ich hiermit den "Return" von Matthias Eissing auf und gebe es ins Forum weiter.

Frage war: "Wann werden die fehlenden Abstraktionen in Firemonkey eingebaut, damit der gleiche Code auf IOS & Android läuft"

(Mit einer Zeile. Nein Null-Zeilen... Running Gag der Delphitage)

Angeblich würde man hier auf die Community hören... Lassen wir mal so stehen...

Es war auch so eine kleine Andeutung da, dass ggf. Code "von uns" hier in Firemonkey einfließen "könnte"... Wer's glaubt...

Trotzdem möchte ich nix unversucht lassen und daher dieser Post...

Bin gespannt auf Eure Kommentare...

Mavarik

[Darlo]

Für mich wirklich wichtig:
- FireDac sollte auch auf mobilen Geräten Verschlüsselung unterstützen
- iCL, mCL und "aCL"-System benutzen

[greenmile]

Ich will doch nur einen WebBrowser für Mac; das aber schon seit XE2. Und eine vernünftige Listview.
@Embarcadero: Schaut Euch mal die mCL von TMS an. Die sind zwar Buggy, in einigen Punkten aber sowas von vorne auf dem Mac ...

[Mavarik]

Zitat von Darlo:

Für mich wirklich wichtig:
- iCL, mCL und "aCL"-System benutzen

OK Aber das macht keinen Sinn...
Klar könnte man auf jeweils der Plattform die Nativen-Controls nutzen, aber ich denke - egal wie gut die sind - das ist nicht das Konzept was hinter Firemonkey steht...

Mavarik

[Darlo]

Zitat von Mavarik:

Zitat von Darlo:

Für mich wirklich wichtig:
- iCL, mCL und "aCL"-System benutzen

OK Aber das macht keinen Sinn...
Klar könnte man auf jeweils der Plattform die Nativen-Controls nutzen, aber ich denke - egal wie gut die sind - das ist nicht das Konzept was hinter Firemonkey steht...

Mavarik

Ja, ich weiß, trotzdem wäre eine Kind-Eigenschaft wie "really true native" und "true native" wirklich schön

[Mavarik]

Zitat von Darlo:

Ja, ich weiß, trotzdem wäre eine Kind-Eigenschaft wie "really true native" und "true native" wirklich schön

So als Boolean bei einem Button oder so?

  Button1.Usenative := true;
Mavarik

[greenmile]

Für mich macht es aber Sinn. Die Firemonkey Komponenten hatten jetzt 3 Versionen lang Zeit zu reifen, seit 3 Versionen (XE2 - XE5) sind sie aber Müll, seit 3 Versionen warte ich auf elementare Komponenten, die es sehr wohl auf der jeweiligen Plattform gibt. Gut, der Müll ist weniger geworden mit jeder Version, aber es ist und bleibt Müll. Punkt. Die mCL laufen bei mir in der ersten Version bedeutend sauberer (und rund laufen sie trotzdem nicht), da wird FMX locker bis XE8 brauchen. Das ist wirklich traurig. Oder die Chance für TMS. Deshalb die Idee: Für alle Plattformen FMX. Und für Details halt native, sowas wie mCL. Dann habe ich beides.

Auf MacOS gibt es native eine coole Listview. Einen Browser. Wieso zum Henker sind die nicht in Firemonkey drin??? Und es liegt sicherlich nicht daran, dass Embarcadero davon nichts wusste, das sind häufig gewünschte Punkte. Einfach mal als Komponente kapseln, das kann doch nicht so schwer sein.

[Mavarik]

@greenmile

Müll finde ich zu hart...

Ich nenne es verbesserungsbedürftig.

Für IOS geht es ja noch aber für Android ist es echter Müll. Absolut nicht zu gebrauchen zur Zeit...(Aussage von ME: "Wir arbeiten daran. Warte auf Update 1")
Mal abgesehen davon, dass ein für IOS designtes Formular ÜBERHAUPT nicht auf Android passt...

Gleiche Codebase mag ja noch stimmen, aber auf keinen Fall gleiches Design...

Mavarik

[greenmile]

Eine Frage, die Stahli mal gestellt hat und die alles beantwortet: Wie viele wirklich professionelle Anwendungen, die mit Firemonkey erstellt wurden und die FMX Controls verwenden, gibt es? Und ich meine nicht kleine Tools sondern etwas, mit dem man Geld verdienen kann.

Ich habe es aufgegeben. Ich froh und glücklich über den Compiler und dass ich eine Form habe. Und ich bin glücklich, dass endlich Drittanbieter wie TMS was anbieten. Die Kombi ist für mich ok und die einzig sinnvolle. Denn ich will und muss Geld damit verdienen. Ich kann dem Kunden nicht sagen "Hey, wir warten auf SP1. Oder XE6. Oder XE7. Oder geht halt nicht.". Das habe ich bei XE2 getan und mir böse die Finger verbrannt.

Wieso ich überhaupt noch mitschreibe? Weil ich echt sauer bin, dass ich einen Wartungsvertrag für Delphi UND einen für Mobile Studio brauche. Obwohl sich in Delphi selbst kaum was ändert und ich es nur brauche, weil ich sonst mit dem Mobile Studio nirgendwo aufsetzen kann. Und weil ich noch zusätzlich extern Geld ausgeben muss für etwas, was ich eigentlich vom Hersteller erwarte.

===

Also mein Wunsch an Emba:

1. Ein Wartungsvertrag für Delphi UND Mobile Studio, nicht diese Abzocke
2. Die viel versprochenen Bugfixes. Sobald eine neue Version kommt, werden alte Versionen vergessen
3. Essentielle Komponenten wie nativ Listview, Webbrowser usw.

[Union]

FireMonkey ist genau wie QC: Für die Tonne. Das muss neu aufgesetzt werden. Ich wollte heute was ganz einfaches machen. Habe es nicht hingekriegt, aber 3 QC zu einem einzigen Fall erstellt. Dabei habe ich u.a. (immer noch und schon wieder) festgestellt:

• Schlüsseleigenschaften von OS-Komponenten werden hardcodiert und nicht published
• Ganz normale Bedienung führt zu SIGxxx Problemen und Verabschiedung der gesamten App
• Die "nativen" pixel-perfect Komponenten sehen komplett anders aus als bei den im Gerät vom Hersteller mitgelieferten Apps und verhalten sich auch anders.
• Die Programmierer beherrschen keine Rechtschreibung.
• Der Source wird von Kommentaren und ToDo gestrippt damit man auch ja nichts nachvollziehen kann.
• Der Source entspricht nicht dem Auslieferungszustand des Kompilats - es stecken dort Fehler drin die zu einem Compilerabbruch führen und daher nicht der Ursprung der vorhandenen dcu und bpl sein können.

Es gibt eine Schnittmenge ca. 30 Komponenten auf den verschiedenen Plattformen. Ist das zu viel verlangt dass die auch alle funktionieren?