Intelligentes Absturzhandling in Android

Crash in Style

Tam Hanna


Murphy’s Law besagt, dass der Optimalfall nur äußerst selten eintritt. In der Praxis sollte der Entwickler immer vom Worst Case ausgehen. In dieser Situation tritt der Absturz bei einem User auf, dessen Freundschaft zum Chef-Programm-Reviewer der New York Times nur von seiner technischen Unkenntnis getoppt wird. Selbst in diesem Fall ist es möglich, den Schaden durch intelligente Vorbereitung zu minimieren. Es gibt eine Vielzahl von Methoden, die Abhilfe versprechen – Zeit, sich einige davon anzusehen.

Dump to File

Die wohl primitivste Form der Fehlerberichterstattung ist aus der Zeit des Palm OS bekannt. Nach dem Start erstellt das Programm eine für den Enduser gut zugängliche Log-Datei, die während der Ausführung der Apps mit Informationen über den Zustand (aktive Routine etc.) gefüllt wird. Stürzt das Programm ab, so soll der User die Datei an den Entwickler senden – der letzte Eintrag erlaubt bei ausreichender Platzierung von Log Calls Rückschlüsse über das, was im Programm als Letztes vorging und wo der Hund begraben liegt.

Dabei sollte man beachten, dass das Terminieren des eigenen Programms unter Umständen auch noch nicht geschriebene Daten eliminiert. Aus diesem Grund ist es manchmal sinnvoll, das eigentliche Übermitteln in einen Service auszulagern, der von der im Vordergrund laufenden Anwendung unabhängig ist. Im Beispiel A360­Crash1 führen wir das vor.

Als Erstes erstellen wir unseren CrashReport-Service. Hier ist es besonders wichtig, den von Eclipse automatisch erstellten Konstruktor anzupassen. Der Codegenerator schreibt der Routine nämlich einen Parameter ein. Entfernt der Entwickler diesen nicht vor der Ausführung, so scheitert das Betriebssystem beim Erstellen des Services mit einer nichtssagenden Exception (Listing 1).

Listing 1public class ErrorReporter extends IntentService {  public static final String INTENTSTRING ="com.tamoggemon.a360crash1.intent.CALLERRORREPORTER";  public ErrorReporter() { super("TAG"); }

Der Intent-String dient als „Speicherablage“ für den Intent, der zum Aufruf des Services dient. Tag erlaubt die Identifizierung des Threads im Debugger. Da wir bei diesem Programm keine komplexen parallelen Algorithmen implementieren, ist der übergebene String ohne Relevanz. Die eigentliche Intelligenz findet sich in onHandleIntent() – die Methode sieht aus wie in Listing 2.

Listing 2protected void onHandleIntent(Intent intent) { try { boolean newFile=false; File writeFile=new File(intent.getStringExtra("FilePath"))...

Intelligentes Absturzhandling in Android

Crash in Style

Tam Hanna


Murphy’s Law besagt, dass der Optimalfall nur äußerst selten eintritt. In der Praxis sollte der Entwickler immer vom Worst Case ausgehen. In dieser Situation tritt der Absturz bei einem User auf, dessen Freundschaft zum Chef-Programm-Reviewer der New York Times nur von seiner technischen Unkenntnis getoppt wird. Selbst in diesem Fall ist es möglich, den Schaden durch intelligente Vorbereitung zu minimieren. Es gibt eine Vielzahl von Methoden, die Abhilfe versprechen – Zeit, sich einige davon anzusehen.

Dump to File

Die wohl primitivste Form der Fehlerberichterstattung ist aus der Zeit des Palm OS bekannt. Nach dem Start erstellt das Programm eine für den Enduser gut zugängliche Log-Datei, die während der Ausführung der Apps mit Informationen über den Zustand (aktive Routine etc.) gefüllt wird. Stürzt das Programm ab, so soll der User die Datei an den Entwickler senden – der letzte Eintrag erlaubt bei ausreichender Platzierung von Log Calls Rückschlüsse über das, was im Programm als Letztes vorging und wo der Hund begraben liegt.

Dabei sollte man beachten, dass das Terminieren des eigenen Programms unter Umständen auch noch nicht geschriebene Daten eliminiert. Aus diesem Grund ist es manchmal sinnvoll, das eigentliche Übermitteln in einen Service auszulagern, der von der im Vordergrund laufenden Anwendung unabhängig ist. Im Beispiel A360­Crash1 führen wir das vor.

Als Erstes erstellen wir unseren CrashReport-Service. Hier ist es besonders wichtig, den von Eclipse automatisch erstellten Konstruktor anzupassen. Der Codegenerator schreibt der Routine nämlich einen Parameter ein. Entfernt der Entwickler diesen nicht vor der Ausführung, so scheitert das Betriebssystem beim Erstellen des Services mit einer nichtssagenden Exception (Listing 1).

Listing 1public class ErrorReporter extends IntentService {  public static final String INTENTSTRING ="com.tamoggemon.a360crash1.intent.CALLERRORREPORTER";  public ErrorReporter() { super("TAG"); }

Der Intent-String dient als „Speicherablage“ für den Intent, der zum Aufruf des Services dient. Tag erlaubt die Identifizierung des Threads im Debugger. Da wir bei diesem Programm keine komplexen parallelen Algorithmen implementieren, ist der übergebene String ohne Relevanz. Die eigentliche Intelligenz findet sich in onHandleIntent() – die Methode sieht aus wie in Listing 2.

Listing 2protected void onHandleIntent(Intent intent) { try { boolean newFile=false; File writeFile=new File(intent.getStringExtra("FilePath"))...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang