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
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