TFrame vs. TForm als View verwenden

[Rollo62]

Hallo zusammen,

wie steht ihr zu der Form/Frame Frage bei CrossPlatform (Win, OSX + Mobile).

Es gibt zwar Threads zu Vcl, aber was gilt bei Mobile ?
http://codeverge.com/embarcadero.del...ich-on/1044015

Ich möchte Forms/Frames als Designer nutzen, und dann als View in mobilen Clients anzeigen.
Im Moment habe ich mehrere Forms als View in Panels geladen, und schalte diese im TabControl um.

Das funktioniert sowiet gut, aber ich stosse immer auf mysteriöse Probleme, so das ich mich Frage was wohl
der "richtige" Weg ist um verschiedene Views umzuschalten.

Es gibt auch den schönen TFrameStand Ansatz, allerdings habe ich mein Projekt noch nicht umgebaut.
Im Demo funktioniert das aber ganz genauso wie ich es mir vorstelle und wünsche (basiert aber auf Frames).
Und es nutzt auch das StyleBook sehr schön um die grafische UI zu entkoppeln.

Weil ich in älteren Delphi Versionen mal Probleme mit Frames hatte sträube ich mich noch etwas dagegen.

Im Prinzip möchte ich meine Views sowiet wie möglich entkoppeln, und per RegisterView im System bekannmachen
und über Messages kommunizieren.
So das alle Views möglichst separat lauf- und testbar bleiben.
Deshalb ist mein jetziger TebControl Ansatz nicht optimal.

Also wer kennt sich gut aus mit Vor- Nachteilen von Frames/Forms in mobilen Clients ?

Rollo

[mensch72]

Da ich "MultiView" nicht mag und ich etwas in dieser Richtung schon vorher brauchte, verwende ich Frames, welche ich im FMX-Mobile wegen des "StandAllone-Designs" mag(Tab/Page-Control mag ich garnicht und "ClientForms auf TabParent" gibt es nur im VCL-Windows).

Mein Mobil APP Style ist nicht sonderlich schön, aber sehr praktisch. Im Prinzip immer ein mehrfachverwendbarer quadratischer "Funktionsbereich" (ein Frame) und das für Hoch oder Quer jeweils auf 2 separaten Forms mit "Button Menu" oder "ListView" daneben oder darüber. Im TabletMode je nach Bedarf auch noch mit einer 2. Master/Detail-Liste. So komme ich mit 4 bis 6 Forms aus, für welche ich die GUI "separat" realisiere (in den Events möglichst nur "SharedCode" aufrufen).
=> Da trennt man automatisch sehr sauber in Design&Funktion, um in den eigentlichen Forms ausser den Aufrurufen in den "Events" quasi NULL Funktion zu haben
=> Das ist unter FMX sogar relativ schnell, weil immer nur die GUI Elemente "einer Ansicht" im Form sind (bei SingleForm mit PageControl werden es pro Tab immer sehr mehr!)
=> ja das widerspricht völlig dem "ResponsiveDesign" Konzept, wo man mit 1x die GUI Verteilung/Scalierung realisieren will/soll
=> ich bin aber so schneller, wenn es um die einfache und schnelle Unterstützung für ein exotisches Screenformat geht (z.B. MiniQuadrat bei SmartWatches oder bei "optimalen" 4:3/16:9/16:10 Tablet bzw. Car-Apps)

Um die "Formumschaltung" beim drehen kümmere ich mich absichtilich selbst, weil wenn ein aktiver Vorgang(Scan per Thread für XXX) läuft, dann sperre ich das drehen und bleibe im aktuellen Layout. Wenn nix aktiv ist, dann schalte ich beim drehen auf das passende Layout, bzw. passe ich dieses bei Bedarf auch beim Einblenden einer statischen Bildschirmtastatur an.

Wer das alles mit MultiView "DesignTime sicher" und in RunTime vollautomatisch mit MultiView hinbekommt, den beglückwünsche ich. Ich schaffe es nicht.
Das man bei Frames abundzu mal den Frame ContainerForm/ContainerTab löschen und neu einsetzen muss, daran habe ich mich gewöhnt und kann seit XE7 gut damit leben.

[Rollo62]

Hallo mensch72,

dankesehr für die Info.

Im Prizip möchte ich ähnliches machen, ich verstehe aber dein "quadratisches" Konzept nicht ganz.
Ich denke man das man durch Align.Client auch immer ein responsive Design hinbekommt, und nur ein Sonderfällen
mal wirklich 2 separate Forms/Views braucht.

