The source and binaries of the prototype have been posted on Github for any interested. Comments are welcome.
http://heroicefforts.github.com/Viable/intro.html On Feb 25, 9:09 pm, laphroaig15 <laphroai...@gmail.com> wrote: > A follow up. I'm close to a working prototype as I described a few > weeks ago. The code looks like it was written by someone who's only > been developing Android apps for two months (DH and MM would reach > through the screen to strangle me) and the UI looks like it was > designed by a developer, but hopefully it will prove useful as a > starting point or at least a conversation starter. The prototype is > currently bridging to JIRA and Issue Tracker. I should have some > source on github late next week after I've read up on git, maven, and > have my project build ducks all in a row. > > http://tinyurl.com/yeol4shhttp://tinyurl.com/ybeqybd > > regards, > > Jess > > On Feb 2, 7:36 pm,laphroaig15<laphroai...@gmail.com> wrote: > > > > > It certainly wouldn't be closed. I'm not looking to implement yet > > another issue management system or sell a hosted solution. There are > > many folks who already do that. I'm thinking more of a user friendly, > > common bridge to those systems. I'd mentioned JIRA because I have a > > fondness for the Atlassian products (quality, weight, price point, > > etc.), and I like independence. That would be one concrete SPI > > implementation that I'd build out to support my own projects. Someone > > who actually comprehends Google's auth methodology wrt Android could > > implement, or help me implement, a similar plugin for Google Issue > > Tracker. > > > I appreciate the excellent input. I'll follow up when I have some > > seed code to contribute. > > > -Jess > > > On Feb 1, 9:57 pm, theSmith <chris.smith...@gmail.com> wrote: > > > > On Feb 1, 4:52 pm,laphroaig15<laphroai...@gmail.com> wrote: > > > > > The alternatives you suggest seem to be summed up as, "implement the > > > > equivalentbugreportingtool 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 ___ forBugReporting" Automated and simple > > > errorreportingwould 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 actualreporting, 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
