Ios9

[Darlo]

Solange Du Dein xCode aus dem AppStore hast gerne ;-)

[cipher]

Zitat:

Zitat von Darlo (Beitrag 1317138)

Solange Du Dein xCode aus dem AppStore hast gerne ;-)

:-D Ja, hab ich.

https://itunes.apple.com/us/app/enlightme/id1027478184

Was mich halt wundert ist, dass die App durch das Review kam, obwohl sie auf meinen alten iPads sofort beim Start abstürzt.

[Darlo]

Geht bei mir leider auch nicht. Ich weiß jetzt nicht wie Delphi das Bundle aus 32 und 64 bit erstellt, aber hattest Du bei der 32 Bit-Konfig auch das SDK 8.4 ausgewählt? Ggf. mal das SDK 9 unter 32 bit löschen....

Vielleicht weiß hier ja jemand wie Delphi hier intern arbeitet.

[cipher]

Zitat:

Zitat von Darlo (Beitrag 1317146)

Geht bei mir leider auch nicht. Ich weiß jetzt nicht wie Delphi das Bundle aus 32 und 64 bit erstellt, aber hattest Du bei der 32 Bit-Konfig auch das SDK 8.4 ausgewählt? Ggf. mal das SDK 9 unter 32 bit löschen....

Das SDK 9.0 habe ich komplett gelöscht. Habe nur SDK 8.4 mit XCode7 konfiguriert.

