The source and binaries of the prototype have been posted on Github
for any interested. Comments are welcome.
http://heroicefforts.github.com/Viable/intro.html
On Mar 3, 2:29 am, laphroaig15 laphroai...@gmail.com wrote:
Dupes were a concern for me as well; not only on the receiving side,
but
Hi guys,
Thanks for your informative comments and discussion. In Android,
send me logs!, I am just taking the simplest possible approach -
sending logs by email looks like the simplest and most reliable way
and best understood by users.
Of course, the anonymity of users might be an issue. But
Dupes were a concern for me as well; not only on the receiving side,
but also for bugging the heck out of users who might encounter the
crash regularly. The approach I've implemented so far is to store a
digest with the issue. If the issue has already been reported by
another user, then the app
What's nice about Apple's approach here is that developers
don't have to do anything... it's a good way of improving the code
quality for *all* apps. I was pretty surprised and happy when it
came online a month or two ago because it confirmed that what
was crashing across our user base were
There's multiple third party libraries that already have this functionality.
Mike
On 02/25/2010 07:38 PM, mssmison wrote:
I love this idea!
I'd like to build it into the source itself, that would be a life
saver.. lol
--
You received this message because you are subscribed to the
I've been working on a 3rd party application that uses meta-data and
exception handling as suggested above to allow users to submit this
data to a developer's issue tracker and to browse said tracker. I
plan to put it up on github next weekend. It's more of a prototype at
the moment, but I'm
Inserting a try {} catch {xxxException ...} in the code an be hard...
if the crash occurs in a place we don't expect/suspect of not being
stable.
A solution for Google team, would be in the Manifest.xml to add
field :
sendErrorLogsTo=m...@me.com
So, for each Force Close we could receive a mail
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
On 02/25/2010 11:57 PM, focuser wrote:
Mike - I think Apple's approach may be good for Apple, and probably
not that compatible with the openness of Android?
Also, what's better of Apple's approach other than that users don't
have to give their identity (email addresses etc) to individual
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,
Just pointing out an alternative as well (I've used it in a few apps):
http://code.google.com/p/android-remote-stacktrace/
- Dan
On Fri, Feb 26, 2010 at 11:58 AM, dadical keyes...@gmail.com wrote:
For those of you that are comfortable using Flurry, a similar approach
works nicely. Flurry
I take it a step further, and send one event for each exception cause
(up to three).
I also process the stacktrace to make it more compact (taking out
filenames, removing package prefixes that I expect, etc.) so that more
trace fits within Flurry's limits.
I find it useful already, even though my
I love this idea!
I'd like to build it into the source itself, that would be a life
saver.. lol
--
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
Mike - I think Apple's approach may be good for Apple, and probably
not that compatible with the openness of Android?
Also, what's better of Apple's approach other than that users don't
have to give their identity (email addresses etc) to individual
developers? If you suggest it here, we could
14 matches
Mail list logo
