Best Practices für IOS +Android APP

[Lemmy]

Zitat:

Zitat von QuickAndDirty (Beitrag 1300714)

Zitat:

Zitat von vagtler (Beitrag 1300671)

Wenn ich übergreifende Plattformen höre, so würde ich den hybriden Ansatz zumindest in meine Überlegungen einbeziehen. Tatsächlich werden Frameworks wie Angular.JS in Verbindung mit z.B. Materail, Ionic oder WinJS immer leistungsfähiger. Ich empfehle durchaus auch mal eine Präsentation von z.B. Christian Weyer persönlich anzuschauen: https://speakerdeck.com/christianweyer/

Ja, die Sache ist die, dass ich vorhabe ne menge Code aus einem Desktop-Projekt(Delphi-VCL, über 5Mio Codezeilen) wieder zu verwenden.

wo ist das Problem? Der Code kommt in einen Restserver der in Delphi implementiert ist und die Oberfläche in AngularJS....

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1300714)

Ist das nur für Windowsphone oder ist das deine Allgemeine Lösung für alle Plattformen?

Der Scroller ist für alle Plattformen das Laden der richtigen Tastatur "FMX.Platform.Win" :stupid:

Nur für Windows...

[bcvs]

Zitat:

Zitat von QuickAndDirty (Beitrag 1300714)

Ist es möglich mehrere Formulare in einer App zu verwenden(So wie in Android die Aktivities) oder macht man besser alles über Tabs, so als würde man nen Wizzard für Windows entwickeln?

Dazu gab es hier vor kurzem schon mal eine Frage (und Antworten):
http://www.delphipraxis.net/184767-a...-activity.html

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1300714)

Ist es möglich mehrere Formulare in einer App zu verwenden(So wie in Android die Aktivities) oder macht man besser alles über Tabs, so als würde man nen Wizzard für Windows entwickeln?

Selbstverständlich kannst Du mehrere Formulare verwenden...

Die Frage ist wo soll die App überall laufen?

Beispiel: iOS & Android werden die Formulare immer Fullscreen dargestellt. Bedeutet ein Show von einem neuen Formular überlagert das "1." - also kein Problem!

Willst Du die gleiche App auf einem Windows Tablett laufen lassen oder auf dem Desktop sieht es schon anders aus... Auf dem Desktop PC macht Fullscreen in der Regel keinen Sinn und die einzelnen auf popenden Fenster sind dann auch eher doof..

Ich habe mir hierfür ein Form-Framework geschrieben nach dem folgenden Ansatz:

Code:

iPhone           iPad
+----+     +----+----+----+ 
|    |     |    |         |
|    |     |    |    |    |
|    |  -> |    |         | 
|    |     |    |    |    |
|    |     |    |         |
+----+     +----+---------+

Ein iPad im Landscape Mode ist 3x so groß wie ein iPhone (Umgerechnet auf Andorid passt das System auch)

Wenn meine App auf dem IPhone 3 Tabs hat oder ich 3 Tabs benötige um Funktion XY aus zu führen kann ich die Infos auf dem Pad sofort nebeneinander anzeigen. Ich designe also immer nur iPhone Aspekt Ratio.

Wenn ich das Pad drehe Zoome ich hoch als hätte ich ein überdimensionales iPhone...

Es gibt also nur ein Hauptformular... Alle anderen Formulare werden erzeugt und das untere

Delphi-Quellcode:

Layout.Parent

erhält den entsprechenden Frame (Links, Mitte, Rechts). die Mitte ist align Client... wenn ich also

Delphi-Quellcode:

Right.Width := 0;

setze habe ich das, was die Multiview seit XE7 kann. Nur das ich das schon für XE2 programmiert hatte. 8-)

Mein Mainform ist natürlich ein Tabcontrol. Daher gibt es auch Butten die Global oder Tabbezogen arbeiten und vom Framework entsprechend umgeschaltet werden... usw...

Mavarik

[vagtler]

Zitat:

Zitat von Lemmy (Beitrag 1300716)

[...] wo ist das Problem? Der Code kommt in einen Restserver der in Delphi implementiert ist und die Oberfläche in AngularJS....

:thumb:

[QuickAndDirty]

So wie es im Moment aussieht werde ich ein facebookartiges Drawer-menü als "Site-Navigation" verwenden.
Damit ich Übergänge hab möchte ich das TTabControl nehmen und darin TFrame Nachfahren unterbringen, so dass ich die Ansicht mit einer Animation gewechselt bekomme aber dennoch unterschiedliche Ansichten gekapselt für sich entwickeln kann.

Haben Frames in Firemonkey eigentlich irgend einen Nachteil?

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1300971)

Haben Frames in Firemonkey eigentlich irgend einen Nachteil?

ja z.B. Wenn Du eine PrototypeBindSource auf das Frame setzt, kannst Du die nicht mehr löschen und bekommst die Fehlermeldung, dass das Vater Formular die Komponente hat. Musst Du also dann den FMX Source ändern.

Frames können nett sein - wegen der Vererbung - aber mich nervt das...

Nimm eine Form mit einem Layout als Alignclient und setze den Parent so wie Du Ihn brauchst. Siehe

Mavarik

[QuickAndDirty]

Zitat:

Zitat von Mavarik (Beitrag 1300978)

Zitat:

Zitat von QuickAndDirty (Beitrag 1300971)

Haben Frames in Firemonkey eigentlich irgend einen Nachteil?

Nimm eine Form mit einem Layout als Alignclient und setze den Parent so wie Du Ihn brauchst. Siehe

Wo ist das Layout? In der Parent oder in der Child Form? Oder hat TForm zur Laufzeit ein Align?
Das ChildFormular kommt dann zur Laufzeit dadrauf (re-parent) nehme ich an.

Ich werde es so machen.

[QuickAndDirty]

Zitat:

Zitat von Mavarik (Beitrag 1300978)

setze den Parent so wie Du Ihn brauchst. Siehe

Vom Formular oder vom Layout?

[Mavarik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1301035)

Zitat:

Zitat von Mavarik (Beitrag 1300978)

setze den Parent so wie Du Ihn brauchst. Siehe

Vom Formular oder vom Layout?

Es gibt ein MainForm...

Das MainForm hat sagen wir 3 Bereiche... Alles Layouts...
LayoutLinks, LayoutRechts, LayoutMitte...

Jetzt erzeugst Du 1-3 Forms... Ohne an zu zeigen...

Und setzt NewForm.Layout.Parent := LayoutLinks; usw...

Mavarik