Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)
-   -   Delphi 10.2 und Android... (https://www.delphipraxis.net/193017-10-2-und-android.html)

Rollo62 11. Jun 2017 21:13

AW: 10.2 und Android...
 
Hallo Frank,

Es hält sich noch in Grenzen bei mir, im Wesentlichen um die Basisfunktionen mit BLE sicherzustellen.
Ich muss dazusagen das ich auch wirklich auf unterstem Level mit den Control arbeite, also teilweise
TRectangle als TButton, weil irgendwas nicht rund lief.
Ich versuche auch möglichst ohne solche FMX-Fixes auszukommen, falls machbar.
Jegliche Versuche höherklassige Komponenten einzsetzen ist oft gescheitert, weshalb ich erstmal die Fingerdavon lasse.
Mit TLayout, TRectangle, TGlyph, TImage, TImageList, TLabel, TSpeedButton, TCheckBox/TSwitch, TListBox, TListView, TMemo(hat Probleme), TStyleBook, FireDac/Sqlite, Camera, ShowShareSheet kann man schon ganz schon weit kommen.
Ein paar Funktionen habe ich dann natürlich aus Android/iOS oder z.B. Anregungen aus D.P.F. reingenommen, ansonsten nutze ich aber keine kompletten Fremdkomponenten um mir nicht noch mehr Ärger einzuhandeln.
Ich denke aber über TMS Cloud package nach.

Mein aktuelles Problem in 10.2 sind die TGlyh TImageList unter Android, es werden anscheinend Caches für die MultiResBitmap verwendet, die mal als "Geisterbilder" woanders wieder auftauchen können.
Bei iOS funktioniert das noch wie unter 10.1.
Womöglich hat Android Version noch zig andere Probleme, aber das bekomme ich nicht einfach weg, deshalb teste ich den Rest nicht.
Es fühlte sich generell auch etwas zäher an, also von optimierung der Threads hätte ich mehr erwartet.

Ansonsten arbeitet Bluetootk im Moment für mich bei 8 ziemlich verschiedenen Geräten mit customer UUIS Services als RS232-Ersatz, aber da tauche ich auch nicht sehr in die (Un)-Tiefen von BLE ab.
Nice-to-have für BLE wären mehrere Devices gleichzeitig verbinden, Mesh-Support (ist aber noch nicht wirklich in den Phones angekommen), stabileres BLE System generell.

Um BLE herum hatte ich Einiges an Versuchen machen müssen, von normalem reinlegen in DatenModul über Threads bis zu Alles im TBluetoothManagerLE, habe ich bestimmt 5 Varianten durch.
Im Moment ist es eine Version die vom Timing und von den Prozessen her relativ stabil läuft, auf der Basis der FMX Komponenten, so hoffe ich bleibt es erstmal bestehen.
Allerdings habe ich noch nicht versucht, wie Mensch72, den kompletten BLE-Codes zu Optimieren und/oder einen Rewrite zu machen, das sollte das FMX schon liefern, sonst kann ich ja gleich zu Xamarin o.ä. wechseln.
Wenn man die Workarounds mal sortieren würde und einen bestmöglichen, funktionierenden Code irgendwo ablegen könnte fände ich das super, aber womöglich sprechen die Lizenzregeln von Emba dagegen.
Vielleicht wäre Emba gut geraten die Sourcen als OpenSource anzulegen, damit mal ein paar mehr Leute an den BugFixes mitarbeiten können.

Also z.B. diverse Fixes:

in FMX.Platform.iOS machte das Longtap für mich Probleme, sendet mal falsche Codes und gibt daher
Probleme wenn man mit Mouse Down/Move/Up zeichnet.
Der Workaround ist das komplett abzuschalten, und bei Bedarf mein eigenes LongTap erzeugen:
Delphi-Quellcode:
    TInteractiveGesture.LongTap:
      begin
////S4:
//        LongTapRecognizer := TUILongPressGestureRecognizer.Alloc;
//        LongTapRecognizer := TUILongPressGestureRecognizer.Wrap(LongTapRecognizer.initWithTarget(GetObjectID, sel_getUid('LongTap:')));
//        LongTapRecognizer.setDelaysTouchesBegan(False);
//        LongTapRecognizer.setCancelsTouchesInView(True);
//        LongTapRecognizer.setDelegate(GetObjectID);
//        View.addGestureRecognizer(LongTapRecognizer);
//        LongTapRecognizer.release;
      end;

in System.Bluetooth: Es gab memory leaks, die durch Weak reference weg sind
Delphi-Quellcode:
   [Weak] FFilterUUIDList: TBluetoothUUIDsList; //Added weak reference

....

    if Assigned( FFilterUUIDList ) then // Added safety check
    begin
      for LServiceUUID in FFilterUUIDList do
        if ADevice.ScannedAdvertiseData.ContainsServiceUUID(LServiceUUID) then
          Exit(True);
      if ADevice.DiscoverServices and (FFilterUUIDList <> nil) then
        for LServiceUUID in FFilterUUIDList do
          if ADevice.GetService(LServiceUUID) <> nil then
            Exit(True);
    end;

....

   FFilterUUIDList := nil; // Add to avoid Leaks, additional Weak s.a.
in System.Bluetooth: scheint ein Typo zu sein der die falsche Variable übergibt
Delphi-Quellcode:

  try
    if FilterDiscoveredDevices(LFilter, LDeviceList) and Assigned(FOnDiscoveryLEEnd) then
      FOnDiscoveryLEEnd(Sender, LDeviceList); // BugFix: old variable ... ADeviceList);
  except
    if Assigned(ApplicationHandleException) then
      ApplicationHandleException(Self)
    else
      raise;
  end;
in System.Mac.Bluetoot: auch Memory leaks:

Delphi-Quellcode:
  if FLEManager.FScanOptions = nil then
  begin
    FLEManager.FScanOptions := TNSMutableDictionary.Create;
//    LNumber := TNSNumber.Wrap(TNSNumber.OCClass.numberWithBool(True)); //After 10.1_U1  addition from new file
    LNumber := TNSNumber.Wrap(TNSNumber.OCClass.numberWithBool(False));  //After 10.1_U1  test
    //S4: Before 10.1_U1 LNumber := TNSNumber.Wrap(TNSNumber.OCClass.numberWithUnsignedChar(0));
    FLEManager.FScanOptions.setValue((LNumber as ILocalObject).GetObjectID, CBCentralManagerScanOptionAllowDuplicatesKey);
  end;

....

procedure TInternalBluetoothLEManager.StartDiscovery(Timeout: Cardinal; const FilterUUIDList: TBluetoothUUIDsList);
var
  LNumber: NSNumber;
begin
  if FIsDiscovering then Exit;

  //###
  //S4: Addition to avoid permanent Memory leaks
  if FFilterUUIDList <> nil then
  begin
    FFilterUUIDList.release;
  end;
  //###
  //S4: Addition to avoid permanent Memory leaks
....

Wohlgemerkt unter VCL habe und hatte ich solche Probleme nie, das läuft immer superstabil.
FMX als Zugpferd für Mobile ist allerdings auf wackeligen Füssen gebaut, läuft aber auch zuverlässig wenn man's nicht übertreibt und versucht das letze Auszureizen.

Rollo

bra 12. Jun 2017 09:42

AW: 10.2 und Android...
 
Tokyo ist für mobil eine einzige Katastrophe. Unsere App (von Berlin kommen) funktioniert weder unter iOS noch unter Android richtig. Ich frage mich, ob die bei Emb überhaupt noch Tests machen, so verbuggt, wie das mit jeder neuen Version ist. Teilweise grundlegende Dinge funktionieren da nicht mal mehr :evil:

Rollo62 12. Jun 2017 13:11

AW: 10.2 und Android...
 
Grundvorraussetzung bei allen Komponenten ist für mich erstmal:
Funktionieren die Samples out-of-the-box.

Und bei 10.2 laufen die eben nicht mehr so wie vorher.
Vielleicht sollte Emba erstmal die eigenen Demos wieder lauffähig machen.

Selber Schuld ich hätte ja auf Upd1 warten sollen, aber ich hatte gerade andere Probleme mit iOS etc. und hatte die Hoffnung das 10.2 das hinbekommt.
War aber leider auch nicht so, erst XCode 8.3.3 plus Handgefrickel war die Lösung für mich.

Naja, wir hängen eben zwischen ALLEN Stühlen, und das sind mittlerweile ganz schön viele :pale:

Mavarik 14. Jun 2017 14:00

AW: 10.2 und Android...
 
Zitat:

Zitat von Mavarik (Beitrag 1374244)
QC Gibt es schon RSP-17546!

OK Bitte auf jeden Fall nochmal für den QC Voten, Danke


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:55 Uhr.
Seite 3 von 3     123   

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