[android-developers] Re: Exception Logging
First off, you are to be commended for putting this much effort into diagnostics. Even the big players are just catching onto this (as witnessed by the fact that there's no facility for this built into the phone). Real time diagnostics are much friendlier for the user than saying Please reproduce with logging turned on or whatever, and generally the information you obtain is more comprehensive and helpful (since you're more apt to see several instances of essentially the same bug, but with slightly different symptoms). There is a slight danger that the paranoid among users will believe that you're secretly collecting data on them. It's probably better to somehow obtain their permission to send the failure report to you, vs doing it silently and unconditionally. Asking them at the same time if they want to provide an email address is good, though. In terms of options, I'd say KISS -- keep it simple. Unless the facility is going to be picked up by a trusted authority (say, Google), just have email address be reported back to the developer. Promise, of course, that the email address will be kept private (and make any users of your facilities aware that they're making this promise) but don't bother with the complex forwarding service -- users are no more apt to trust it than they are to trust the individual developers, and in fact they're probably more likely to be confused by the options and not agree at all. On Sep 18, 12:19 pm, Brad Gies rbg...@gmail.com wrote: This is a bit long winded (sorry, but I need to explain what I'm doing before I can ask the question). Just wondering if I could get a few (hopefully few hundred) opinions on this : I developed an Exception Handler for my first Android app (released the first month the market opened), which logs all uncaught exceptions to my server, and since then I have gradually refined it and improved. I'm now using it in my 4th public Android app and a few private apps, and I find it extremely helpful to find bugs that don't happen to me when I'm testing. One thing I added that is proving to be extremely useful is an AlertDialog when the exception occurs asking the user if it is OK to contact him/her if I need more information to be able to fix the problem, and a box for them to enter their email address if they agree. I don't have good numbers for you on the acceptance rate because most of my public apps already have the users email address and for the private apps the company enforces their compliance (or supplies the emails for me to use). BUT... it looks like about 20% of users do enter their email address if asked, and that is more than enough to be very useful. I think I can increase the percentage of users that do supply their emails addresses, and that is what my question is about :). (I will ask it soon) First, It has occurred to me that my Exception Logger might be even more successful for me if other developers were also using it because users might have seen it before and trust it when they first see it in my apps. That obviously would only happen if quite a few developers were using it. Anyway... sorry it's already getting long, and I AM trying to keep it from becoming a book. I have repackaged my Exception Logger and will release it in the next couple of days for other developers to use (the price is the good one - FREE). I will host the thing on my server (FYI it's a Cloud based server so we can increase capacity if needed) and any developers using it will be able to log in and view the exceptions their app has generated, and sort by time/date, user, and other fields. NOW.. the question: I think the Exception Logger would be more successful getting the users to agree to be contacted IF their email addresses were kept confidential. Actually, I don't think there is much doubt that would be the case. BUT, there is a tradeoff. Obviously, most developers would prefer to see the email addresses so they can manage the contacts a bit more effectively without using my website to do it, BUT if the email addresses are not confidential, fewer users will give them. So here are what I think are the options: a) keep the email addresses confidential, but developers can send the user an email using my website, include both a reply address which goes to my website and then forwards the email to the developer, and also the developers email address so the user could respond directly to the developer if they choose. I'm sure this would have by far the highest success rate for getting contact info but means devs have to use my website to send the first email at least. b) give the user a choice of keeping the email address confidential or just giving it to the developer. This should also have a fairly high acceptance rate by the user, but complicates the process for them because they would actually have to read the instructions to figure out how it works, and quite possibly a few users
Re: [android-developers] Re: Exception Logging
It's probably better to somehow obtain their permission to send the failure report to you, vs doing it silently and unconditionally. Asking them at the same time if they want to provide an email address is good, though. Just so you know... how it works now is that the exception is logged immediately without the email address the first time an exception occurs. The server returns the id number of the exception, and THEN the dialog pops up and asks if they would mind supplying an email address. The user has the choice of supplying the email address and choosing Yes Always send it, Send it this time (in which case they will be asked again on the next exception, but their email address is kept so they never need to enter it again, or the third option is No, and don't ask again in which case they will never see the dialog again for the life of the app. If they answer Yes, always then they will never see the dialog again either, and the email address is just included in the original post when it's sent. Note that it is programmed this way because there are occasions when an exception occurs in the onCreate of your activity and the user interface is unstable, so even if I try to pop up the dialog then, the user won't see it. When the exception is logged, I use a couple of Preferences to keep track of what's sent, and all info needed for the dialog box, and when the Class is created, I check to see if an Exception occurred and the dialog will popup then (on the next activity created) OR I also have a function that can be called in the onResume event of each activity to check to see if a dialog is needed. If you use that function then the user will get the dialog box almost immediately after the exception occurs even if they use the back button to get out of the activity that caused the problem (the only time this doesn't work is if the exception happens on the onCreate of the main entry activity), and I would hope most devs have that covered already. The Exception would still be logged, but the user would never see a dialog box because the user interface would never be stable. There is also a Let me see what's sent button and a Help/Info button to give some information on what it is, and what it's doing. users are no more apt to trust it than they are to trust the individual developers That's a good point, and certainly true right now. I would hope if the Exception Logger is used by enough devs though that users would see it and learn to trust it. BUT... if the user clicks on the Help/Info button I already have the statement that the dev has agreed NOT to spam them, and maybe that is enough for option c) to be a good option. It's certainly a lot less website work for me because I already have all of that code working for myself... I'm just in the process of making it multi-dev friendly :). I do use option c) myself, and it works well I just have it in my mind that the other options would be even more effective...but, I'm not positive and that's why I'm asking for other opinions. The unstated part of the question is what would other devs find most acceptable? Sincerely, Brad Gies --- Bistro Bot - Bistro Blurb http://bgies.com http://bistroblurb.com http://ihottonight.com http://forcethetruth.com --- Everything in moderation, including abstinence Never doubt that a small group of thoughtful, committed people can change the world. Indeed. It is the only thing that ever has - Margaret Mead On 18/09/2010 11:00 AM, DanH wrote: First off, you are to be commended for putting this much effort into diagnostics. Even the big players are just catching onto this (as witnessed by the fact that there's no facility for this built into the phone). Real time diagnostics are much friendlier for the user than saying Please reproduce with logging turned on or whatever, and generally the information you obtain is more comprehensive and helpful (since you're more apt to see several instances of essentially the same bug, but with slightly different symptoms). There is a slight danger that the paranoid among users will believe that you're secretly collecting data on them. It's probably better to somehow obtain their permission to send the failure report to you, vs doing it silently and unconditionally. Asking them at the same time if they want to provide an email address is good, though. In terms of options, I'd say KISS -- keep it simple. Unless the facility is going to be picked up by a trusted authority (say, Google), just have email address be reported back to the developer. Promise, of course, that the email address will be kept private (and make any users of your facilities aware that they're making this promise) but don't bother with the complex forwarding service -- users are no more apt to trust it than they are to
[android-developers] Re: Exception Logging
Even the big players are just catching onto this (as witnessed by the fact that there's no facility for this built into the phone). It is built into later Android versions. The normal force close dialog has an extra button called Report. That leads to a screen where extra information can be added which has buttons Preview and Send, although the user can just hit back from there as well. There's also a long scrolling dialog full of legalese with Accept and Decline buttons that showed up the first time I went through this, but that might have been because the app that crashed was the Market app itself. That dialog didn't show up in subsequent crashes I observed, although those were for non-Google apps, although still distributed by the Market. So either it remembers your choice for the legalese step, or that only shows up for Google apps. Anyway, for normal developers, the information ends up on the Market developer console. There's a link called Errors you can click on next to each published app to see reported errors. Flurry, the free app metrics service, also has an uncaught exception handler that it sets, unless you specifically call the FlurryAgent.setCaptureUncaughtExceptions function to disable it. These errors are reported in the Flurry analytics for the app. So error reporting of this sort isn't rare at all. The official reporting does have flaws, however. It isn't available on older versions of Android. I assume it isn't active for non-Google, non-Market distributed apps. Also, hardly any users actually use it. I suspect it's just too much work for a user to go through this multiple opt-in every time. I think an opt-out for sending stack traces on upgrading or activating a phone with a version of Android that supports it would have been much more helpful to users and devs alike. Having hardly any errors reported just leads to lower quality apps for everyone, and stack traces are far more useful than 1 star, short cryptic comments on the Market details page. A compromise could have been opt-in/opt-out on app install, or on first install of an app by each developer, or explicit opt-out of stack trace sending on crash at least, processed separately from the form. The form has a manual input section that probably makes lots of users blow reporting off, because it looks like work. They could have still kept the per-crash opt-in for sending additional information with any of those solutions to protect private information, and still gotten devs more stack traces to work with. I guess the biggest danger I've heard people mention is apps sending private data in the message property of exceptions, which is included in stack traces. This might be possible even for an app without the internet permission, which users might trust more because they think it can't send data. On Sep 18, 2:00 pm, DanH danhi...@ieee.org wrote: First off, you are to be commended for putting this much effort into diagnostics. Even the big players are just catching onto this (as witnessed by the fact that there's no facility for this built into the phone). Real time diagnostics are much friendlier for the user than saying Please reproduce with logging turned on or whatever, and generally the information you obtain is more comprehensive and helpful (since you're more apt to see several instances of essentially the same bug, but with slightly different symptoms). There is a slight danger that the paranoid among users will believe that you're secretly collecting data on them. It's probably better to somehow obtain their permission to send the failure report to you, vs doing it silently and unconditionally. Asking them at the same time if they want to provide an email address is good, though. In terms of options, I'd say KISS -- keep it simple. Unless the facility is going to be picked up by a trusted authority (say, Google), just have email address be reported back to the developer. Promise, of course, that the email address will be kept private (and make any users of your facilities aware that they're making this promise) but don't bother with the complex forwarding service -- users are no more apt to trust it than they are to trust the individual developers, and in fact they're probably more likely to be confused by the options and not agree at all. On Sep 18, 12:19 pm, Brad Gies rbg...@gmail.com wrote: This is a bit long winded (sorry, but I need to explain what I'm doing before I can ask the question). Just wondering if I could get a few (hopefully few hundred) opinions on this : I developed an Exception Handler for my first Android app (released the first month the market opened), which logs all uncaught exceptions to my server, and since then I have gradually refined it and improved. I'm now using it in my 4th public Android app and a few private apps, and I find it extremely helpful to find bugs that don't happen to me when I'm testing. One thing I added that is proving
