288 CHAPTER 8: Android UI Design: Using Advanced ViewGroup Layout Containers
be a “visual” list of popular galaxies including the milkyWay galaxy in the left content browser pane,
and the resulting display of their planetary information in the right pane primary detail view, once the
ImageButton for each Galaxy object is clicked.
The primary objective of the SlidingPaneLayout UI layout container class is to have the UI and the
content the UI controls simultaneously visible. The SlidingPaneLayout was not meant to be utilized
to implement screen-switching UI designs, which allow your user to navigate between different
functional Activity subclasses within your Android application.
Task-switching use cases for providing application Activity navigation should use Options Menu and
ActionBar-based UI design approaches instead. The use of a SlidingPaneLayout should be for an
app or Activity that keeps the user in “single task mode,” and optimizes the UI design to maximize
the functionality between your UI and your content parts of the screen, which maximizes the user’s
ability to focus upon, and to complete, the task at hand.
The SlidingPaneLayout approach to UI design should therefore be considered when you require a
more “niche” UI layout container, which would be considered to be a memory-efficient approach to
implementing a dual-pane UI layout.
This UI layout container should target primary usage on large display screens (tablets, notebooks,
and iTV Sets, including the 2K HDTV and 4K UHDTV), but which also needs to provide seamless
user experiences for end users on smaller Android device screens (mini-tablets, eBook readers,
smartphones, and smartwatches).
SlidingPaneLayout Technical Considerations: Layout Weight
Inside of your SlidingPaneLayout parent container (the parent XML tag), the child UI widget objects
(child XML tags), in this case they will be
only occur if the combined width of the UI elements exceeds the available width that you specify for
a SlidingPaneLayout parent container.
Your parent SlidingPaneLayout container tag’s android:layout_width and android:layout_height
parameters will usually be configured using the MATCH_PARENT constant. This will define a
SlidingPaneLayout to fit all of your Activity subclass’s available screen real estate, so that it can
“morph” between different device screen sizes and orientations, which is what it’s designed to do,
so you want this UI layout container to be in “full screen” mode.
When an overlap UI layout scenario is encountered on a smaller display screen size or on a portrait
orientation display screen, your user will be able to slide the UI (first or top View child object) away
from obscuring your content View. The user accomplishes this by dragging the UI pane, or using a
keyboard to navigate in the direction of the overlapped View. If the UI (or content) for the child view
is horizontally scrollable, then your user may also grab this content, using the edge of this content.
It is important to note that we are covering another UI container which supports the android:layout_
weight parameter. The LinearLayout container, which we learned about in Chapter 6, also supports
this concept of UI layout weight, so you should be sure to apply everything that you’re about to learn
about android:layout_weight parameter here to your LinearLayout UI design skills.
I was covering so many other foundational concepts back in Chapter 6 that I didn’t have room to get
into layout weight, but I will cover it here, while hoping to keep this chapter to a reasonable length!