10.2 und Android...

[Mavarik]

Emm :stupid:

Also Ich verstehe es nicht, wie Delphi die Kontrolle an Android übergibt, aber mit 10.2 wird im MainProg.dpr Application.Run ausgeführt und endet nicht in einer

Delphi-Quellcode:

  repeat // Zeile fehlt in 10.2
    InternalProcessMessages;
  until FAndroidApp^.destroyRequested <> 0; // Zeile fehlt in 10.2

sondern "InternalProcessMessages" wird nur ein mal aufgerufen und MainProg.dpr ist zu ende... (Sollte sich dann nicht die App schließen)

Da InternalProcessMessages nur ein mal aufgerufen wird, gibt es auch keine OnIdle Events mehr...

Meine Frage... Wieso ist die App noch im Speicher und läuft?

Hat das etwas damit zu tun, das der Java-UI-Thread jetzt der selbe ist wie der von Delphi?

Strange....

Mavarik :stupid:

PS.: Unnötig zu sagen, dass FMX ohne den OnIdleEvent nicht zu gebrauchen ist...

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1374149)

PS.: Unnötig zu sagen, dass FMX ohne den OnIdleEvent nicht zu gebrauchen ist...

Das brauchten wir bisher unter Android nicht. Wofür brauchst du das?

Bei uns läuft alles in Threads, was wir vorher mit OnIdle gemacht hatten. Allerdings nicht wegen Android, sondern weil es vorher keine gute Lösung war. (Nutzung für eine asynchrone Eventqueue.)

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1374154)

Zitat:

Zitat von Mavarik (Beitrag 1374149)

PS.: Unnötig zu sagen, dass FMX ohne den OnIdleEvent nicht zu gebrauchen ist...

Das brauchten wir bisher unter Android nicht. Wofür brauchst du das?

Bei uns läuft alles in Threads, was wir vorher mit OnIdle gemacht hatten. Allerdings nicht wegen Android, sondern weil es vorher keine gute Lösung war. (Nutzung für eine asynchrone Eventqueue.)

Beispiel:

Delphi-Quellcode:

Procedure TForm1.ButtonClick(Sender : TObject)
begin // Jegliche Animation: Focus ButtonDown Farbe setzen usw. Läuft im UI-Thread mit einem Timer
  Proc_Dauert_10Sekunden_kann_nichtimThread(true); // Keine Reaktion für den User...
end;

Daher immer:

Delphi-Quellcode:

Procedure TForm1.ButtonClick(Sender : TObject)
begin // Jegliche Animation: Focus ButtonDown Farbe setzen usw. Läuft im UI-Thread mit einem Timer
  TIdleWorker.Default.Execute(Procedure // Wir ausgeführt im nächsten OnIdleEvent...
    begin
      Proc_Dauert_10Sekunden_kann_nichtimThread(true); // Keine Reaktion für den User...
    end);
end;

oder

Delphi-Quellcode:

Procedure TForm1.ListBox1Click(Sender : TObject)
var
  Layout : TLayout;
begin 
  Layout := TLayout.Create(NIL);
  Layout.Parent := TListListBoxItem(Sender);
  Layout.Align  := TAlignLayout.Client;

  TIdleWorker.Default.Execute(Procedure // Wir ausgeführt im nächsten OnIdleEvent...
    begin
      Whatever := Layout.Height; // Erst korrekt belegt nachdem sich die UI-Fertig aufgebaut hat... 
    end);
end;

usw. Aber das war nicht die Frage... 8-)

Mavarik

[Darlo]

10.2 ist irgendwie bezgl. auf FMX ein Desaster. Keine meiner Apps kann fehlerfrei genutzt werden. Bin daher bei 10.1 #2. Hoffe Update 1 kommt bald und richtet den ganzen Mist.

[Mavarik]

Zitat:

Zitat von Darlo (Beitrag 1374164)

