Einige Probleme mit einer benutzerdefinierten Klasse, die AsyncTask erweitert. Meine App zielt auf Android 4.0.3 und der unten stehende Code funktioniert gut für 30+ Leute, die ihn testen. Es gibt jedoch zwei Benutzer, bei denen die App abstürzt, wenn ich wie unten eine neue AsyncRequest aufruft.
Ich habe einen funktionierenden Logger, der in einer Textdatei im Benutzerspeicher aufzeichnet und den Eintrag nicht im AsyncRequest-Konstruktor aufzeichnet. Also muss ich davon ausgehen, dass der Absturz vor dem Aufruf des Konstruktors passiert.
Eines der beiden Geräte, bei denen dieser Absturz auftritt, ist offenbar Android 4.0.4. Nicht sicher, was das andere Gerät ausführt. Leider habe ich keinen Zugriff auf die beiden Geräte und kann daher keine Logcat-Ausgabe sehen.
Jede Eingabe darüber, warum die Objekterstellung einen Absturz verursacht, würde sehr geschätzt werden.
%Vor%Und hier ist die vollständige AsyncRequest-Klasse
%Vor%EDIT: Wie in den Kommentaren unten.
Hier ist die vollständige Methode, die ich meine benutzerdefinierte AsyncTask aufrufen. Alle Logging-Nachrichten, die ich bis zur Erstellung der AsyncTask erstellt habe, werden im Log angezeigt. Keine der Ausnahmen sind.
Die Protokollierung zeigt den URL-Wert unmittelbar vor dem Erstellen meiner AsyncRequest an und die URL ist überhaupt nicht fehlerhaft. Das erwarte ich.
%Vor% Bedenken Sie zunächst, dass executeOnExecutor() nicht vor Api 11 verfügbar ist. Sie haben bereits gesagt, dass das Problem bei einem 4.0.4-Gerät liegt, aber denken Sie daran.
Hier sind die Schritte, die ich unternehmen würde, um das Problem zu beheben. Es sieht so aus, als ob Sie bereits ein paar davon mit all diesen ReportInfo() -Aussagen gemacht haben.
Erstens nehme ich an, dass Ihr Aufruf an GetServerInfoAsync in try...catch liegt, korrekt? Ich überprüfe aufgrund Ihrer Verwendung von Throw . Außerdem haben Sie bereits die Protokollierung hinzugefügt, um nach Fehlern mit der URL zu suchen. Da die Fehler auftreten, bevor Sie sie tatsächlich verwenden, kann der Fehler nicht mit der URL oder Internetberechtigungen auftreten.
Sie rufen die AsyncTask-Generierung mit Verweisen auf callback und context auf. Sie haben die Protokollierung über ReportInfo() hinzugefügt, die auf den Kontext verweist, und diese funktionieren, ja? Daher ist Kontext nicht dein Problem. Sie überprüfen jedoch nie, was callback ist. Sie werfen einen Fehler, wenn es null ist, aber Sie tun nie etwas damit, bevor Sie AsyncRequest aufrufen. Probieren Sie ReportInfo(callback.toString()) aus, um zu sehen, was es ist.
Wenn alles andere fehlschlägt, scheint es ein Fehler beim Threading zu sein. Warum nicht versuchen, nur AsyncTask anstelle von executeOnExecutor() zu verwenden. Brauchen Sie wirklich mehr als einen Hintergrund-Thread?
Tut mir leid, dass ich nicht früher zurück gekommen bin. Es gab zahlreiche Probleme hier.
Zunächst mal ... Dank des Vorschlags von Wolfram konnte ich die Ausnahme abfangen und feststellen, dass mein FileLogger (und eine andere Klasse) eine statische Referenz war und diese beiden Tablets die Referenz zur Laufzeit nicht finden konnten. Also habe ich Logging von meinen asynchronen Methoden entfernt.
Zweitens gab es nach den obigen Änderungen ein weiteres Problem, nämlich dass ein Looper vom Hauptthread aus aufgerufen werden musste. Es stellte sich heraus, dass diese beiden Tablets meine asynchrone Aufgabe nicht vom Hauptthread aus anriefen. Also musste ich den Async-Aufruf in einem neuen Handler mit dem MainLooper einschließen.
Tags und Links android android-asynctask