On Sun, Jul 4, 2010 at 5:42 AM, Mark Murphy <mmur...@commonsware.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. So you go through contortions to make a bitmap that works on the screens you know of so far... and conveniently one of the large size screens happens to have the same number of pixels as current high density phones (at least in one dimension; in the long dimension there is more variation), and then along comes something like this: http://www.wired.com/gadgetlab/2010/06/samsung-enters-tablet-race-with-the-galaxy-tape/ And there are going to be all other kinds of screen configurations that appear. (Trust me -- I hear all kinds of things that manufacturers want to do, and we try to manage the things Market ships with to keep things relatively simple for developers, but the platform has the infrastructure to support many different screen sizes, and you will be encountering more of them down the road.) 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 The 2d Canvas APIs are functionally pretty equivalent to SVG, and can be used to generate the same kinds of images. Also there is the approach that the platform itself uses extensively: 9-patch PNG images, allowing you to create images that can expand to fill the available space. There are some limitations on what you can do with these (various types of gradients can't be done for example), but this has the benefit of being very easy to use for a lot of the common cases and efficient to render. > 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. > No it doesn't. Things are defined as they are to be flexible for this -- that is why "density" is not tied to a specific screen dpi, but rather is a more general concept of "here is the scaling factor to use to have a UI that is the appropriate size for the user." So on a TV display one could certainly report a density class that is significantly different than the "real DPI" if you were to look at the raw display... density is intended to represent the user's perceived size. Not that I know this is how that is going to end up... we aren't doing third party apps on GoogleTV yet, and there are a lot of things to decide about how they should all play out with third party apps. -- 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