10.2 ist irgendwie bezgl. auf FMX ein Desaster. Keine meiner Apps kann fehlerfrei genutzt werden. Bin daher bei 10.1 #2. Hoffe Update 1 kommt bald und richtet den ganzen Mist.

Genau so bei mir... 10.2 war das Linux Update...

[mensch72]

Dann schreibt doch mal was in QC und äußert dort den "wenig Aufwand" Wunsch nach einem Berlin10.1u2 mit noch einmal nachgereichter aktueller XCode Unterstützung, denn dort nähern wir uns stark IOS11

(ich weiß grad gar nicht ob die Signierung mit Tokyo10.2hf1 nun geht, habe noch keine App damit wieder zur Veröffentlichung "lauffähig" und mir fehlt die Zeit da zu suchen, obwohl ich nun mit dem Wissen um "geändertes OnIdle" mir da ein paar Stellen einfallen)

[Darlo]

Zitat:

Zitat von mensch72 (Beitrag 1374178)

Dann schreibt doch mal was in QC und äußert dort den "wenig Aufwand" Wunsch nach einem Berlin10.1u2 mit noch einmal nachgereichter aktueller XCode Unterstützung, denn dort nähern wir uns stark IOS11

(ich weiß grad gar nicht ob die Signierung mit Tokyo10.2hf1 nun geht, habe noch keine App damit wieder zur Veröffentlichung "lauffähig" und mir fehlt die Zeit da zu suchen, obwohl ich nun mit dem Wissen um "geändertes OnIdle" mir da ein paar Stellen einfallen)

Steht doch alles schon drin. Geil nur dass da keine Hotfixes kommen. Man kann ja nichtmal nem Label dynamisch Text zuweisen....

[Rollo62]

Ich hab im Moment ios app auf 10.2 und selbige auf Android unter 10.1

Wenn ich genau wüsste was alles schief läuft würde ich auch qc schreiben können.

Bin aber eher bei schadensbegrenzung und kann nicht ständig Delphi reengineeren.
Dafür könnte uns emba ja mal vergüten z.b. bonus für qc Eintrag je nach voting.
Dann würden vielleicht mehr Entwickler die Arbeit von emba mitmachen.

Ich bin jedenfalls stinksauer das wir immer ohne Vorwarnung als gamma Tester benutzt werden

[mensch72]

..."Bin aber eher bei schadensbegrenzung und kann nicht ständig Delphi reengineeren.
Dafür könnte uns emba ja mal vergüten z.b. bonus für qc Eintrag je nach voting"...

zum Beispiel:)

Microsoft verschickt für einen guten "MSDN-QC-Eintrag" auch mal ein T-Shirt mit nem passenden Bild/Spruch... da geht es ja garnicht um den Wert, eher das sie anerkennen, das man seine Zeit zur FehlerANALYSE geopfert hat.

