Best Practices für IOS +Android APP

[QuickAndDirty]

Hallo, welches sind Best Practices die man beachten sollte, wenn man eine Plattform übergreifende Smartphone App neu entwickelt?
Welche Stolpersteine sind bekannt und wie vermeidet man sie.
Ich verwende Delphi XE8.
Es geht mir darum nicht einfach am Ende feststellen zu müssen, dass man so wie ich die APP entwickelt habe, nicht so entwickeln sollte.

Bitte ich bin auch für scheinbar triviale hinweise dankbar.

Ich weiß das man bei java-Android apps gewisse Vorkehrungen treffen muss um den Status der App persistent zu speichern,
da Aktivities im Hintergrund schonmal aus dem Arbeitsspeicher verschwinden. Gibt es dergleichen in DELPHI auch zu beachten?

In Android gibt es verschiedene Programme Services, Contentprovider und Apps. In IOSscheint es stattdessen verschiedene Rechte und Ressourcen-Strategien zu geben.
Muss ich mich darum in Delphi kümmern?

[mensch72]

es gibt irgendwo von Emba oder einem deren Specialists ein gutes Videotutorial, was genau darauf eingeht. (habe es jetzt nur nicht vor mir, finde das aber hoffentlich wieder)

Mir im Gedächtnis:
- man muss seine eigene INET Domain als Installbase konfigurieren, und nicht unter "com.embarcadero.????" seine App entwickeln, sonst wird man im Store nie gefunden oder so
- man muss die Standardeinstellungen der Versionsnummern unbedingt ändern, und zwar für IOS und Android getrennt und unterschiedlich! (eins muss fortlaufend sein, eins in Haupt und Nebenversion bei aber fortlaufender BuidNr oder so... es wurde glaube empfohlen es manuell zu setzen)
- dann gibt es unterschiedliche ICON und Bild Größen, an welche man sich bei welche IOS und Android jeweils halten sollte
- man sollte immer sowenig wie möglich "Rechte" anfordern, die Defaultrechte also lieber fast auf Null reduzieren und dann bei jeder App besser separat das nötige DAZU ankreuzen


Eigene Erfahrung:
- man sollte sich entscheiden ob man konsequent native Style will&macht, ODER ob man einen zwischen IOS und Android einheitlichen&portablen FMX Style verwendet... Ich finde eine App, die man auf Android und IOS gleich und absichtlich anders aussieht, wie 95% der OS-Style Apps besser.
Ob dann Android V4.4 oder V5 das OS sich ändert oder bei IOS V7 & V8 sich optisch unterscheiden soll meiner App möglichst egal sein... das ist aber eine Glaubensfrage und muss je nach Kundenkreis entschieden werden. Bei Spielen würde ich auch (m)einen Style realisieren, bei einer ToolApp ala "Turistinfo" welche in Konkurrenz zu zig anderen meist NativeApps steht, würde ich wohl auch den nativen OS Style nehmen.

[Union]

Am Besten erstmal die Design-Guidelines für die Plattformen durcharbeiten:

https://developer.apple.com/library/...ual/MobileHIG/
https://developer.android.com/design/index.html

Für die Formulardaten-Persistenz benutzt Du TFormSaveState.

[mensch72]

