Hmmm. Honestly, I found the screamingpengiun page far more helpful, even if it's unofficial and therefore possibly risky. The official list of resources is so terse and lacks any imagery that I find it mostly useless. It gives no more information than the editor's javadoc & context completion popups do. I find myself cross referencing a useful-but-possibly-problematic reference and an official-safe-yet- near-useless reference. And neither page gives guidance as to how or when each icon is intended to be used to provide a consistent user experience.
The stock graphical resources are helpful not just in providing a consistent UI, but also for developers who need an icon quickly and don't have the artistic skill or time to doodle something. Every developer to creating their own icons is a fast track to ugly. But it's also very convenient to be able to refer to an existing & standardized set of icons instead of having to roll your own every time. Suddenly need an icon for a dialpad? It's there for you already....how handy! It avoids ugly 'programmer art', makes the UI consistent for the user, and is more convenient during development. It would be would even more useful if there was an extended set of standardized icons that covered more circumstances but still matched the look and feel of the existing set. --Larz On Mar 20, 9:59 am, Dianne Hackborn <hack...@android.com> wrote: > As with other resources, the official list of public resources is here: > > http://developer.android.com/reference/android/R.drawable.html > > Note that a lot of these are actually things like state list drawable XML > files, which map to some set of multiple underlying images that you can not > directly access. > > On Fri, Mar 20, 2009 at 7:42 AM, Mark Murphy <mmur...@commonsware.com>wrote: > > > > > > > >> That list is... very questionable. It contains lots and lots of > > >> resources > > >> that are not in the public SDK, and which you should not be using. > > > > Then how about pointing us to a list that isn't questionable? Or at > > least > > > show us where to find said information and we'll draw up a list. > > > Agreed. For example, one would hope we are encouraging people to use the > > stock option menu icons wherever possible, for consistency between > > applications. However, that implies that developers know how to reference > > the stock option menu icons, which implies the existence of some sort of > > documentation. > > > We do not necessarily need the core Android team to develop the > > documentation, but we do need the algorithm for deducing if a resource is > > deemed "in the public SDK" or not. > > > -- > > Mark Murphy (a Commons Guy) > >http://commonsware.com > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