Ob Mr. Hausladen nun seitens Emba/Idera als Anerkennung seiner jahrelangen IDE-Hotfix-Leistungen eine kostenlose Subscription bekommen hat?
Bekannt ist aktuell nur das er aktuell selbst kein Geld mehr für eine Subscription ausgeben will und deshalb seineseits alle Tools auf den Stand RTM-10.2 bleiben müssen :(

(Im aktuellem QC würde ja reichen reichen: "ja bestätigt, wird behoben per Hotfix/Update/Version bis MM/YYYY"... Geld/Zeit ist eh nicht berechenbar!... also lieber bei bestimmten Sachen da um 1..3.. Monate bei denen die Subscription als Anerkennung verlängern, das hilft dann "allen")


Trotz allem POSITIV: Die IDE ist 10.2hf1 trotz wenig Einsatzerfahrung gefühlt vergleichbar stabil wie "Berlin" auf Stand "10.1u2"... Mit FmxLinux-AddON gibt es etwas, was man vorher nicht machen konnte... Da hat "Desktop-FMX" einen Schritt nach vorn gemacht, auch wenn MobileFMX aktuell unter 10.2. gefühlt ein Schritt zurück ist.

[Rollo62]

Mobile ist gefühlt zwei Schritte zurück

Schade das emba seine Assets nicht kennt und weiter "CrossPlatform" propagiert und dabei seine tapferen Mitstreiter auf Kosten der Pinguine vernachlässigt.
Und uns dann noch nicht mal daran partizipieren lässt, erst ab Enterprise.
Ziemlich dumme Strategie Konsole als Enterprise auszugeben.
CrossPlatform ist Mobile.
Wenn ich Emba wäre würde ich da Alles reinsetzen. Aber seit Xe8 kaum BugFixes.

[Der schöne Günther]

Wir haben es letztes Jahr einmal mit RAD Studio auf iOS und Android versucht, endete ziemlich unglücklich und wurde dann eingestampft. Jetzt soll noch einmal ein kleines Projekt damit gemacht werden, aber wenn ich das alles lese dann reiche ich besser bald Urlaub ein und warte bis die Sache sich wieder erledigt hat :-D

[jaenicke]

Zitat:

Zitat von Darlo (Beitrag 1374180)

Steht doch alles schon drin. Geil nur dass da keine Hotfixes kommen. Man kann ja nichtmal nem Label dynamisch Text zuweisen....

Das kann ich nicht reproduzieren. Neue Anwendung, Buttonklick:

Delphi-Quellcode:

  Label1.Text := 'Test';
//

Das funktioniert bei mir. Oder meintest du etwas anderes?

[Darlo]

https://quality.embarcadero.com/browse/RSP-18159

Schau dir mal die 18159.zip an.

[Rollo62]

Ich bin seit XE7 dabei mit Projektem, dann gavs mit XE8 einen Rückschritt der mich fast einen Projektkunden gekostet hat. Mit XE10 wurds dann stabiler, 10.1 noch besser, 10.1Upd2 beser und besser.
Und dann bei 10.2 wider totales Desaster, erinnertm ich an XE8.

Emba sceint nur in Wellen zwischen Good and Evil arbeiten zu können.

Von den verlorenen Wochen und Monaten mittlerweile nicht zu reden ...

Wenn das nicht immer wieder passieren würde, dann wäre ich mit RadStudio sehr zufrieden, obwohl nur 50%
der zugesicherten Eigenschaften nutzbar ist.
Daran gewöhnt man sich wenn man nicht zu hohe Ansprüche stellt.

[Mavarik]

QC Gibt es schon RSP-17546!

[braunbaer]

Zitat:

Zitat von Rollo62 (Beitrag 1374210)

Ich hab im Moment ios app auf 10.2 und selbige auf Android unter 10.1

Hallo Rollo 62,
das ist ein guter Tipp.
mit Android habe ich ebenfalls massivste Probleme.
hab jetzt wie du das kompilieren auf Android mit 10.1 gemacht und hat einwandfrei funktioniert.
Ich habe 3 Apps im Produktivbetrieb und alle Androidversionen sind seit Delphi 10.2 Schrott.

Hoffe, dass so was in Zukunft nicht mehr passiert...

Grüße aus dem Bregenzerwald
Gebhard

[Rollo62]

Das Dumme ist nur das ich ein paar Fixes der FMX-Routinen einbauen musste, die sich je nach 10.1 und 10.2 unterscheiden.

Ich mache das im Moment Quick-and-Dirty so, dass ich diese per Batch-Datei umkopieren lasse:

Die verschiedenen Ausgangsdateien bei mir:

Zitat:

FMX.Platform.iOS_Fix10_1.pas
FMX.Platform.iOS_Fix10_2.pas
FMX.Platform.iOS_Fix10_2_Hf1.pas

System.Bluetooth_Fix10_1.pas
System.Bluetooth_Fix10_2.pas
System.Bluetooth_Fix10_2_Hf1.pas

System.Mac.Bluetooth_Fix10_1.pas

werden durch die jeweiligen Batch Dateien für 101 oder 102 bereinigt, umkopiert ...

Zitat:

_Use101_Upd2.bat
_Use102_Hf1.bat

und diese legen mir dann noch je nachdem eine "BatchInfo"-Datei an, die mir nur zeigen soll was gerade aktiv ist.

Zitat:

_Is102_Hf1.bai

Das ist nicht besonders schön oder cool, erfüllt aber seinen Zweck.

Ich hoffe auch drauf das ich mit dem Upd1 diese Krücke wieder rausnehmen kann (und am Besten alle Fixes gleich mit).
Die Hoffnung stirbt zuletzt :stupid:

[mensch72]

Leider habe ich bezüglich der für uns "lebensnotwendigen" Patches bei "Bluetooth" und "BluetoothLE" einen Maulkorb.
Fakt ist: man kann OutOfTheBox seit XE8 keine sichere AndroidAPP mit BLE schreiben, wenn man Android 4.4+,5.1+,6+,7+ sowie die Samsung S5&S6 "vernünftig" unterstützen will. In den Emba/Idera Sourcen gibt es schlicht einige unbehandelte ErrorStates (ala "131..133") welche zu "BigTimeouts" führen, wo doch eine vernünftige Behandlung und "Lösung" garnicht so schwer wäre(ist).

Aktuell ist unsere Liste für Sachen, die man nicht nutzen darf bei der Schnittmenge zu Android&IOS für BLE sehr lang. Für Berlin10.1u2 habe ich noch all unsere Patches seit XE8u? nachgezogen.
Gerade bei Multiplattform und IOT stößt hier scheinbar FMX als universelle Kapselung/Schicht seitens Emba/Idera aktuell an die Grenze des "wartbaren", denn um das sauber zu lösen braucht es Fachkompetenz in BLE, allen native Plattformen und dann noch Deep-FMX als "AbstaktionLayer". Ich wollte FMX so erweitern, das unter Windows(8.1+) auch der BLE-Scan ("DiscoverDevices") echt funktioniert und nicht nur die zuvor bereits unter Windows(System) registrierten/angemeldeten Geräte findet...
In C#/C++ API nach MSDN ist das mit etwas Aufwand durchaus möglich, aber es passt leider nicht wirklich(einfach) in die FMX-Layer seit XE8:(

FMX als UniGUI halte ich weiter für DAS TOP FEATURE von RadStudio, was auch wenn es aktuell (wieder) etwas hakt sicher gelöst wird.
Sobald aber neben GUI auch noch Hardwarelayer ala BLE für IOT dazu kommen, wird das seitens Emba/Idera mit ein paar SimpleDemos stets nur ein kratzen an der Oberfläche bleiben. Mangels vorhersehbarer Entwicklungsstabilität lohnt sich da aber leider auch für niemanden ein komerzielles AddON zu realisieren und dieses anzubieten. Die von FMXlinux machen ja genau sowas, nur eben rein für GUI und da klappt da ja auch sehr gut:)

[Darlo]

Hoffe das für Berlin noch ein Update 3 folgt um xCode 8.3 und iOS 10.3 / 11 zu unterstützen. Würde 10.2 gerne auslassen und auf 10.3 hoffen.

[Mavarik]

@Rollo62,Mensch72

Mich würden Eure Patches interessieren...

Ich selbe führe meine auch seit XE7 mit:

FMX.Memo.Style,
FMX.Controls,
FMX.WebBrowser.Win.pas,
FMX.Objects.pas,
FMX.Platform.iOS.pas
FMX.VirtualKeyboard.ios.pas
System.Win.Sensors.pas


Mavarik

[Rollo62]

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]

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]

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]

Zitat:

Zitat von Mavarik (Beitrag 1374244)

QC Gibt es schon RSP-17546!

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