Crash Reporter

Hej alla duktiga utvecklare.. vill bara uppmärksamma er på detta nedan:

Såg i en tråd där en utvecklare (johannilsson, sthlm traveling) har implementerat en crash reporter i sin app vilket jag tycker är suveränt... nåt ni andra duktiga utvecklare kanske borde snegla lite på för en bättre utveckling av era appar..
mvh

 

Tackar. Tror jag skall lägga till det till snowstorm också.

 

Värt att nämna är att det finns fler implementationer som gör samma sak bl.a den här, http://code.google.com/p/android-remote-stacktrace/

 

Utvärderade du de olika? Vilken valde du, och varför?

 

Tänkte köra remote-stacktrace först. Men jag gillade idén med att låta användaren maila in den själv. Då har den som fick felet även en möjlighet att lägga in ytterligare beskrivning samt att jag har möjlighet att maila tillbaka för ytterligare frågor om så skulle behövas.

Gillar också att man gör det synligt att man faktiskt skickar in en rapport om ett fel, men det är helt klart en smakfråga och även beroende på hur mycket fel appen producerar. Om det visar sig att jag får in väldigt många rapporter kan det kanske vara en idé att göra det i bakgrunden istället för att inte irritera med både FC och en dialog hela tiden.

Tror datan de båda skickar är i stort sett samma i övrigt.

 

Ok. Tack. Gillar också mer när användaren har ett val. Vill inte att de skall tro att man skickar något data i smyg.

 

Någon mer än jag som får en infinite loop på denna?

uncaughtException anropas om och om igen tills en ANR dyker upp :/

 

Vilken av de båda får du det här på?

 

Ahh sorry, den som länkas här i tråden. Den mail-baserade.

 

Jag har den implementerad i min app och har inte sett något fel eller någon som har klagat på nya krasher, brukar ofta få en kommentar eller mail vid krasher. En sak som jag gjorde fel på först kommer inte ihåg hur det felet artade sig men det var att jag skickade in fel context till checkErrorAndSendMail.

Så här gjorde jag först. Se getApplicationContext.

Kod:

final ErrorReporter reporter = ErrorReporter.getInstance();
reporter.checkErrorAndSendMail(getApplicationContext());

Men när jag bytte till så funka det bättre.

Kod:

final ErrorReporter reporter = ErrorReporter.getInstance();
reporter.checkErrorAndSendMail(this);

Vet inte om det här är relaterat till felet du får dock.

 

Nej var inte så, men tror jag hittade felet nu, var en taskig egen kodsnutt jag lagt till som blivit lite fel, dock är det ju konstigt att jag fick exakt samma fel när jag testade att kopiera all den koden rakt av. Jaja skitsamma, funkar nu

Edit: Eller nej, ahh riktigit konstigt det här, händer bara ibland, helt random. :/
Får väll leta lite till.

 

Skrik till om du hittar vad som orsaker det, man vill ju helst inte att den delen som skickar krashrapporter ska vara den som krashar

 

Nej känns ju lite skumt, letar för fullt. Testa du att läga till en kodsnutt som krachar programmet på menu knappen t.ex.
Typ:

Kod:

File f = null;
f.getPath();

Och se om du också får det ibland. Du har kanske redan testat men jag kan inte begripa det.

Vilken Android version kör du?

Edit: Tror jag hittat problemet, det uppstår efter att man roterat skärmen, vet inte varför och har ingen lösning än, ska titta på det mer.

 

Okej, så ja, nu har jag hittat en lösnig, problemet är att koden i Init(Context) kallas ytterligare en gång men själva exception handlern förstörs ju inte när man roterar skärmen då den är static. Min lösning är att inte ropa Init från din Activity utan ändra getInstance() till följande och ropa Inet där direkt så du aldrig behöver tänka på det mer.

Kod:

static GlobalExceptionHandler getInstance(Context context)
	 {
		 if (S_mInstance == null )
		 {
			 S_mInstance = new GlobalExceptionHandler();	
			 S_mInstance.Init(context);
		 }
		
	 	return S_mInstance;
	 }

Då ropas den bara en gång, när den behövs dvs när den klassen skapas.

Här är hela min ExceptionHandler class om du vill kolla:
http://pastebin.org/79897

Och från vår Activity anropar vi då denna på följande sätt:

Kod:

GlobalExceptionHandler eHandler = GlobalExceptionHandler.getInstance(this);
//eHandler.Init(this);
    
eHandler.CheckErrorAndSendMail(this);

 

Hmm, jag startar den iofs från en klass som extendar Application. Liknande.

Kod:

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        final ErrorReporter reporter = ErrorReporter.getInstance();
        reporter.init(getApplicationContext());
    }
}

Se om det gör någon skillnad för dig, har nämligen inte märkt någon skillnad vid rotering här. Sitter på en magic med 1.5 orginal.

Skapade en force close genom att lägga in det här bara.

Kod:

((String)null).toString()

 

Kollade just på koden för ErrorReporter, och man kan lugnt säga att han som skrivit den inte är Javautvecklare. Svårt att hitta fler fel mot style guidelines..... men det var inte det jag skulle skriva om

.. Det hade varit kul om man även hade kunnat få med en del av loggen så att man kan se vad som hänt precis före felet uppstod. Det är ju inte alltid så att det egentliga felet kommer från den nuvarande tråden.

Funderar på om man borde ta och kolla lite på hur en log collector (t.ex http://code.google.com/p/android-log-collector/source/checkout) läser loggen, och sedan integrera det med ErrorReporter

 

Håller med, har märkt att en del rapporter har varit lite ur context, kanske vi skulle kunna göra en fork ihop som vi kan underhålla?

 

Jag har inte kollat på den koden än, men det låter bra

 

Okej ja det är ju ett annat sätt att lösa samma problem, antar att din application class är den som startar först och sen därifrån startar din activity med tillhörande UI. På så vis kalla ju inte onCreate() i din Application class när du roterar skärmen utan den är väll redan död då. Men ErrorReportern lever ju kvar och gör vad den ska.
Jag kan inte göra på detta viset då det finns två sätt att öppna mitt program, antigen via lunchern eller vi ett Intent...

 

Har samma problem själv med både intent och launchern. Det var därför jag extenda Application, onCreate i den kör alltid först. Måste dock lägga till den under name i application elementet i manifestet vilket jag missade först.