[android-developers] Re: Getting a complete list of android native drawables
I realize this thread has been dead for a couple of months, but I just composed a list of drawables from android.R.drawable. I left out all the NinePatch drawables; these are just the ones that might be suitable for use as icons. Anyway, here's the link: http://darshancomputing.com/android/1.5-drawables.html Darshan On Mar 19, 5:43 pm, Agus wrote: > Does anyone has a complete list of native drawables listed on a > webapage ? I don't want to do trial and error.. > Any help is appreciated. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
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 alreadyhow 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 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 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
excellent advice, thanks: > So back to the whole issue of menu icons... if there are standard menu > icons you want to use, I recommend just copying them out of the platform > source and into your app, so you can make sure that the other icons you > design remain consistent with them. the old UI consistency problem is one of choice vs. lack of choice, or more-choice vs. less-choice. in general the less-choice approach works well for a little while then often breaks down or loses to a competing more-choice approach. I for one prefer the more-choice approach, coupled with some guidance for the current recommended choices and some care for some consistency. Over the long term, e.g., decades, the best or preferred UI techniques are determined by the users. The problem of choices is mostly only for the new platforms, such as Android with its very open, small&large devices, lots of internal components, touch-based, voice-activated (eventually) platform. It will take a few years but I expect that new dominant UI techniques will emerge from Android and similar devices. It's a lot of fun to be in the phase where anyone can try to invent a new UI technique. So for now, lets have freedom of choices and go for it, invent. serge On Mar 21, 11:51 pm, Dianne Hackborn wrote: > Hi Mark, > > I think there are two things being mixed here: you mention a number of times > the basic user interaction model of not having a "close" menu item, but seem > to be equating that with not having a standard look for menu icons across > all applications. > > To me, these are really different things. > > In Android, as you note I have said before, we discourage applications from > having a close command. This is part of the basic interaction of the > device, just like we also encourage an edit-in-place model, and other > aspects about how applications behave. This should be as consistent as > possible across applications, and we do need to have these more clearly > described in UI guidelines. > > But when it comes to the look of menu items... well, at the end of the day, > trying to make these consistent across all applications on even most Android > devices just isn't going to happen. The first thing a lot of device > manufacturers will want to do is customize the look of the stock UI to give > it their own look, branding, etc. I think we can expect to see Android > devices in the future with quite different looks than the standard open > source platform, and I really don't see anything wrong with that. > > It does mean, however, that we probably made a mistake in putting any > standard menu icon resources in the platform. The fact is, it is just going > to be impossible to use these with a good result except in the unlikely > situation where you only have menu items for which there is a platform > icon. Otherwise, on some number of devices, your application is going to > end up with radically different appearing icons in its menus. > > For example, I am sure some manufacturers are going to have menu icons that > use colors, because the stock Android UI is admittedly very low-key in its > use of color and other devices are going to want to be much more striking. > So there you'll end up with your own icons being all laid-back and > grayscale, sprinkled with a few stock colorful icons. Yuck. > > I don't see how we can avoid living with the user seeing different UI looks > in different applications. Heck, a good chunk of serious app developers > -want- to give their app its own distinctive look, and I really can't fault > them for it. But as long as the applications are internally visually > consistent, and the *user interaction* is consitent across all applications, > this seems like a perfectly acceptable situation. > > Btw, for this reason I also recommend, if someone finds they want to do > something like customize the look of a button or something, that they > actually go and just create their own look for their UI. Otherwise you'll > end up with a similar problem: if you make this special button have a look > that matches the stock Android UI buttons and other widgets, when you run on > a device that has its own look for these your internal UI will end up with > an inconsistent look. (And fwiw, Cupcake has slight changes to a lot of the > visual elements, so you'll actually see this problem crop up just by running > on the newer platform.) > > So back to the whole issue of menu icons... if there are standard menu > icons you want to use, I recommend just copying them out of the platform > source and into your app, so you can make sure that the other icons you > design remain consistent with them. > > On Sat, Mar 21, 2009 at 8:09 PM, Mark Murphy wrote: > > > > > > > Marco Nelissen wrote: > > > On the other hand, you might be better off using your own copy of the > > > system icons. For example, if you were to use system icons plus some > > > additional ones in the same style that you made yourself, your > > > appli
[android-developers] Re: Getting a complete list of android native drawables
+1 for written guide lines. Also I think it's a bad idea that every vendor can opt for its own look and feel and I hope they don't. However I am aware, that this ship has sailed. It still feels strange though to have an application platform that enables and encourages the deployement of 3rd party apps, that doesn't help to provide a unified user experience. Consistency of the UI is something we are giving up that way and I don't just mean consistency in the color scheme. When not using a common set of icons, concepts that are complicated to convey in a simple icon have to be explained all over again for each app the users uses. For example I have a menu option "(Un-)Hide Read Items". I don't really know how to express that in a small little icon. It wouldn't be too bad though if everybody would use the same icon for filtering, even if the icon is not very descriptive. As it is used over all applications it would still be known to the user and the mental leap from filtering to "(Un-)Hide Read Items" wouldn't be too hard for most users then. Btw. I use the Loudspeaker symbol and the Loudspeaker symbol muted for that currently. On Sun, Mar 22, 2009 at 4:51 AM, Dianne Hackborn wrote: > Hi Mark, > > I think there are two things being mixed here: you mention a number of > times the basic user interaction model of not having a "close" menu item, > but seem to be equating that with not having a standard look for menu icons > across all applications. > > To me, these are really different things. > > In Android, as you note I have said before, we discourage applications from > having a close command. This is part of the basic interaction of the > device, just like we also encourage an edit-in-place model, and other > aspects about how applications behave. This should be as consistent as > possible across applications, and we do need to have these more clearly > described in UI guidelines. > > But when it comes to the look of menu items... well, at the end of the > day, trying to make these consistent across all applications on even most > Android devices just isn't going to happen. The first thing a lot of device > manufacturers will want to do is customize the look of the stock UI to give > it their own look, branding, etc. I think we can expect to see Android > devices in the future with quite different looks than the standard open > source platform, and I really don't see anything wrong with that. > > It does mean, however, that we probably made a mistake in putting any > standard menu icon resources in the platform. The fact is, it is just going > to be impossible to use these with a good result except in the unlikely > situation where you only have menu items for which there is a platform > icon. Otherwise, on some number of devices, your application is going to > end up with radically different appearing icons in its menus. > > For example, I am sure some manufacturers are going to have menu icons that > use colors, because the stock Android UI is admittedly very low-key in its > use of color and other devices are going to want to be much more striking. > So there you'll end up with your own icons being all laid-back and > grayscale, sprinkled with a few stock colorful icons. Yuck. > > I don't see how we can avoid living with the user seeing different UI looks > in different applications. Heck, a good chunk of serious app developers > -want- to give their app its own distinctive look, and I really can't fault > them for it. But as long as the applications are internally visually > consistent, and the *user interaction* is consitent across all > applications, this seems like a perfectly acceptable situation. > > Btw, for this reason I also recommend, if someone finds they want to do > something like customize the look of a button or something, that they > actually go and just create their own look for their UI. Otherwise you'll > end up with a similar problem: if you make this special button have a look > that matches the stock Android UI buttons and other widgets, when you run on > a device that has its own look for these your internal UI will end up with > an inconsistent look. (And fwiw, Cupcake has slight changes to a lot of the > visual elements, so you'll actually see this problem crop up just by running > on the newer platform.) > > So back to the whole issue of menu icons... if there are standard menu > icons you want to use, I recommend just copying them out of the platform > source and into your app, so you can make sure that the other icons you > design remain consistent with them. > > > On Sat, Mar 21, 2009 at 8:09 PM, Mark Murphy wrote: > >> >> Marco Nelissen wrote: >> > On the other hand, you might be better off using your own copy of the >> > system icons. For example, if you were to use system icons plus some >> > additional ones in the same style that you made yourself, your >> > application's menus will look weird if the system icons are >> > redesigned. >> >> Android has bee
[android-developers] Re: Getting a complete list of android native drawables
Hi Mark, I think there are two things being mixed here: you mention a number of times the basic user interaction model of not having a "close" menu item, but seem to be equating that with not having a standard look for menu icons across all applications. To me, these are really different things. In Android, as you note I have said before, we discourage applications from having a close command. This is part of the basic interaction of the device, just like we also encourage an edit-in-place model, and other aspects about how applications behave. This should be as consistent as possible across applications, and we do need to have these more clearly described in UI guidelines. But when it comes to the look of menu items... well, at the end of the day, trying to make these consistent across all applications on even most Android devices just isn't going to happen. The first thing a lot of device manufacturers will want to do is customize the look of the stock UI to give it their own look, branding, etc. I think we can expect to see Android devices in the future with quite different looks than the standard open source platform, and I really don't see anything wrong with that. It does mean, however, that we probably made a mistake in putting any standard menu icon resources in the platform. The fact is, it is just going to be impossible to use these with a good result except in the unlikely situation where you only have menu items for which there is a platform icon. Otherwise, on some number of devices, your application is going to end up with radically different appearing icons in its menus. For example, I am sure some manufacturers are going to have menu icons that use colors, because the stock Android UI is admittedly very low-key in its use of color and other devices are going to want to be much more striking. So there you'll end up with your own icons being all laid-back and grayscale, sprinkled with a few stock colorful icons. Yuck. I don't see how we can avoid living with the user seeing different UI looks in different applications. Heck, a good chunk of serious app developers -want- to give their app its own distinctive look, and I really can't fault them for it. But as long as the applications are internally visually consistent, and the *user interaction* is consitent across all applications, this seems like a perfectly acceptable situation. Btw, for this reason I also recommend, if someone finds they want to do something like customize the look of a button or something, that they actually go and just create their own look for their UI. Otherwise you'll end up with a similar problem: if you make this special button have a look that matches the stock Android UI buttons and other widgets, when you run on a device that has its own look for these your internal UI will end up with an inconsistent look. (And fwiw, Cupcake has slight changes to a lot of the visual elements, so you'll actually see this problem crop up just by running on the newer platform.) So back to the whole issue of menu icons... if there are standard menu icons you want to use, I recommend just copying them out of the platform source and into your app, so you can make sure that the other icons you design remain consistent with them. On Sat, Mar 21, 2009 at 8:09 PM, Mark Murphy wrote: > > Marco Nelissen wrote: > > On the other hand, you might be better off using your own copy of the > > system icons. For example, if you were to use system icons plus some > > additional ones in the same style that you made yourself, your > > application's menus will look weird if the system icons are > > redesigned. > > Android has been beaten up in the past for apps not having a consistent > look and feel, particularly when compared with iPhone. It is likely to > get beaten up for it in the future. > > While having apps with disparate UIs is part-and-parcel of having an > open platform, it might be nice if there was at least some measure of > guidance for how application developers *can* strive for a consistent > look and feel if they so choose. In other words, let developers have the > freedom to follow a lead as much as they have the freedom to chart their > own course. > > Either a sporadically-consistent look and feel is a goal of the core > Android team, or it isn't. Speaking as a developer, it would be nice to > know which philosophy the core Android team is adopting. > > If the core Android team would like a consistent look and feel from apps > (e.g., Ms. Hackborn's repeated insistence that "close" menu items are > evil), then you're going to have to throw us a bone now and again with > advice on how to maintain a consistent look and feel with the stock > Android apps. I would think rules for how to have consistent menu icons > might be part of that. > > If, on the other hand, the core Android team is not terribly interested > in UI look fidelity, or feels it's not an issue because of re-branding > that device manufacturers mi
[android-developers] Re: Getting a complete list of android native drawables
Marco Nelissen wrote: > On the other hand, you might be better off using your own copy of the > system icons. For example, if you were to use system icons plus some > additional ones in the same style that you made yourself, your > application's menus will look weird if the system icons are > redesigned. Android has been beaten up in the past for apps not having a consistent look and feel, particularly when compared with iPhone. It is likely to get beaten up for it in the future. While having apps with disparate UIs is part-and-parcel of having an open platform, it might be nice if there was at least some measure of guidance for how application developers *can* strive for a consistent look and feel if they so choose. In other words, let developers have the freedom to follow a lead as much as they have the freedom to chart their own course. Either a sporadically-consistent look and feel is a goal of the core Android team, or it isn't. Speaking as a developer, it would be nice to know which philosophy the core Android team is adopting. If the core Android team would like a consistent look and feel from apps (e.g., Ms. Hackborn's repeated insistence that "close" menu items are evil), then you're going to have to throw us a bone now and again with advice on how to maintain a consistent look and feel with the stock Android apps. I would think rules for how to have consistent menu icons might be part of that. If, on the other hand, the core Android team is not terribly interested in UI look fidelity, or feels it's not an issue because of re-branding that device manufacturers might do, that's perfectly fine. However, if the UI critics continue harping on the issue, please don't blame the developer community for not following non-existent style guidance. The worst answer is no answer at all, where we are left with conflicting guidance: the core Android team sometimes berating us for not slavishly following the stock apps design (e.g., not having "close" menu items) and sometimes saying that our efforts to follow the stock apps design may be fruitless (e.g., you might change the icon style out from under us). - Also, with specific respect to the icons, bear in mind that we're working under a 70MB hard cap, and so every KB we can slice off our apps makes it that much more likely somebody will keep our apps around, rather than discarding them to free up space. Hence, the interest in avoiding redundant icons. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
On Fri, Mar 20, 2009 at 7:42 AM, Mark Murphy 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. On the other hand, you might be better off using your own copy of the system icons. For example, if you were to use system icons plus some additional ones in the same style that you made yourself, your application's menus will look weird if the system icons are redesigned. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
On Mar 20, 7:38 am, gsmd wrote: > I'd suggest to check out the sources from git & search for .pngs > there. At least, that's what I did. That's a very bad idea. If they're not part of the documented API, they could very easily go away again on the next os release. Using undocumented features of any system is always a risky proposition. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
Might be better to send him an email. The comment might be missed? On Sat, Mar 21, 2009 at 3:57 AM, Mariano Kamp wrote: > Sorry if I wasn't clear, but I am not the author. Having said that I'll > post a comment on his blog with a reference to this thread. > > > On Fri, Mar 20, 2009 at 9:52 PM, Dianne Hackborn wrote: > >> Thanks for the pointer, that's nice! Might be useful to contribute to >> ApiDemos or DevTools. >> >> >> On Fri, Mar 20, 2009 at 1:01 PM, Mariano Kamp wrote: >> >>> http://mgmblog.com/2008/12/12/listing-androids-drawable-resources/ >>> In the code referenced above the author's code iterates over >>> android.R.drawable and puts the result in a list. It is a bit more >>> illustrative as you can actually see the icons. >>> >>> Also when looking for what's what and how should you use it, I consider >>> the API demos and the packaged apps (http://android.git.kernel.org/ -> >>> packages) quite valuable. >>> >>> 2009/3/20 Dianne Hackborn >>> 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 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. >>> >>> >>> >> >> >> -- >> 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
Sorry if I wasn't clear, but I am not the author. Having said that I'll post a comment on his blog with a reference to this thread. On Fri, Mar 20, 2009 at 9:52 PM, Dianne Hackborn wrote: > Thanks for the pointer, that's nice! Might be useful to contribute to > ApiDemos or DevTools. > > > On Fri, Mar 20, 2009 at 1:01 PM, Mariano Kamp wrote: > >> http://mgmblog.com/2008/12/12/listing-androids-drawable-resources/ >> In the code referenced above the author's code iterates over >> android.R.drawable and puts the result in a list. It is a bit more >> illustrative as you can actually see the icons. >> >> Also when looking for what's what and how should you use it, I consider >> the API demos and the packaged apps (http://android.git.kernel.org/ -> >> packages) quite valuable. >> >> 2009/3/20 Dianne Hackborn >> >>> 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 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. >>> >>> >>> >>> >> >> >> > > > -- > 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
Thanks for the pointer, that's nice! Might be useful to contribute to ApiDemos or DevTools. On Fri, Mar 20, 2009 at 1:01 PM, Mariano Kamp wrote: > http://mgmblog.com/2008/12/12/listing-androids-drawable-resources/ > In the code referenced above the author's code iterates over > android.R.drawable and puts the result in a list. It is a bit more > illustrative as you can actually see the icons. > > Also when looking for what's what and how should you use it, I consider the > API demos and the packaged apps (http://android.git.kernel.org/ -> > packages) quite valuable. > > 2009/3/20 Dianne Hackborn > >> 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 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. >> >> >> >> > > > > -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
http://mgmblog.com/2008/12/12/listing-androids-drawable-resources/ In the code referenced above the author's code iterates over android.R.drawable and puts the result in a list. It is a bit more illustrative as you can actually see the icons. Also when looking for what's what and how should you use it, I consider the API demos and the packaged apps (http://android.git.kernel.org/ -> packages) quite valuable. 2009/3/20 Dianne Hackborn > 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 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
> 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. Great, thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
On Fri, Mar 20, 2009 at 9:02 AM, Pd wrote: > Why not have a look at the res/drawable folder in the android.jar. That is what the originally referenced page shows (though a somewhat older version), but many of those are not in the public SDK. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
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 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
To think of the day of work I could've saved if I known these were there. So much for my custom icons :) On Fri, Mar 20, 2009 at 11:02 PM, Pd wrote: > > Why not have a look at the res/drawable folder in the android.jar. > > gsmd wrote: > > I'd suggest to check out the sources from git & search for .pngs > > there. At least, that's what I did. > > > > On Mar 20, 2:43 am, Agus wrote: > > > >> Does anyone has a complete list of native drawables listed on a > >> webapage ? I don't want to do trial and error.. > >> Any help is appreciated. > >> > > > > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
Why not have a look at the res/drawable folder in the android.jar. gsmd wrote: > I'd suggest to check out the sources from git & search for .pngs > there. At least, that's what I did. > > On Mar 20, 2:43 am, Agus wrote: > >> Does anyone has a complete list of native drawables listed on a >> webapage ? I don't want to do trial and error.. >> Any help is appreciated. >> > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
Have a look at "android-sdk-windows-1.1_r1\tools\lib\res\default \drawable". I suppose these are the public drawables. On Mar 20, 3:42 pm, "Mark Murphy" 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! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
>> 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! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
I'd suggest to check out the sources from git & search for .pngs there. At least, that's what I did. On Mar 20, 2:43 am, Agus wrote: > Does anyone has a complete list of native drawables listed on a > webapage ? I don't want to do trial and error.. > Any help is appreciated. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
On Thu, Mar 19, 2009 at 10:16 PM, Dianne Hackborn 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. > > > On Thu, Mar 19, 2009 at 5:47 PM, Mark Murphy wrote: > >> >> > Does anyone has a complete list of native drawables listed on a >> > webapage ? I don't want to do trial and error.. >> > Any help is appreciated. >> >> There's this list, which has been accurate for all the images I've used: >> >> >> http://www.screaming-penguin.com/info/android_drawables/android_drawables.html >> >> -- >> 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. > > > > > -- Faber Fedor Linux New Jersey http://linuxnj.com faberfedor.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
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. On Thu, Mar 19, 2009 at 5:47 PM, Mark Murphy wrote: > > > Does anyone has a complete list of native drawables listed on a > > webapage ? I don't want to do trial and error.. > > Any help is appreciated. > > There's this list, which has been accurate for all the images I've used: > > > http://www.screaming-penguin.com/info/android_drawables/android_drawables.html > > -- > 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
> I've checked that one out, that's for Android 1.0 which is old. Not that old. Are there any you've found that do not work? -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
I've checked that one out, that's for Android 1.0 which is old. On Thu, Mar 19, 2009 at 5:47 PM, Mark Murphy wrote: > >> Does anyone has a complete list of native drawables listed on a >> webapage ? I don't want to do trial and error.. >> Any help is appreciated. > > There's this list, which has been accurate for all the images I've used: > > http://www.screaming-penguin.com/info/android_drawables/android_drawables.html > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Getting a complete list of android native drawables
> Does anyone has a complete list of native drawables listed on a > webapage ? I don't want to do trial and error.. > Any help is appreciated. There's this list, which has been accurate for all the images I've used: http://www.screaming-penguin.com/info/android_drawables/android_drawables.html -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