die "Design-Guidelines" sind nur der halbe Weg... man kommt nicht umhin selbst IOS und Android Geräte zu besitzen und diese auch mit mehreren Apps REAL ZU NUTZEN(gut ist wie bei Navis und Spielen da auch zu sehen, wie andere vergleichbare Funktionen auf den unterschiedlichen Plattformen realisieren.

Meine Meinung:
- Wer wirklich 100% an den "Design-Guidelines" kleben will/muss, wird mit Delphi nicht glücklich.
- Delphi steht ja eigentlich für Plattform übergreifend portabel... da ist es mittlerweile ganz gut und hat seine Stärken und Vorteile
- mit viel Aufwand kann man auch unter Delphi (fast) alles native nutzen und darstellen, aber dann ist man schon so hart am OS, das man sich auch schnell eine echt native Java oder ObejetiveC Containerklasse zur Realisierung der benötigten Sachen in eine Lib schreibt und diese von Delphi aus nur noch aufruft

[Mavarik]

hmm Da hat sich so viel angesammelt...

Mal unsortiert:

Wenig Daten ListBox
Viele Daten ListView

Datenbank SQLite

Nur Unicode Strings (beachten) andere nur mit Patch...

iOS PDF im Browser Ja / Android Nein

Die "Richtige" Scroll-Routine - wenn sich die Tastatur einblendet - verwenden...

Android Versionen kann man nur einmal produktiv schalten... Dann muss die Versionsnummer erhöht werden.
iOS nur über den Store

Für Windows Tabletts die richtige Tastatur einblenden..

Mavarik

[QuickAndDirty]

@mavarik:
Was wäre denn jeweils die "richtige" routine/tastatur &c.

[QuickAndDirty]

Bitte posted weiter egal wie belanglos euch das erscheinen mag oder wenn es etwas ist was nur euch betrifft. FÜR MICH IST DAS ALLES WICHTIG.
Das ist mein Erstes FM Projekt und es wird keinen richtigen "kennen lern Vorlauf" geben für dieses Framework.
Alles was man besser am Anfang richtig macht, weil es im nachhinein kaum , mehr zu ändern geht wäre z.B. wichtig.

[Mavarik]

Also

Mein letzter Stand für die Keyboard Geschichte ist:

Delphi-Quellcode:

Procedure TMainForm.CalcContentBoundsProc(Sender: TObject;var ContentBounds: TRectF);
begin
   if KeyBoardVerdecktFeld and (KeyBoardPositionY > 0) then
     ContentBounds.Bottom := Max(ContentBounds.Bottom,2 * ClientHeight - KeyBoardPositionY);
end;

...
  MainVertScrollBox.OnCalcContentBounds := CalcContentBoundsProc;
...

procedure TMainForm.FormVirtualKeyboardHidden(Sender: TObject; KeyboardVisible: Boolean; const Bounds: TRect);
begin
  KeyBoardPositionY:=0;
  KeyBoardVerdecktFeld := False;
  KeyBoardRestorePosition;
end;


procedure TMainForm.FormVirtualKeyboardShown(Sender: TObject; KeyboardVisible: Boolean; const Bounds: TRect);
 var
   LFocused : TControl;
   LFocusRect: TRectF;
begin
  KeyBoardOnScreen := true;
  KeyBoardPositionY := Self.ClientHeight - Bounds.Height;
   KeyBoardVerdecktFeld := False;
   if Assigned(Focused) then
   begin
     LFocused := TControl(Focused.GetObject);
     LFocusRect := LFocused.AbsoluteRect;
     LFocusRect.Offset(MainVertScrollBox.ViewportPosition);
     if (KeyBoardPositionY<>0) and (LFocusRect.Bottom>KeyBoardPositionY) then begin;
       KeyBoardVerdecktFeld := True;
       MainVertScrollBox.RealignContent;
       Application.ProcessMessages;
       MainVertScrollBox.ViewportPosition :=
         PointF(MainVertScrollBox.ViewportPosition.X,
                LFocusRect.Bottom - KeyBoardPositionY);
     end;
   end;
   if not KeyBoardVerdecktFeld then
     KeyBoardRestorePosition;
end;

Meine Version der FMX.Platform.Win (bin mir nicht sicher, ob das schon alles funktioniert)

Delphi-Quellcode:

constructor TVirtualKeyboardWin.Create;
var
  L: integer;
  S: string;
  HID: HKey;
  DVersion: DWORD;
  Major, Minor: byte;
begin
  S := '';
  inherited Create;
  SetLength(S, MAX_PATH);
  L := GetSystemDirectory(PChar(S), MAX_PATH);
  SetLength(S, L);
  FPath := S;
  FExeName := 'osk.exe';
  FWndClassName := 'OSKMainClass';

  FKBPresent := True;
  DVersion := Winapi.Windows.GetVersion;
  Major := Lo(LoWord(DVersion));
  Minor := Hi(LoWord(DVersion));
  FVersion := Major;
  FVersion := FVersion * 100 + Minor * 10;
  if DVersion < 620 then
  begin
    if Winapi.Windows.RegOpenKeyEx(HKEY_LOCAL_MACHINE, 'SYSTEM\CurrentControlSet\Enum', 0, KEY_READ,
      HID) = ERROR_SUCCESS then
      try
        S := FindKeyValue(HID, 'ClassGUID', '{4D36E96B-E325-11CE-BFC1-08002BE10318}', 'Control',
          'ActiveService');
        FKBPresent := S <> '';
      finally
        RegCloseKey(HID);
      end;
  end
  else
  begin
    if Winapi.Windows.RegOpenKeyEx(HKEY_LOCAL_MACHINE, 'SOFTWARE\Classes\', 0, KEY_READ,HID) = ERROR_SUCCESS then
      try
        S := FindKeyValue(HID, 'CLSID', '{054AAE20-4BEA-4347-8A35-64A533254A9D}', 'LocalServer32','');
        FPath := S;
        FExeName := 'TipTap.exe';  // Das ist die "Richtige"
        FWndClassName := 'IPTip_Main_Window';
        FKBPresent := S <> '';
      finally
        RegCloseKey(HID);
      end;

    //Windows.Devices.Input.KeyboardCapabilities.KeyboardPresent
  end;
  FNewvkbState := vkbState;
  StartTimerLang;
end;

Mavarik

[vagtler]

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/

[QuickAndDirty]

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?

Zitat:

Zitat von Mavarik (Beitrag 1300670)

Also
Mein letzter Stand für die Keyboard Geschichte ist:

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

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.

[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