Mit dem TabControl hatte ich auf dem Desktop wenig Probleme.
Das ist für mich praktisch weil ein View of SubViews bracht, z.B. zur Eingabe oder Anzeige von speziellen Werten.
Da nehme ich gerne ein TabControl ohne Tabs als container und schalte das manuell um.
Im mobilen Clients muss ich dann aber die schöne "Slide" Funktion der Tabs abschalten, weil die intern
Applikation.ProcessMessages benutzen (ja bei Delphi ist das anscheinend noch nicht ganz Tabu).

Nach deinem Konzept sitzt aber jedes Frame noch auf einer Form, richtig ?
Mir ging es auch darum ein möglichst Lightweigt Design aufzubauen, weil ich schonmal an Speichergrenzen
gestossen bin.
Im Memory von iPhone gibt es ab 50MB RAM-Usage mögliche Probleme mit Out-of-Memory.
Deshalb baue ich meine Views immer Auf und Ab.
Da scheinen mir Frames und Forms nicht so ideal, weil diese viel Overhead mitbringen den man nicht braucht.

Ich habe auch schon an einen Container aus TLayout gedacht, in dem alle Controls drinsind.
Im Prinzip würde das reichen, und was da drin ist sollte keine Rolle spielen (TabControl, Frame, etc.).
Aber dann fällt das praktische RAD Editieren der Forms weg, und man muss alle Controls per Hand erzeugen
(vielleicht ist das sogar der bessere Weg für sauberes Design, und RAD ist nur eine Illusion ...).

Beim Umschalten hast du vollkommen recht, das kann man nicht automatisch machen (ich zumindest).
Denn nicht alle meine Views sind für responsive gedacht, also muss ich je nach View entscheiden.
Ich schalte dazu vorher Portrait oder Landscape, oder eben beides ein.

Weil ich mich auch mit LiveBindings und Datasets auseinandersetzen musste habe ich das Problem
beim Auf und Abbbau der Forms/Frames, das es etwas dauern kann.
Wenn ich zentral die Datenbank in einem separaten Modul habe und Views anzeige braucht es trotzdem
eine sichtbare Verzögerung bis die geladen werden, egal ob LiveBindings, oder von Hand.

Mit dem Formsaufbau habe ich auch keine Probleme, das geht auch auf alen Plattformen schnell genug,
aber schon eher mit Speicher und anderen Mobilespezialitäten wie Toches.
Lässt du deine Frames denn alle über die Laufzeit im Speicher, oder baust du die jedesmal Auf und Ab ?
Vielleicht bin ich auch etwas zu übervorsichtig geworden durch meine ganzen obstrusen iOS Probleme


Rollo

[Mavarik]

Crossplattform?

Unter iOS&Android kann ich immer FormCreate-FormCreate usw... Machen die werden alle schön übereinander gestapelt... Die gleiche App läuft dann leider nicht so unter Windows & OSX...

Also einfach eine Form nehmen darauf eine Scrollbox (Für die Tastaturüberlappung) darauf ein oer mehrere Layouts...

Alle Forms normal designen und dann FormCreate ohne Show und dann den Parente einfach auf das gewünschte Layout setzen...

Fertig...

Keine Formvererbung, Multiviewdesigner usw... Alles nicht nötig... (Funktioniert mit jeder Delphi Version)

Mavarik

[bra]

Ein Problem mit den TFrames ist, dass man hier für die unterschiedlichen Plattformen den Style im Designer nicht sieht. Man kann also nicht zwischen Windows/Android/iOS umschalten und hat als stylelookup für Elemente (z.B. Buttons) nur sehr eingeschränkte Auswahl - man muss das also quasi blind machen und dann schauen, wie es am Gerät aussieht.

Ist vielleicht nicht ganz so wichtig, macht aber das ordentliche Designen leider schwieriger.

[Rollo62]

@Mavarik,

hattwst du noch keine Probleme mit RAM Speicher gehabt bei grösseren Projekten ?
(Mit grösser meine ich lediglich > 6 Forms + Sqlite DB).

Ich lade die TForms in Panels, weil ich mal die irrige Vorstelung hatte man könnte jetzt dank
GPU Unterstützung wunderbar alles Sliden und Bewegen, und so die eingebetteten Forms cool anzeigen.
So ähnlich wie JavaScript das im Browser schon immer konnte.
Das geht ja auch bis zu einem gewissen Punkt, aber dann ruckelt es wenn man nicht höllisch aufpasst.

Leider werden bei meinen eingebetteten Forms die Basic-Events nicht mehr gefeuter FormShow, FormResize, etc.
so das man immer etwas drumherum basteln muss.
Das wäre nicht das Schlimmste, ist aber natürlich ärgerlich.


@bra
Das ist ein wichtiger Punkt, denn ich möchte Forms/Frames ja benutzen um möglichst beim RAD Konzept im Designer
zu bleiben.
Wenn ich nicht mehr sehe was ich zusammenbaue kann ich das gleich manuell von Hand machen.
Wie gesagt, ich könnte mir ein Konzept wie TFrameStand gut vorstellen, wenn der StyleBook Designer mal
die Qualität von der IDE erreicht.

Ich habe auch schon versucht separat auf einer Form zu designen, zum Beipiel alles auf einem zentralen Panel,
und dann einfach das ganze Panel Copy und Past in das eigentlich Projekt.
Auch das geht wenn es keine Namenskonflikte gibt, aber dann sind alle Events weg.

Eigentlich sollte der StyleDesigner genau das leisten, z.B. einfach mal die Farben und Icons ändern.
Aber auch damit hatte ich soviel Probleme das ich letzendlich um fertig zu werden mittlerweile TRectangle dahinterstelle, und das kann ich prima einfärben.

Daher spricht dein Argument eher gegen TFrame und für TForm, so wie ich es jetzt nutze.


Rollo

[Mavarik]

Zitat von Rollo62:

@Mavarik,

hattwst du noch keine Probleme mit RAM Speicher gehabt bei grösseren Projekten ?
(Mit grösser meine ich lediglich > 6 Forms + Sqlite DB).

Ich lade die TForms in Panels, weil ich mal die irrige Vorstelung hatte man könnte jetzt dank
GPU Unterstützung wunderbar alles Sliden und Bewegen, und so die eingebetteten Forms cool anzeigen.
So ähnlich wie JavaScript das im Browser schon immer konnte.
Das geht ja auch bis zu einem gewissen Punkt, aber dann ruckelt es wenn man nicht höllisch aufpasst.

Leider werden bei meinen eingebetteten Forms die Basic-Events nicht mehr gefeuter FormShow, FormResize, etc.
so das man immer etwas drumherum basteln muss.
Das wäre nicht das Schlimmste, ist aber natürlich ärgerlich.

6 Forms & Speicher?

Ich habe 30 Forms... Sind aber "nur" Container... Beispiel: Listbox hat keine Items... Die erzeuge ich per zentrale Routine die je nach Plattform alles "richtig" macht...

Animationen "darfst" Du nur im Application.OnIdle machen... da nur so sichergestellt ist, das der UI-Thread die volle "power" für die Animation hat.
Denn die Animationen laufen per Timer!

FormShow usw. brauche ich ja auch nicht... Wenn ich den Parent setzen weiß ich das doch...
Für den Resize wird eine Event gefeuert... Der geht an das MainForm... Da erzeuge ich mir eine TMessage auf die können alles Subframes hören...

Das alles haben "wir" natürlich im FDK - Das Firemonkey Development Kit zusammen gefasst. (Die Homepage hierzu ist noch in Arbeit)

Mavarik

[Rollo62]

Zitat:

6 Forms & Speicher?

Ja, das hätte ich auch gedacht.
Aber ich bin mittlwerweile am Verzweifenln und bin jetzt extrem vorsichtig was iOS/Android betrifft.
Nichts ist so wie es scheint, oder wie man es erwarten würde ...

Im Moment werfe ich alle "schönen" Ereiterungen wieder raus, einfach weil es womöglich die Probleme verursacht
(MultiView, TabControl mit Slide Effekt, StyleBook, etc.).
Alles hat an irgendeiner Stelle in eine Sackgasse geführt, abe in einem ProofOfconcept fantastisch funktioniert.
Nur leider muss ich reale Apps bauen, nach Kundenvorgaben, und dann snd Sackgassen das Letzte was ich brauche.

Das ist mehr als Schade weil ich ein Projekt jetzt schon mittlerweile 4 mal neu aufgebaut habe, aber immer
wieder auf neue Seltsamkeiten stosse.

Ich habe z.b. aktuell das Problem das eine Embedded Form in TPanel auf einer anderen Form keinen HandleZoom
mehr empfängt, also HandlePan läuft nach wie vor.

Ich vermute mal das nur die MainForm GestureRecognizer richtig verarbeitet, und das diese an evtl. SubForms darunter
nicht mehr weitergeletiet werden.

