Okay let me put it this way... what you are trying to do is not how things are intended to work, because it results in applications that are very tied to specific screen resolutions and are likely to not behave well when encountering new kinds of screens that they didn't anticipate.
So I strongly recommend not going down this route, and instead using another approach. However, if this is REALLY what you want to do... then you need to take control, and decide exactly what you want to have happen yourself. That is, stick all of your possible graphics in drawable-nodpi, and at run time look at the space you have on the screen and other information to determine exactly which graphic you want to use for that environment. Definitely don't do things like try to mix physical screen resources, with density resources, with screen size resources. It IS well defined which resource you will end up with given a particular screen (via the resource matching hierarchy described in the docs), but it is likely it won't do exactly what you want. If one were to ask "is a large screen resource better than a high density resource?" well... it depends. For our purposes we will always match screen size before density since layouts tends to be more fragile than densities (we can after all always scale graphics), but you are going against how the platform thinks about screen sizes so you can't really count on it doing what you want here. That is, "screen size" and "density" are two completely orthogonal things, and have no bearing on each other. You are trying to put them together, and fighting with the platform by doing so. And honestly -- just DO NOT use absolute screen size configurations. Those are deprecated for a reason. They will only cause pain. They just do not work for being able to adjust for the kinds of different screens we have. But let me say one more time: with the approach you are taking, there is a good chance you are going to end up having to tweak your app each time a device with a new kind of screen appears. It is going to cause you some trouble. If that is absolutely what you want, then go ahead and take control and do it... just don't be surprised at the consequences. On Sun, Jul 4, 2010 at 4:16 PM, Stephen Lebed <srle...@gmail.com> wrote: > As another test, I removed the drawable-normal-hdpi and drawable-large- > mdpi folders and left drawable-480x320 and drawable-800x480. > > The G1 is displaying correctly, the Droid is using the layout for the > G1, using the normal res graphics and scaled them to fill the screen, > the Dell Streak is displaying correctly. > > Stephen > > > On Jul 4, 3:58 pm, Stephen Lebed <srle...@gmail.com> wrote: > > I have tried creating a drawable folder called res/drawable-480x320 > > and res/drawable-800x480 thinking that this would do the trick, but it > > doesn't work either. > > > > Stephen > > > > On Jul 4, 3:44 pm, Tom Gibara <m...@tomgibara.com> wrote: > > > > > > > > > > 2. The Web designer decides that the original design was nonsensical > > > >> and comes up with a design that works better on a range of browser > > > >> window dimensions. The Android equivalent of this is more or less > what > > > >> Ms. Hackborn was hinting at (I think) in her replies on the two > > > >> threads -- use a different design. > > > > > > Yes, trying to make fixed size bitmaps into "a UI that splits the > screen in > > > > half" is simply the wrong approach. > > > > > "Half-the-screen" is a conveniently simplified example just to discuss > the > > > technicalities. Al's screenshot of the facebook app provides a concrete > > > real-world example. There are six possible actions, and the UI design > maps > > > this on to a grid of 3x2 buttons that fill the screen. Though this > design > > > might look quite bold over a large screen, I think that in the context > of > > > this discussion, its the kind of UI that a developer might reasonably > be > > > called on to implement; calling the design nonsensical is to bypass the > > > issue. > > > > > I apologize for a lack of clarity in my previous post, but I'm "not > trying > > > to make trying to make fixed size bitmaps into 'a UI that splits the > screen > > > in half'". I'm trying to ensure that the image resource with the most > > > appropriate density is selected by for display by a variably sized > view. > > > > > The 2d Canvas APIs are functionally pretty equivalent to SVG, and can > be > > > > > > used to generate the same kinds of images. > > > > > I do this a lot - it's liberating to have the option of resizing > resources > > > precisely to the required dimensions, but it comes with a lot of effort > > > relatively speaking (handling caching and view resizing are two > significant > > > areas of additional work). Though I broadly agree with Mark's > sentiment; > > > designers want to export graphical assets into UIs that, for their > > > complexity, the developers don't want to touch - let alone render in > code. > > > > > Tom. > > > > > -- > > > Tom Gibara > > > email: m...@tomgibara.com > > > web:http://www.tomgibara.com > > > blog:http://blog.tomgibara.com > > > twitter: tomgibara > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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, and so won't reply to such e-mails. 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
