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
