Certainly interesting but there are other solutions. >> 1. It doesn't engage the user to acknowledge that a problem has occurred >> (mea culpa). Not true, you can pop up a message box in the default handler and tell them an error occurred.
>>2. It doesn't elicit contextual information from the user. Again in the message you can ask them if they want the error sent to your server. >>3. It doesn't help to provide the user visibility into the state of issues >>for the application (bugs nor enhancements). Depending on how your app identifies the error you can tell them what it is. Also providing a change log in your app could be valuable. >>4. It requires that my application request internet permission Well yes, most applications want this anyway (we are dealing with smart phones here). If you let the users know that it is for bug reporting in the description they should be fine with it. If the user doesn't choose to install it then I see that as an issue because I won't know about the error, but yes then you are not dependent on the internet permission in your standalone app. Broadcast events would work to make it usable with several apps but I'm not sure how much information you can stuff into a broadcast... For example I would at least want a full stack trace and cause trace from the exception that occurred, and this can easily be 20+ lines. -theSmith On Jan 30, 11:30 pm, laphroaig15 <laphroai...@gmail.com> wrote: > I'd finished up my first android application, a simple power > management app, and was preparing to release it when I realized that I > didn't have a proper design or infrastructure for bug reporting. One > of my pet peeves with the applications on the Android marketplace is > that there's inadequate visibility into the change logs from version > to version. I get a notice to update app X, but I don't know if > that's fixing a bug that's been annoying me, adding/refreshing > advertising code, etc. I dislike adding to chaos. > > So, I started looking at my options. Obviously, if I hosted my source > code somewhere then users could use the hoster's built-in bug tracking > facility to report bugs. On the off chance that a mobile user took > the time to look up the project and submit a bug, I'd still be reliant > on the submitter to supply correct and relevant diagnostic > information. I have my doubts that either would occur reliably. > > I came across this thread [http://groups.google.com/group/android- > developers/browse_thread/thread/bae832439608ad2e/44d2e285da39aa57? > lnk=gst&q=exception+handler#44d2e285da39aa57] detailing a simple > strategy for collecting information under the covers and posting an > exception to a remote server. I see some issues with this strategy as > well: > > 1. It doesn't engage the user to acknowledge that a problem has > occurred (mea culpa). > 2. It doesn't elicit contextual information from the user. > 3. It doesn't help to provide the user visibility into the state of > issues for the application (bugs nor enhancements). > 4. It requires that my application request internet permission. If I > wanted to allow the user to opt-in to send some personally > identifiable information (say to support notification), then I'd need > to request profile permissions. I dislike jumbling together a lot of > disparate concerns and then asking for every permission under the > sun. This trend will lead to users totally disregarding the > permissions altogether. > > So, my thought was to implement a separate Bug Reporting application > that handles bug tracking. Other programs could elect to register > with this app. The BR app accepts crash information from a calling > application, prompts the user to provide summary, description, and > priority information, then posts the issue to the developer's bug > server (indicated during registration). The BR application could be > further enhanced to retain these issue ids and allow the user to > browse the state of them (by browsing to a well defined link or via > some well-defined exchange with the bug server). Similar > functionality could be implemented to allow viewing change logs, > release road maps, etc. for the app. Obviously, the integration b/t > the BR app and the client apps would be implemented in such a way that > there would be a transparent no-op if the user decided to uninstall or > never install the BR app (so as to not perpetuate a bad Vista-like > user experience). > > It looks like I can license JIRA for $10 and open up anonymous issue > creation. So, far I've prototyped a simple BR activity and a JIRA > plugin to accept BR submissions. Obviously, the http protocol could > be openly defined in such as way as to allow integration with any > extensible bug tracking system. > > I'd like to hear opinions on this strategy. Has it already been > done? Is it too intrusive or techy for users? Do you agree or > disagree that visibility is an issue? Is there simply a better > solution of which I'm unaware? Ideally, such a thing would be > embraced by Android itself (or the market). > > regards, > > -Jess -- 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
