If enough other devs do use it, I would put some effort into producing reports to make it more useful, but one option that I will do immediately is to put a button on the form listing your last ?? exceptions to download it in a comma delimited format so you can import it into a spreadsheet and do anything you want with it.

The only paid option I am even considering is putting an optional Pay Pal donate button on the web page the devs use to view the logged exceptions. I'd be happy if that even covered the additional server expenses.

I should also mention that devs will (soon) have the choice to send the exceptions to their own server if they prefer (the option is already in the code), but they will have to agree to some very specific provisions not to spam users before using it. When I have time to figure out the licensing, and set it up, I will put the code up on one of the open source sites so that other people can improve it.

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 10:53 AM, Sean Chitwood wrote:
I believe option A is the best.

One thing you might consider as a premium option for developers is reporting showing which crashes are more prevalent than others. I know Microsoft does this internally for application crashes reported via Watson.

--Sean

Calendar: http://www.google.com/calendar/embed?src=darkmane%40gmail.com
Livejournal: http://darkmane.livejournal.com

Every 5 minutes you spend writing code in a new language is more useful than 5 hours reading blog posts about how great the language is.




On Sat, Sep 18, 2010 at 10:34 AM, Prakash Iyer <thei...@gmail.com <mailto:thei...@gmail.com>> wrote:

    I have thought along similar lines. I think it should just be
    option a. Don't confuse the user with options. In fact don't even
    allow user to reply back directly.

    On Sep 18, 2010 1:19 PM, "Brad Gies" <rbg...@gmail.com
    <mailto: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 would think they asked for their email addresses to be
    confidential, when they actually checked the other option, and
    would be upset if they found out later. It's also a bit more work
    for me, for maybe very little benefit.

    c)    Don't bother keeping the email addresses confidential. All
    my own apps work this way, and it is useful, but I'm sure either
    of the other two options would have a better success rate of
    obtaining the email addresses, and therefore would be better for
    most devs to get information about problems in their apps.

    I don't try the a) or b) options for myself because obviously I
    could see the email addresses in my log files if I wanted to
    look, and it would be a little deceitful to tell the user their
    email would be confidential in that case, even if I did use them
    properly ... BUT, I can do that for other developers without
    stretching the truth at all, so I think it's worth the effort if
    other devs want to use it.

    So, please let me know what your opinions are.

    I'm also hoping to get some idea of how many developers might
    want to use this. I've already done almost all the work, so it
    will be released even if nobody wants to use it. It freaks me out
    a little to open up my server to an unknown amount of use, but I
    am well setup to increase server capacity quickly if needed, and
    I don't think the cost of doing this will be too horrible (I
    hope). ...


    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

-- 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
    <mailto:android-developers@googlegroups.com>
    To unsubscribe from this group, send email to
    android-developers+unsubscr...@googlegroups.com
    <mailto:android-developers%2bunsubscr...@googlegroups.com>
    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 post to this group, send email to
    android-developers@googlegroups.com
    <mailto:android-developers@googlegroups.com>
    To unsubscribe from this group, send email to
    android-developers+unsubscr...@googlegroups.com
    <mailto:android-developers%2bunsubscr...@googlegroups.com>
    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 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

--
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