I've posted about using the droiddrop remote logging tool to create a simple user's forum to address some of these same issues. See http://talkingandroid.com/2009/11/04/droiddrop-remote-logging-for-android/
There might be a way to leverage this for bug reporting as well. Let me know how I can help. Carmen -- Carmen http://www.twitter.com/CarmenDelessio http://www.talkingandroid.com http://www.facebook.com/BFFPhoto http://www.twitter.com/DroidDrop On Mon, Feb 1, 2010 at 9:57 PM, theSmith <[email protected]> wrote: > > > On Feb 1, 4:52 pm, laphroaig15 <[email protected]> wrote: > > The alternatives you suggest seem to be summed up as, "implement the > > equivalent bug reporting tool in your own app." That, of course, is > > always an option. Everyone could implement their own variation. > > However, it seems to go against the general Android theme of a > > separation of concerns and the loose coupling of apps. It also > > assumes that developers would take the effort to implement it. > > > > No issue management is absolutely necessary, as evidenced by many of > > the existing apps in the marketplace. What I am after is whether an > > open implementation holds value. Would it help developers and improve > > the robustness of applications? Would it add value to the end users? > > I have a strong SCM background, so my judgment is a little biased. > > Absolutely I believe this would add value to any application that > would use it. It could even be seen as a marketing point in the app's > description "Uses ___ for Bug Reporting" Automated and simple error > reporting would provide a great asset to the Android community, > especially if it were open and easily implementable. That would be my > primary concern with such a system. If you were to start working on > this, I would suggest opening it up to the community, not right away > though, wait till you have something of substantial value with a > robust feature set. As for the actual reporting, how would you > collect requests from several applications and multiple developers? > Who has access to what? Do they need their own accounts? (I'm not > familiar with JIRA) > > -theSmith > > > Broadcasting seems to be working. Maybe I'll try generating a deep > > stack overflow to get a gauge on the upper bounds on the stacktrace. > > It might be a big chunk of info, but hopefully the system won't be > > generating a high volume of them. I'm reading up on content providers > > at the moment. > > > > On Feb 1, 2:45 pm, theSmith <[email protected]> wrote: > > > > > 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 > forbugreportingin 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 <[email protected]> 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 forbugreporting. 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 abugthat'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-inbugtracking > > > > facility to report bugs. On the off chance that a mobile user took > > > > the time to look up the project and submit abug, 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 separateBugReportingapplication > > > > that handlesbugtracking. 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'sbug > > > > 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 thebugserver). 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 > > > > extensiblebugtracking 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 [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
