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/commonsguy http://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
