I'm not sure I am totally following you, but if you have two different layouts, one for smaller screens, and one for larger screens, then yes you probably want to have two resources, one with no qualifiers (for the smaller screens), and one with the appropriate screen size qualifier for the larger screens it is intended for.
As a general rule, if you see a density qualifier being used with a layout, there is probably something wrong. Layouts are density independent -- that us why there are "dp" units and such for any sizes you use in the layout. As the most general case, there is really a continuous range of densities and screen sizes. We created the bins for each early on, to ease things for developers, but this is an arbitrary restriction. In fact in 3.2 we realized that the bins for screen sizes wasn't working, which is why we have dropped them in favor -swNNNdp and related configurations. This is actually easy for developers, because they had to deal with a pretty much continuous range of screen sizes anyway, we already have good tools for handling this (through layout managers), and now they can be much more explicit about the break-points where they want to switch between different layouts. The same situation nearly exists for density as well. You can run a device at any reasonable density you want, and applications will still work. There is not as clear a case for allowing this though -- it definitely causes more pain for developers who have a much harder time deciding how to create graphics, and there is not as much benefit for device manufacturers to have such freedom. However, even so, tvdpi was introduced in I think 3.2. It is an interesting density between mdpi and hdpi. It is certainly conceivable for other new densities to pop up in the future. So, that leaves us, with both screen size and screen density needing to be treated really as continuous ranges. For this to work, something must help applications turn a small discrete set of design points into supporting a range of values. For screen size, this is layout managers. For density, this is the automatic scaling of bitmap drawables and dp units. If you are using density configurations with layout resources, you have a fundamental issue because layouts can *not* be scaled to match the actual density. So what happens if you have a layout-hdpi and are now running on an xhdpi screen? We'll use the layout-hdpi resource because that is the best match, but there is no mechanism to know how to transform that into something appropriate for an xhdpi density. So the layout-hdpi is a break point where your layout changes in some fundamental way across different densities... but does that even make sense? If I have one device with a normal size mdpi screen, and another with a normal size hdpi screen (so they are the same size in my hand, just higher density screens), why would the layout be different between them? I should just see UI elements with finer details, not a different layout of those elements. On Thu, Feb 23, 2012 at 7:39 PM, William Ferguson < william.ferguson...@gmail.com> wrote: > So Dianne, you're saying that if I only have a single configuration > for a screen size that I might as well drop the density qualifier as > it will have no impact, as the screen size will totally override the > decision as to which resource is used, > > This means that if I want to implement the layouts I thought I have > been supporting I will need 4 definitions of 2 layouts > - default - layout_A_less_capabable_screens > - large-mdpi - layout_A_less_capabable_screens (this config does not > currently exist). > - large-hdpi - layout_B_more_capabable_screens > - xlarge - layout_B_more_capabable_screens > > Or if I want to implement the layouts I have actually been supporting, > I can collapse this to > - default - layout_A_less_capabable_screens > - large - layout_B_more_capabable_screens > > > William > On Feb 24, 11:09 am, Dianne Hackborn <hack...@android.com> wrote: > > Keep in mind that all densities are a potential match, and screen size is > > considered a more significant match than density. So if there is the > > choice between resources with two different densities, but one has a > better > > match for the screen size, the screen size will win. > > > > And I will say what I usually do -- I very strongly recommend mixing > screen > > size and screen density qualifiers in the same configuration. These are > > two * orthogonal* axis. You will need to think very hard and long about > > the set of different screens that are going to match the qualifiers you > > have, and I think it most cases this is *not* what people are thinking. > > Usually people do this because they think they are more finely-tuning to > > try to design for a specific screen resolution, but that is not what this > > does. > > > > On Thu, Feb 23, 2012 at 1:48 PM, William Ferguson < > > > > > > > > > > > > > > > > > > > > william.ferguson...@gmail.com> wrote: > > > Thanks for the review Mark. > > > I didn't think I was going insane, just tearing my hair out. > > > > > William > > > > > On Feb 23, 11:15 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > > Replying to the list: > > > > > > On Thu, Feb 23, 2012 at 2:54 AM, William Ferguson > > > > > > <william.ferguson...@gmail.com> wrote: > > > > > you can download a very small project showing this behaviour from > > > > > [REDACTED] > > > > > Deploy it to a 2.2 (I haven't tested other Android Version but I > > > > > expect the same) AVD with a resolution of WVGA800 (800*400) and > > > > > default "Abstracted LCD density" of 160dpi (ie mdpi). > > > > > The buttons will show the text for large hdpi. > > > > > > Well, I can reproduce the problem, on multiple Android emulator > > > > versions (including 4.0) and the original Galaxy Tab 7. > > > > > > In the sample you sent me, it pulls from res/layout-large-port-hdpi/ > > > > > > If I add a res/layout-large-port-mdpi/ directory, that gets used on a > > > > 4.0 emulator and the 2.2 emulator, but not the Tab 7. > > > > > > That's indicative of a bug in the Tab 7: > > > > > > > http://stackoverflow.com/questions/7049659/understanding-samsung-gala... > > > > > > In terms of why it pulls from res/layout-large-port-hdpi/ instead of > > > > res/layout-xlarge-port/ or res/layout-port/, I cannot say. > > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > > > > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > > > Android Training...At Your Office:http://commonsware.com/training > > > > > -- > > > 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 > > > > -- > > 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 > -- 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
