Thanks Dianne, that's clarified quite a few things for me. I guess my disconnect was started by fact that the layout qualifiers allow for a density specifier.
William On Feb 25, 6:49 am, Dianne Hackborn <hack...@android.com> wrote: > 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