Wahrscheinlich ist mein generelles Problem das ich gerne die versprochenen "dynamischen", "coolen" Views nutzen möchte
um eine schöne, moderne App hinzubekommen (das erwartet und dafür zahlt der Kunde ja auch).
Nicht nur das einfache Umschalten von Forms, so wie es auf dem Desktop üblich war.
Mittlerweile sehe ich das so das man dafür vielleicht wirklich besser mit GameEngines beraten ist, wie Unity.

Das FDK schaue ich mir gerne mal an.

Rolf

[Rollo62]

Zitat:

FormShow usw. brauche ich ja auch nicht... Wenn ich den Parent setzen weiß ich das doch...
Für den Resize wird eine Event gefeuert... Der geht an das MainForm... Da erzeuge ich mir eine TMessage auf die können alles Subframes hören...

FormShow: Sollte man statt FormCreate nutzen, damit iOS nicht zu lange dort hängt und dich etvl. rausschmeisst.

FormResize: Das würde sich bei repsonsive Design um die Darstellung kümmern, kommt aber nur in der MainForm.

Ich versuche schon alles "richtig" nach Vorschrift zu machen, dumm nur das wohl noch keine allgemeingültige Vorschrift gibt.

Rollo

[Mavarik]

Zitat von Rollo62:

FormShow: Sollte man statt FormCreate nutzen, damit iOS nicht zu lange dort hängt und dich etvl. rausschmeisst.

Nee... Auch nicht Application Events nutzen... ggf. dann die 1. Initialisierungen - die lange dauern - im 1. OnIdle

Zitat von Rollo62:

FormResize: Das würde sich bei repsonsive Design um die Darstellung kümmern, kommt aber nur in der MainForm.
Ich versuche schon alles "richtig" nach Vorschrift zu machen, dumm nur das wohl noch keine allgemeingültige Vorschrift gibt.

Bei mir gibt es ja nur eine MainForm... Mehr brauche ich ja nicht.

"Richtig"? "Vorschrift"?

Meine Vorschriften lauten :
1. Ein Sourcode - Ein Formular für alle Plattformen. Keine Vererbung je nach Betriebsystem (das kann keiner warten)
2. Es muss unter Windows, iOS & Android laufen...
3. Es muss auf allen Plattformen gleich aussehen! (Meine App, meine Regeln - Bitte keine Diskussion darüber anfangen)
4. Es muss sich auf allen Plattformen gleich verhalten. (Soweit wie möglich)
5. Es muss auf Phone & Pad laufen.
6. So wenig wie mögliche IFDEF's

Zu 1.) Meine Create Routinen berücksichtigen die besonderheiten der Styles und der Unterschiede von iOS & Android (Fontgröße usw.) daher brauche ich keine unterscheidungen im Formular... (Siehe zu 6.)

Zu 2.) Das ist die sportliche Aufgabe... Nur wenn ich meine App auf Windows testen kann, komme ich ansatzweise auf eine zeitlich akzeptable Entwicklungszeit.

Zu 3.) Ggf. kann man einen Schalter einbauen... Company Look&Feel oder Plattform Look&Feel

Zu 4.) Der kleinste gemeinsamme Nenner bestimmt die App-Funktionalität... (Ausnahme: Sensoren)

Zu 5.) Der mehr Platz auf einem Pad wird von mir NIE für zusätzliche Features verwendet, sonder lediglich um die Darstellung zu optimieren.
Wenn eine Teilfunktion nur auf dem Pad funktioniert - fein - aber Basis-App-Feature müssen auf auf dem Phone laufen... (Ist für mich eine Frage der Telefonhotline und vermeidet : "Ich hab mir jetzt extra xy gekauf, aber kann xy nicht nutzen", Anrufe)

Zu 6.) Die IFDEF's gehören in eine Wrapper-Schicht (zum Beispiel FDK). Die eigentliche Anwendung muss überhaupt nicht wissen ob iOS, Android oder Windows "drunter" liegt.
Beispiel 1 : Zurück Button... iOS reicht eine Width von 78 Android brauch ca. 105 plus die funktion Hardwarekey die den Button Zurück auslösen kann.
Das will ich doch nicht extra jedes mal programmieren... Also gibt es eine Funktion MakeBackButton(Procedure ...) die alles richtig Erzeugt.
Beispiel 2 : Tastatur Button bei iOS - kennt Android & Windows nicht... Also für Android & Windows bei ShowKeyboard Statusleiste ausbleden und Button Panel anzeigen... Auch das will ich nicht jedesmal extra programmieren...

Dafür habe ich mir (1 Jahr lang) ein FrameWork-Wrapper programmiert...(Seit XE2 und natürlich wir stetig verbessert)


Mavarik