Dianne, I really don't feel that Android's solution here is as complete and universal and helpful as you appear to describe.
(I carefully say "appear to describe", because I think a good part of the issue is that it is HARD to describe). The assumption you are making appears to be that UI should be based on size rather than pixels. That's not really right. But neither is the assumption that UI should be based on pixels, rather than size! The reality is that UI must simultaneously satisfy several constraints. Sometimes information must be laid out cleanly in whatever space is available. In this case, your graphics will look best if you draw images with the same number of pixels. Likewise for background images. Other times, you must satisfy the constraint that things can't be smaller than one pixel -- likewise requiring you to control for pixels rather than physical size. And other times, as you point out, you need to control for physical size -- readable fonts, reasonable distances between elements, etc. The problem is hard. Mark points out the case of giant TV screens. Maybe you should be considering subtended angle of the screen, rather than physical size -- how many radians of the visual field does the device occupy in normal usage? And resolution of the pointing device. Fingers don't vary in size with devices -- but you're not always going to be using a finger. Android's approach to this problem is combinatoric -- in number of directories, and size of application. The alias mechanism is a reasonable way to reduce the combinatorics. I think a better (though still difficult) approach would have been to require users to express the choice of graphics, etc. as constraints. This graphic should not be smaller than 20mm. Choose the best-pixel- sized image out of this set to satisfy the constraint. This one should be sized to match 10dp text -- but in no case should it be scaled below 20 pixels, as critical detail would be lost. That one over there needs to take 10% of the screen width. This is complicated to specify, to implement, and to use. But the thing is, it matches the problem. It forces the user to actually think about the problem in the right way. (I'm not explaining it in the way it should be explained -- I'm selecting for the extremes.) Walk the user through the design process as part of discussing layout. Not just "here's what RelativeLayout can do", but "here's how you design a layout for a range of screens, and here's how you specify graphics to fit appropriately into that layout depending on purpose, and here's how you force a choice of another layout for ranges of screens where that layout doesn't work well." I think dumping screens into big categories was a big mistake -- an attempt to over-simplify a much harder problem than it assumes. What is a large size for one app will not be large for another, and likewise dpi. The thresholds that are appropriate differ for an application that is trying to present as clear an image as possible in the available space, vs one that is trying to present text + icons in a list that is both readable and clickable, vs one that is trying hard to present a complete set of information on one screen, but still needs to respect readability limits -- limits that will be hit at different points, depending on the font sizes the app started with! The result is that developers are left with categories that really don't make all that much sense, and they have to figure how to pigeonhole their graphics and their apps. Developers are confused, because the model is confused AND because the problem is hard. We can't make the problem not be hard, but adding the confused model isn't a requirement. Finally, there's another dimension to all of this that nobody has mentioned -- internationalization. You're going to find a lot of layouts will fail in some way when you switch languages. What fit with the text labels in one language will not fit in another. Careful design of layouts helps, but does not eliminate the problem. Sometimes you'll need entirely separate layouts for a language -- and then you may need a new set of graphics to match the new layout! Yet another layer of combinatorics -- but one that is difficult to test for. It forces part of the design process downstream into the localization process, and also means that the entire combinatoric panopoly of test cases for screen sizes must be repeated for each localization! This is especially a problem for application which rely on facilities not present in the emulator, or for screen sizes that the emulator fails to support (unless that's been fixed in the latest release). On Jul 4, 1:32 am, Dianne Hackborn <[email protected]> wrote: > I am going to very strongly urge you *not* to do this. And definitely don't > do what was recommended by someone on the other thread you started, using > the deprecated explicit size qualifier. > > What you are doing is going against the design of Android that is there to > help applications deal with the variety of screens we have. So not only are > you fighting the platform, but you are setting yourself up to have a > continual series of problems as you encounter different kinds of devices. > > Let's take this statement: "The Dell Streak being a high res device should > have used the 480x720 imagery." > > Well... no, that isn't the way it is. The Dell Streak is a medium density > large screen. The Droid and other such phones are high density normal > screens. There are VERY different things, and you shouldn't be treating > them as the same. That is why the platform support identifies them as being > different. For example, the standard text size on the Streak is going to be > smaller than on Droid... because the Droid has a higher density screen, so > a larger text size is needed to have the same effective physical size. If > you don't take this into account, you are either going to end up with a > strangely huge UI on the Streak, or an unusably small UI on the Droid. > > Further, you really should not be creating a fixed size UI. Just start with > the number of screens you will encounter today: QVGA low density, HVGA > medium density, WVGA (in two different sizes) high density and medium > density, and you can be sure that more will be appearing in the future. If > you design your UI based on the platform facilities (densities, screen > sizes, layout) then your app will nicely scale to all these screens with > little work on your part. If you try to treat the screen as a rigid size, > you are going to set yourself up for continual pain. > > > > > > On Sat, Jul 3, 2010 at 9:27 PM, Stephen Lebed <[email protected]> wrote: > > Hi Dianne, > > > I wish I could share with you my source so you can see why its > > necessary. I've already tried various methods before settling on the > > solution I have now. My app now displays its custom graphics on the > > G1, Droid, and Dell Streak's specs on the emulator. > > > My app is a utility that uses rendered graphics to make the app look > > nice. I have imagery that is 320x480 for use on mdpi devices, and > > imagery at 480x720 for use on hdpi and large devices. My goal was to > > create graphics that would not require resizing for the majority of > > high res devices. The Dell Streak being a high res device should have > > used the 480x720 imagery, but instead used the images in the 'drawable- > > mdpi'. It was only after I created a 'drawable-large' folder with a > > duplicate set of 480x720 images that the Dell Streak would finally use > > them. I could have worked it out so that the Streak would use the > > graphics in the mdpi folder and just scaled them up to fill the > > screen, but that would have been a bad solution for people capable of > > displaying high resolutions. > > > I also tried creating a 'drawable-hdpi-large' folder, but it wouldn't > > work for some reason. > > > I hope this makes sense and helps explain the issue I was having. I > > found that the resource aliasing only works from a 'drawable' folder. > > I've copied all my high res images into that folder and I have > > references in my 'drawable-hdpi' and 'drawable-large' folder. > > > I believe it is a shortcoming of the way Android is designed where I > > can't run the alias's from anything other than the 'drawable' folder. > > > I understand the difference between screen sizes and dpi', I'm just > > trying to find a simple way to make a device utilize graphics that its > > capable of supporting. > > > Thanks, > > Stephen > > > On Jul 2, 5:33 pm, Dianne Hackborn <[email protected]> wrote: > > > Why do you want to do this? The Streak's screen is really what it > > reports > > > -- mdpi density, but more space. If you use hdpi graphics, then your > > > graphics will appear incorrectly large on the screen. You should layout > > > your UI to use the extra space, not blow it up larger. > > > > The main time I can think where it would be okay to just use larger > > graphics > > > is a game, where having everything blow up bigger is not so noticeable. > > In > > > that case, you should maybe just go down the path of picking the graphics > > > you want to use explicitly based on the raw space you have to work with. > > > Before going down that road, though, you should probably stop and > > consider > > > what it really means to be manually adjusting for whatever the screen is. > > > > On Fri, Jul 2, 2010 at 5:15 PM, Stephen Lebed <[email protected]> wrote: > > > > I'm hoping there is an answer to my problem. I've created two sets of > > > > graphics for my app. A set for medium res phones and a set for high > > > > res phones. I've placed them into their drawable-mdpi and drawable- > > > > hdpi folders. > > > > > I've now learned that the Dell Streak identifies itself as a large- > > > > mdpi display. I've created a drawable-large folder and placed the > > > > high res images into it. Its so far, everything is working in the > > > > emulator. > > > > > My problem is I would like to create a single set of high res graphics > > > > and have it availalbe to both drawable-hdpi and drawable-large. I've > > > > tried using the example in the docs > > > > >http://developer.android.com/guide/topics/resources/providing-resourc. > > .. > > > > > but it doesn't seem to work. I wanted to use drawable-hdpi to store a > > > > single copy of all the high res images, and store the xml aliases in > > > > drawable-large. It compiles without error, but when my app tries to > > > > read the drawable, it throws an error, Null Pointer Exception. > > > > > Does the alias xml file only work with images in drawable, or can they > > > > be in a drawable-hdpi folder? When I try to pull the file from > > > > drawable-hdpi it causes the error. > > > > > Any help would be appreciated. > > > > > Stephen > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Android Developers" group. > > > > To post to this group, send email to > > [email protected] > > > > To unsubscribe from this group, send email to > > > > [email protected]<android-developers%2Bunsubs > > > > [email protected]><android-developers%2Bunsubs > > [email protected]> > > > > For more options, visit this group at > > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
