Mark, a common crash reporter and publicly available data sound really great, and to be honest, that sounds like a typical platform feature. Also better education would be awesome, but that might come from the community. I have a little problem with collecting log data. At least a common twitter client was (is?) logging passwords in clear text in the log. This kind of carefreeness might lead to insecurities.
On Sun, Apr 12, 2009 at 2:41 PM, Mark Murphy <[email protected]>wrote: > > Al Sutton wrote: > > My concern is that the the Camera is a "built-in" app, Weather channel > > app is *the* number #1 app in terms of popularity in Market, and snake > > is the number #5 game by popularity, and all three throw up errors like > > this which will make the *average user* feel that Android is flaky by > > association. > > That assumes the average user is seeing these errors. I feel like a > broken record, but one or two data points, out of a set of a > million-plus devices, does not make a pattern. They aren't a good sign, > but they aren't evidence of Armageddon, either. > > Ideally, apps should never fail. By the same token, ideally, I should > have hair. > > > Do we name and shame > > apps to try and get them improved? > > One entertaining-yet-probably-controversial way to do this would be to > bake into Android a top-level exception handler that, in addition to > providing better error messages, attempts to push the identity of the > app and the exception stack trace to a Web service. Said Web service, > perhaps running on App Engine, would make the information available to > the application author...and anyone else. > > Average users would not find the information meaningful. Those > interested in a name-and-shame approach, though, could create their own > site to roll up the data to more average-user-friendly details. > > This won't work for all situations (e.g., crash while in airplane mode), > but it might work for enough. > > > Do we look at improving the OS to > > deal with situations like this in a better manner that doesn't require > > users to be shown error messages they may not understand? > > The "deal with situations like this in a better manner" side is beyond > my pay grade. > > Better error messages might be useful. Even if the automatic > post-the-exception stuff I list above is deemed too intrusive, it would > be helpful if Android had a send-the-crash-info button to do it more > manually. Developers can put that in their own apps, but if you want it > across the board, it's better to have it in the OS, IMHO. > > > or do we > > carry on with the current system where we expect users to educate > > themselves to deal with problems like this? > > > > To me the last one isn't part of the path to success. > > Indubitably. > > Here are some other not-mutually-exclusive options: > > -- Better educate developers on proper patterns for this sort of thing > > -- Better frameworks to help lead developers in the right direction for > this sort of thing > > -- If people have figure out a way to get at the error log from > application code on the device (and I forget if someone has a trick for > that), it should be possible to create an AlarmManager-triggered app > that scans for errors and publishes them to a Web service without having > to modify the OS or instrument every app. We'd need to encourage users > to install it, and power users might, giving us access to some level of > crash details. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > Android App Developer Books: http://commonsware.com/books.html > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
