On Feb 1, 4:52 pm, laphroaig15 <laphroai...@gmail.com> 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 <chris.smith...@gmail.com> 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 <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 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 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
