Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)
-   -   Best Practices für IOS +Android APP (https://www.delphipraxis.net/184969-best-practices-fuer-ios-android-app.html)

QuickAndDirty 5. Mai 2015 16:08

Best Practices für IOS +Android APP
 
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 5. Mai 2015 16:37

AW: Best Practices für IOS +Android APP
 
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 5. Mai 2015 16:45

AW: Best Practices für IOS +Android APP
 
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 5. Mai 2015 17:04

AW: Best Practices für IOS +Android APP
 
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 5. Mai 2015 17:38

AW: Best Practices für IOS +Android APP
 
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 6. Mai 2015 18:10

AW: Best Practices für IOS +Android APP
 
@mavarik:
Was wäre denn jeweils die "richtige" routine/tastatur &c.

QuickAndDirty 7. Mai 2015 15:40

AW: Best Practices für IOS +Android APP
 
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 7. Mai 2015 16:41

AW: Best Practices für IOS +Android APP
 
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 7. Mai 2015 16:42

AW: Best Practices für IOS +Android APP
 
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 8. Mai 2015 08:33

AW: Best Practices für IOS +Android APP
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:21 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz