Hi Dianne and Mark, Thanks for taking the time to chime in on this. Mark, I've purchased your Advanced Android Development book and find it very informative.
I've tried your suggestions, but its still not working. I am testing on the emulator, so there may be an issue with that. I'm targeting v1.6 Here is what I have so far in my res folder: res/drawable - contains both normal and large images. Large images have '_lrg' added to the filenames (ie image_lrg.png) res/drawable-hdpi - contains alias pointing to the drawable folders large assets res/drawable-large-mdpi - contains alias pointing to the drawable folders large assets res/drawable-normal-hdpi - contains alias pointing to the drawable folders large assets res/drawable-mdpi - contains a duplicate set of normal images (for now) I also have: res/layout/main.xml - my layout for normal devices like my G1 res/layout-large-mdpi - my layout for the Dell Streak-like devices res/layout-normal-hdpi - my layout for Nexus, Droid, ect. So now when I run my app here are the results: Droid-like settings (normal, 480x854) = Correct layout is used, 480x854 res, 1.5 density. The graphics are the correct high res version, but are scaled up 1.5 times beyond the size of the screen. Dell Streak-like settings (large, 480x800) = Correct layout used, 480x800 res, 1.0 density. The graphics are the correct high res version, and are correctly displayed. G1 phone (actual unit, normal, 320x480) = Correct layout used, 320x480 res, 1.0 density. The graphics are incorrectly using the high res version, so they are oversize for the display by 1.5 times. It appears that the correct layout are being used for each device type. Its the drawables that are not being found correctly. So I'm out of ideas at this point. If there is a folder qualifier combination that I'm missing, or anything else please let me know. Best, Stephen Lebed On Jul 4, 5:42 am, Mark Murphy <mmur...@commonsware.com> wrote: > On Sun, Jul 4, 2010 at 8:11 AM, Tom Gibara <m...@tomgibara.com> wrote: > > That lays it out very clearly. If that is the approach we should be taking, > > I'm saying it is *an* approach. > > > then I don't think I understood Dianne's contraindication in the post I > > replied to. Also, it concerns me that, as the number of variations in screen > > densities and screen sizes increase, this approach might be unwieldy - I'm > > having difficulty visualizing how many variations developers could be > > required to accommodate so I'm not sure. > > Well, actually, those two points are probably tied. My reply made one > assumption: your proposed graphic design was the right one to > implement. Let's back up a step and talk about the design: two images, > each taking up half of the screen. > > First, let's think of a Web app, where a designer wanted to use that design. > > Browser windows can range from 800x600 to 1920x1080 just within the > desktop/notebook realm and still be considered reasonably sized. There > are over a million possible browser size combinations, courtesy of > re-sizable windows. Screen sizes can easily range from 10" netbooks to > 30" Cinema Displays. > > What is "half of the screen" in this case? > > At this point, there are three possibilities that I can see: > > 1. The Web designer elects to use JS/CSS tricks and a metric buttload > of images to achieve the desired look. The Android equivalent of this > is what my reply covered. > > 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. > > 3. The Web designer decides to get all modern on us and use SVG for > the images, which works on some browsers but not all, but provides > near-infinite scalability. In Android, we'd need an SVG library from > which we could generate bitmaps at appropriate sizes, caching as > appropriate to avoid the SVG calculations every time. libsvg-android > is one candidate, though I have not tried it and it uses the NDK and > so may have issues on some chipsets: > > https://launchpad.net/libsvg-android > > Or, I've seen some hints that WebView can render SVG, perhaps in newer > Android releases, though I have not tried it. > > Personally, for now, I'd aim for #2. Have different images for > different densities, so they can have a common approximate physical > size. Have layouts for different physical sizes, where you perhaps > display more information on a larger-size screen, less information on > a smaller-size screen. > > My sincere hope is that all of this gets revisited in 6-9 months, as > #2 pretty much assumes we're talking phones and tablets. Once you get > to 10-foot UIs with Google TV, #2 starts getting problematic, unless > televisions are given pseudo densities and physical sizes based upon > apparent values from the greater distance. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > Android Consulting:http://commonsware.com/consulting -- 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
