For those of you that are comfortable using Flurry, a similar approach
works nicely.  Flurry already collects uncaught exceptions, but for
some reason doesn't actually log the stack trace.  To get around this,
I add an exceptionHandler that logs a Flurry event with the stack
trace as a parameter, like this:

                OutputStream lOS = new ByteArrayOutputStream();
                PrintStream lPS = new PrintStream(lOS, true);
                t.printStackTrace(lPS);
                lPS.flush();
                Map<String, String> lArgs = new HashMap<String, String>();
                lArgs.put("stackTrace", lOS.toString());

                SharedPreferences lPrefs =
PreferenceManager.getDefaultSharedPreferences(pCtxt);
                if(lPrefs.getBoolean(PREFS_REMOTE_DEBUG, true)){
                        FlurryAgent.onEvent(FLURRY_EVENT_UNCAUGHT_EXCEPTION, 
lArgs);
                }

One big advantage of this approach is that Flurry collects lots of
metrics w.r.t. the frequency, timing, and sequencing of the events.
Works very, very nicely.





On Feb 26, 10:10 am, Streets Of Boston <flyingdutc...@gmail.com>
wrote:
> I haven't made it public yet (i will at some point), but i have a
> similar system for my apps.
>
> The process of my activities registers itself by calling
> Thread.setDefaultUncaughtExceptionHandler(uncaughtXcptHandler) and
> binds to service that i wrote that runs in a different process (since
> my app will be dying because of an exception, it's tricky to properly
> handle the exception in the dying process itself).
>
> Then in the uncaughtXcptHandler.void uncaughtException(Thread t,
> Throwable e), I write out an error-log file with the stack-trace and
> some other info. Then i call an asynchronous method on my service that
> will pop up a dialog allowing the user to send me the error report or
> not. If the user clicks 'Yes', then the error-log file is read and
> sent to my webserver. My webserver then sends me an e-mail. This way,
> users can remain anonymous (no e-mail/reply address necessary).
>
> I let my app die immediately after calling the asynchronous method. If
> my app couldn't bind to the service for any reason, the old and
> trusted force-close message from Android is shown instead.
>
> On Feb 25, 3:10 pm, focuser <linto...@gmail.com> wrote:
>
> > Hi fellow Android developers,
>
> > How many times have you asked users to send you the logcat result to
> > track down a nasty force-close?  How many users have actually replied?
>
> > It's not that users are lazy or busy.  Having to run the "logcat"
> > command or download an external log collector app just means too much
> > trouble for them.  It should be much simpler.  It should be just one
> > tap.
>
> > In fact I'm surprised (or being ignorant) that an easier error
> > reporting mechanism has not existed yet in the Android API, especially
> > for the infamous force-close.  That is why I coded and open-sourced
> > "Android, send me logs!", a small code library that makes it easy to
> > detect force-close and send logs from within your own apps.  You can
> > program it to report errors with just one tap, and also include your
> > own tracing information.
>
> > Please check it out athttp://code.google.com/p/android-send-me-logs/.
> > It's still in very early stage, and I would appreciate your critism,
> > suggestions, comments, or even code contributions.
>
> > Linton Ye

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to