you can also use services like BugSense (http://www.bugsense.com/) if you dont feel like running your own server to collect/manage crash reports
On Wednesday, June 26, 2013 2:27:52 AM UTC+3, Ted Hopp wrote: > > On Tuesday, June 25, 2013 5:02:43 PM UTC-4, a1 wrote: > >> >>> You are attacking a strawman. I've commented on a very specific quote >> from original post: >> >>> The alternative is to start removing catch clauses so that the app will, >>> in fact, crash and the developer can at least see something. This seems >>> like a silly approach, though. >> >> From this and rest of the post I get an impression (maybe wrong) that OP >> catches aggressively everything - and this is of course invalid approach >> (that makes debugging harder), and I did explain why. >> > > Well, I never said I was catching everything indiscriminately. I catch > things that I can do something about. Sometimes there's a silent fall-back > and the app doesn't even need to bother the user about it. Sometimes I need > to involve the user in what to do next. Sometimes I simply tell the user > that something didn't work. In all those cases, the app doesn't crash, but > in many of those cases, as a developer I'd like to see what happened; there > may be an underlying flaw in our code or an unforeseen incompatibility with > the user's device. What I was asking about was whether there was a way of > obtaining the benefits of a crash report without forcing the app to crash > (that was what "removing catch clauses" was referring to). Call it a > "glitch report". What I've been doing in cases where I tell the user that > something went wrong is to provide a button that composes an email for the > user to review and then send to us. This seems bad for several reasons: > > - it's a pain to code > - users are often reluctant to send emails (or to take any action > other than dismiss an error notification dialog) > - an error message is already disruptive to the user; asking the user > to take some action makes the disruption worse > - it's out-of-band communication > - it would be useful to report problematic events without involving > the user (especially events for which the user would otherwise not need to > be involved) > > I'll look into the ACRA-style bug reporting that TreKing suggests and at > the crashlytics and android-log-collector tools suggested by Nathan. At > first glance these look interesting, although something integrated with the > developer console would be ideal. > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
