Question

I've got a situation where I bring up a color picker. If it's done in portrait mode everything is fine. But if I do it in landscape mode (the dialog doesn't fit on the screen) it seems to be blowing up when trying to inflate the layout.

Is there some special way to do this in landscape mode where the view doesn't fit entirely on the screen?

Any differences I need to take into account other than screen real estate?

Was it helpful?

Solution

CraigA,

After reading your comments, it seems there is a misunderstanding about the way that different widths and heights are generated in XML. This is a common misconception at first. So, the thing to understand here is that the width of the various objects, while dynamic, impose different behaviors upon your objects.

layout_width/layout_height generally

The width and height parameters do not affect the actual width and height of the object. They affect the display width and height. This means that you can set the width and height to smaller than the contents, and the contents will still be accessible when scrolling, if they are bigger than the container.

Since many child Views take their cues from the parent Views, this can result in behavior like you are seeing above. The trick here is first to understand what is going on, and then compensate for the behavior of the system.

match_parent/fill_parent

Ordinarily, this means that the current View will get its size from the parent. If the View is a top-level View, the behavior changes slightly. If this happens to be the top level View of a Dialog, then it will be the size of the screen or the size of the contents (whichever is smaller). If the View is the top-level View of an Activity, then the results are the same, but they look different. That is, it will have the full Activity opacity and background, but the View's size is only that of the contents or size of the screen (whichever is smaller). The children's sizes are unaffected unless their width/height is based upon that of this View.

wrap_content

In this case, the display height is based upon the display heights of all of the immediate children. This behavior cascades down to the "youngest" descendants until the hierarchy uses something other than wrap_content.

Your issue (as it appears right now)

Your top level view uses wrap_content, so the display size will be based upon all of the children's display sizes. In this case, it might be better to use match_parent' orfill_parent` (depends on your API) for your top level View only. This will at least get the Dialog to be the appropriate size, if not the contents. For those controls whose size is based on the top level View, they will come into line. Those that aren't will have to be adjusted manually.

Now, the decision you have to make here is implementation. Do you need to adjust the sizes for every display, or just the landscape. If your changes have no effect upon the portrait display, then one file should be good. If not, you will want a layout file for portrait (the current one), and then an adjusted one for landscape mode.

If you are using two files, you will have a folder named layout_port for the current one to be stored. You will add a folder named layout_land for the adjusted one. They will be of the same name, just housed in the separate folders.

Hope this helps,

FuzzicalLogic

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top