Und selbst beim Debuggen gibt es nur diesen Crash (siehe Screenshot), der mir nicht weiterhilft, da bis dahin noch keine Zeile von meinem Code ausgeführt wurde.. :(

[omp]

Unser App-Update wurde heute nach 8 Tagen reviewt und akzeptiert.
Ich habe es mit dem Fix für XE8 und SDK 8.4 gemacht. Das war mir irgendwie sicherer als Delphi 10.

[Uwe Raabe]

Es gibt nun einen HotFix, der auch unter Seattle gegen das SDK 9 compilierte Apps unter iOS7, iOS8 und iOS9 lauffähig machen soll (noch nicht selbst probiert).

[MarcoWarm]

Hi,

was das Hotfix angeht. Bei mir funktioniert er.

iPad 2 mit iOS 8.4
SDK für iPhoneOS 9.0

Debug Config 32bit und 64bit

Gruß
Marco

[Thomas Horstmann]

Ich habe das HotFix auf verschiedenen iOS Geräten getestet. Scheint auch grundsätzlich mit El Capitan, XCode 7.0.1 und SDK 9.0 zu laufen. Allerdings bleibt ein iPad mini 2 (9.0.2) mit dem Splash-Screen Fehler bi 64Bit hängen (32Bit läuft). Mit dem SDK 8.4 läuft es. Werde es mal neu aufsetzen, vielleicht liegt es am Gerät (hoffentlich nicht an Retina).

[cipher]

Der Hotfix scheint bei mir zumindest teilweise für Besserung zu sorgen (siehe oben).

Auf dem iPad 2 (mit iOS9) läuft meine App jetzt immerhin im Debug-Modus. Aber nicht, wenn ich sie als Release kompiliere. :(

Das kann also echt nur ein Bug im Compiler bzw. PAServer sein. Und man kann nur hoffen, dass Embarcadero da noch ein Fix oder Update nachliefert.

[bra]

Zitat:

Zitat von cipher (Beitrag 1317429)

Auf dem iPad 2 (mit iOS9) läuft meine App jetzt immerhin im Debug-Modus. Aber nicht, wenn ich sie als Release kompiliere. :(

Hast du beim Release auch die Option für die kombinierte Binary (32 und 64 Bit) gesetzt? Das iPad2 ist nur 32 Bit.

[cipher]

Ja, habe ich. Es handelt sich ja nicht um ein neues Projekt, sondern eins, das mit XE8+SDK8.4+iOS8 auf allen Devices lief.
Ich habe sogar ein reines 32Bit-AdHoc Paket erstellt und als Release stürzt es ab und als Debug läuft es.

[Thomas Horstmann]

Ich habe das hotfix getestet und die (sehr merkwürdige) Erfahrung gemacht, dass es auf einem Gerät läuft (iPad mini 1, iOS 9.0.2) und auf einem anderen nicht (iPad mini 2, iOS 9.0.2). Bei meiner App lag es an TImageList. Wenn zwei oder mehr PNG-Bilder enthalten sind, läuft die App auf dem iPad mini 2 nicht mehr (AdHoc und 64Bit). Mit 32 Bit läuft alles bestens.

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

[cipher]

Zitat:

Zitat von Thomas Horstmann (Beitrag 1317536)

Bei meiner App lag es an TImageList. Wenn zwei oder mehr PNG-Bilder enthalten sind, läuft die App auf dem iPad mini 2 nicht mehr (AdHoc und 64Bit).[/URL]

Das mit der TImageList kann ich bestätigen. Allerdings lief meine App mit zwei PNGs noch. Jetzt habe ich noch 3 mehr eingefügt und sie stürzt auf dem iPhone6 ab. Nach entfernen aller Bilder aus der ImageList läuft die App wieder.

Also, bleibt mir vorerst nur übrig TListView durch TListBox zu ersetzen und somit auf TImageList verzichten. Damit läuft die App immerhin auf den 64-Bit Devices, aber weiterhin nicht auf 32-Bit bei mir. :(

Das ist schon irgendwie krass, da investiert man sehr viel Geld in eine Entwicklungsumgebung und die hat dann so viele Bugs, dass man damit überhaupt nichts lauffähig bekommt. Da scheint Embarcadero die QS überhaupt nicht im Griff zu haben.

[Thomas Horstmann]

Theoretisch kann man die Bilder auch aus einer "Resource" laden. Habe ich vor TImageList so gemacht. Allerdings gab es Ärger mit dem AppStore, da die Resourcen intern in einem Pfad gespeichert werden, der von Apple nicht vorgesehen/freigegeben ist. Also geht dieser Weg nicht, da sonst die App nicht akzeptiert wird. Alternativ kann man jedes Bild in einem Image speichern und dann in TImageList zusammenführen.

Ich halte das aber alles für Flickwerk. Im Zweifelsfall lieber mit El Capitan, XCode 7.0.1, iOS 9 Gerät und SDK 8.4 arbeiten. Damit scheint ja alles stabil zu laufen und warten bis ein neues Update kommt.

[Thomas Horstmann]

Zitat:

Zitat von cipher (Beitrag 1317542)

Zitat:

Zitat von Thomas Horstmann (Beitrag 1317536)

Bei meiner App lag es an TImageList. Wenn zwei oder mehr PNG-Bilder enthalten sind, läuft die App auf dem iPad mini 2 nicht mehr (AdHoc und 64Bit).[/URL]

Das ist schon irgendwie krass, da investiert man sehr viel Geld in eine Entwicklungsumgebung und die hat dann so viele Bugs, dass man damit überhaupt nichts lauffähig bekommt. Da scheint Embarcadero die QS überhaupt nicht im Griff zu haben.

Da kann Embarcadero nur bedingt etwas dafür. In der mobilen Welt dreht sich alles schneller. Und wenn man sich die Foren anschaut, scheint bei Apple auch nicht alles stabil zu laufen. Sonst wären wir in so kurzer Zeit auch nicht schon bei Version 9.0.2.

[Rollo62]

Hallo zusammen,

ich habe auch Probleme mit iOS9, (MacBook, Win8.1, VmWareFusion)
unter Rx10 mit dem aktuelsten HotFix PAServer.

Unter Ios32 läuft es, unter iOs64 crasht es schon bei Laden der Form, leider gibt es keine
sinnvolle DebugInfo.

Die Fehlermeldung ist:

Zitat:

EReadError with message "Error reading TSourceItem.Name: External exception"

Ich hatte erst die Styles im Verdacht, kommt nach Abschalten aber genauso.
Jetzt denke ich doch das es eher von der ImageList kommt, die PNG-Dateien habe ich schon mit IrFanView
upgedated, damit war es jedenfalls imer in Ordnung.

Wenn vielleicht jemand etwas dieser Richtung gefunden hat wäre ich für einen Tipp sehr dankbar.
Im Moment weiss ich nicht was von 32 zu 64-Bit schiefläuft.

Rollo

[cipher]

Zitat:

Zitat von Rollo62 (Beitrag 1317551)

Jetzt denke ich doch das es eher von der ImageList kommt, die PNG-Dateien habe ich schon mit IrFanView
upgedated, damit war es jedenfalls imer in Ordnung.

Wenn vielleicht jemand etwas dieser Richtung gefunden hat wäre ich für einen Tipp sehr dankbar.
Im Moment weiss ich nicht was von 32 zu 64-Bit schiefläuft.

Probleme mit der ImageList kann ich definitiv bestätigen. Habe sie in meinem Projekt daher komplett entfernt.
Jetzt läuft die App unter iOS 64bit.
Aber es scheint noch eine Komponente zu geben, die bei mir unter 32bit Probleme macht. Das ist echt ätzend. Vor allem läuft die App auch unter Android bei mir nur noch im Debug Mode aber nicht als Release.
Ich habe irgendwo gelesen, dass es auch ein Problem mit der Push-Komponente im Zusammenhang mit Parse geben könnte.

[Rollo62]

Hallo cipher,

also ich geb dem Ding noch eine Chance.
Ich habe jetzt alle Images aus der TImageList entfernt, und nochmal neu angelegt.
Es könnte sein das ein Bild verschoben/umbenannt worden ist.

Das sollte eigentlich kein Problem sein, weil in TImageList *.fmx Datei die Bilder als Binary gespeichert sind,
nur ist auch noch zusätzliche ein Link zum Orginalbild vorhanden.
Dummerweise mit absoluten Pfaden, so dass ein Verschieben ins Nirwana führt.

Trotzdem bin ich nicht sicher ob es daran gelegen hat, weil ja die App auf ALLEN Plattformen korrekt
lief, von Win32/64, über Mac, iOS32/Simulator, Android.
Nur eben der iOS64 ist gecrasht, das ist schon seltsam.

Nach dem kompletten Löschen, Neuanlegen der Bilder hat es dann auch bei IOS64 funktioniert,
also definitiv ein TImageList Problem.
Aber das möchte ich nicht nochmal bei einem größeren Projekt machen, mit zig Icons ...

Was lerne ich daraus: Ich werde in Zukunft direkt auf iOS64 debuggen, statt wie bisher auf iOS32,
um vielleicht solche Probleme ehere zu erkennen.

Im übrigen hatte ich ähnliche Probleme mit Styles, auch da denke ich das es verwaiste Bilder/Stile sind
die das Ganze zum crashen bringen können.


Rollo

[cipher]

Nach kleiner Pause habe ich mich jetzt wieder an mein kleines Projekt gesetzt um endlich einmal den Fehler etwas einzugrenzen.

Phänomen bei mir: meine App läuft auf 32-Bit-Geräten nur wenn als "Debug" kompiliert. Auf 64-Bit-Geräten dagegen sowohl als "Release" als auch "Debug".

Ich habe mich bei den Compiler-Einstellungen durch die Unterschiede zwischen Release und Debug geklickt und bin schlussendlich zu folgender Einstellung gekommen:

Wenn ich für die iOS32-Bit-Debug Version "Mit Debug-DCUs" auf "True" setze (siehe Bild), dann läuft die App auch als "Release" kompiliert.

http://enlightme.info/ios.png

Hat hier jemand evtl. einen Tipp, warum das so ist oder wie man das noch weiter eingrenzen könnte?

[Sir Rufo]

Einen Fehler bzgl. iOSDevice32/Release habe ich schon gemeldet
https://quality.embarcadero.com/browse/RSP-12408

Du solltest aber irgendeine Fehlermeldung bekommen, bzw. deine App mit ein wenig Logging bestücken damit du sehen kannst wo der Fehler herkommt.

[cipher]

Das Problem ist, dass die App schon abstürzt bevor sie dazu kommt meinen Code auszuführen (also noch beim "booten"):

http://enlightme.info/crash.png

Ich habe den Fehler jetzt eingrenzen können:

Es handelt sich um einen Bug im Zusammenhang mit TPushEvents. Dieses Feature scheint unter Android & iOS32-Bit im Release Mode zum Crash zu führen.

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

Tolle Wurst, da bleibt mir wohl nichts anderes, als abzuwarten bis Embarcadero einen Fix dafür erstellt. :(

[cipher]

Zitat:

Zitat von Sir Rufo (Beitrag 1319626)

Einen Fehler bzgl. iOSDevice32/Release habe ich schon gemeldet
https://quality.embarcadero.com/browse/RSP-12408

Du solltest aber irgendeine Fehlermeldung bekommen, bzw. deine App mit ein wenig Logging bestücken damit du sehen kannst wo der Fehler herkommt.

Das war ein guter Tipp von dir! TPushEvents scheint auch die Supports-Methode aus System.SysUtils zu nutzen, die bei Android/Release und iOS32/Release zum Absturz führt.

Als Workaround habe ich die System.SysUtils.pas in meinen Projektpfad aufgenommen und folgende Methode:

Code:

function Supports(const Instance: IInterface; const IID: TGUID; out Intf): Boolean; overload;

so verändert:

Code:

function Supports(const Instance: IInterface; IID: TGUID; out Intf): Boolean; overload;

Warum das dann funktioniert, weiß ich aber nicht. :-D

[Memnarch]

Ich vermute es liegt dann an dem const der TGUID. IIRC wird ohne const der record zuerst kopiert und dann an die Funktion übergeben. Mit const wird nur eine reference zu dem record auf den stack gepushed. Das heißt du pushed eine reference auf den stack, während dort eigentlich der record direkt erwartet wird. Innerhalb der Funktion wird dann wohl auf invaliden Speicher zugegriffen.

[cipher]

Zitat:

Zitat von Memnarch (Beitrag 1319847)

Ich vermute es liegt dann an dem const der TGUID. IIRC wird ohne const der record zuerst kopiert und dann an die Funktion übergeben. Mit const wird nur eine reference zu dem record auf den stack gepushed. Das heißt du pushed eine reference auf den stack, während dort eigentlich der record direkt erwartet wird. Innerhalb der Funktion wird dann wohl auf invaliden Speicher zugegriffen.

Ja, das könnte sein, aber die IID wird in dieser Methode auch nur als const weitergegeben:

Code:

function Supports(const Instance: IInterface; IID: TGUID; out Intf): Boolean;
begin
  Result := (Instance <> nil) and (Instance.QueryInterface(IID, Intf) = 0);
end;

Definition der QueryInterface:

Code:

function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;

[Memnarch]

SO war das nicht gemeint, was ich meinte war, dass vllt in der deklaration steht, dass da ein const hingehört, aber aus irgendeinem grund im vorkompilierten Delphisource der implementierungsteil kein const verwendet. Gemeint hatte ich also einen unterschied zwischen Interface und Implementation(wobei bei implementation der tatsächlich kompilierte source interessant wäre).

Das sind aber nur Vermutungen.

[cipher]

Nur zur Info:

Mit dem 10 Seattle Update 1 sind alle Probleme, die ich hatte beseitigt. 👍
Push Messages gehen. Und sogar die Transport Security wird für iOS gesetzt.