16 - Understanding Android View, View Groups and

Layouts
#View #ViewGroup and #Layout are the elements that are brought together to create a UI.
16.1 Designing for Different Android Devices
A well-designed user interface should be able to adapt to changes in device orientation, as well as different
device sizes.
16.2 View and View Groups
Every item in a UI is a subclass of the #Android #View class (to be precise android.view.View). Typical
examples include standard items such as #Button, #CheckBox, #ProgressBar and #TextView classes. Such
views are also referred to as widgets or components. For requirements that are not met by the widgets
supplied with the SDK, new views may be created either by subclassing and extending an existing class, or
creating an entirely new component by building directly on top of the #View class.
A view can also be comprised of multiple other views (otherwise known as a #compositeView). Such views
are subclassed from the Android #ViewGroup class (android.view.ViewGroup) which itself is a subclass of
#View. An example of such a view is the #RadioGroup, which is intended to contain multiple #RadioButton
objects such that only one can be in the "on" position at any one time. In terms of structure, composite
views consist of a single parent view (derived from the ViewGroup class) and otherwise known as a
#containerView or #rootElement that is capable of containing other views (known as #childViews)
Another category of #viewGroup based container view is that of the #layoutManager
16.3 Android Layout Managers
#Layout s are container views (and, therefore, subclassed from ViewGroup) designed for the sole purpose of
controlling how child view are positioned on the screen.
The #AndroidSDK includes the following layout views:
1. #ConstraintLayout - recommended for most layout requirements. Allows positioning and behavior of
the views in a layout to be defined by simple constraint setting assigned to each child view. The
flexibility of this layout allows complex layouts to be created easily and quickly without having to
nest layouts inside of each other, resulting in improved layout performance.
2. #LinearLayout - Positions child views in a single row or column depending on the #orientation
selected. A #weight value can be set on each child to specify how much of the layout space that
child should occupy relative to other children.
3. #TableLayout - arranges child views into a grid format of rows and columns. Each row within a table
is represented by a #TableRow object child, which, in turn, contains a view object for each cell.
4. #FrameLayout - allocates an area of the screen, typically for the purpose of displaying a single view.
If multiple child view are added they will, by default, appear on top of each other positioned in the
top left-hand corner of the layout area. Alternate positioning of individual child views can be
achieved by setting gravity values on each child. Ex: setting a center_vertical gravity values on
a child will cause it to be positioned in the vertical center of the containing FrameLayout view
 5. #RelativeLayout - allows child views to be positioned relative both to each other and the containing
layout view through the specification of alignments and margins on child views. ex: childView A
may be configured to be positioned in the vertical and horizontal center of the containing
RelativeLayout view. View B , might also be configured to be centered horizontally within the
layout view, but positioned 30 pixels above the top edge of View A , thereby making the vertical
position relative to that of View A . The RelativeLayout manager can be of particular use when
designing a UI that must work on a variety of screen sizes and orientations.
6. #AbsoluteLayout - allows child views to be positioned at specific X and Y coordinates within the
containing layout view. Use of this layout is discouraged since it lacks the flexibility to respond to
changes in screen size and orientation.
7. #GridLayout - an instance is divided by invisible lines that form a grid containing rows and columns
of cells. Child views are then placed in cells and may be configured to cover multiple cells both
horizontally and vertically allowing a wide range of layout options to be quickly and easily
implemented. Gaps between components in a GridLayout may be implemented by placing a
special type of view called a Space view into adjacent cells, or by setting margin parameters
8. #CoordinatorLayout - introduced as part of the Android Design Support Library with Android 5.0,
the coordinator layout is designed specifically for coordinating the appearance and behavior of the
app bar across the top of an application screen with other view elements. When creating a new
activity using the Basic Views Activity template, the parent view in the main layout will be
implemented using a CoordinatorLayout instance.
These can be nested within each other to create a UI design of just about any necessary level of complexity.
16.4 The View Hierarchy
Each view in a UI represents a rectangular area of the display. A view is responsible for what is drawn in that
rectangle and for responding to events that occur within that part of the screen (such as a touch event).
A UI is comprised of a view hierarchy with a root view positioned at the top of the tree and child view
positioned on branches below. The child of a container view appears on top of its parent view and is
constrained to appear within the bounds of the parent view's display area.
![[attachments/CleanShot Nitro PDF Pro-Android Studio Flamingo Essentials - Java - Neil Smyth.pdf (Page
146 of 817)-2023-08-16 at [email protected]|400]]
In addition to the visible button and checkbox views, the UI actually includes a number of layout views that
control how the visible views are positioned:
![[attachments/CleanShot Nitro PDF Pro-Android Studio Flamingo Essentials - Java - Neil Smyth.pdf (Page
146 of 817)-2023-08-16 at [email protected]|400]]
We can also visualize the above user interface example in the form of the view tree:
![[attachments/CleanShot Nitro PDF Pro-Android Studio Flamingo Essentials - Java - Neil Smyth.pdf (Page
147 of 817)-2023-08-16 at [email protected]|600]]
The view hierarchy diagram gives probably the clearest overview of the relationship between the various
views. When a UI is displayed to the user, the Android runtime walks the view hierarchy, starting at the root
view and working down the tree as it renders each view.
16.5 Creating User Interfaces
There are 3 different approaches to UI design: using the Android Studio Layout Editor Tool, handwriting XML
layout resource files, or writing Java code.
16.6 Summary
Each element within a user interface screen of an Android application is a view that is ultimately subclassed
from
the android.view.View class. Each view represents a rectangular area of the device display and is responsible
both
for what appears in that rectangle and for handling events that take place within the view's bounds. Multiple
views may be combined to create a single composite view. The views within a composite view are children of
a
container view which is generally a subclass of android.view.ViewGroup (which is itself a subclass of android.
view.View). A user interface is comprised of views constructed in the form of a view hierarchy.
The Android SDK includes a range of pre-built views that can be used to create a user interface. These
include
basic components such as text fields and buttons, in addition to a range of layout managers that can be
used
to control the positioning of child views. If the supplied views do not meet a specific requirement, custom
views may be created, either by extending or combining existing views, or by subclassing android.view.View
and
creating an entirely new class of view.
User interfaces may be created using the Android Studio Layout Editor tool, handwriting XML layout
resource
files or by writing Java code. Each of these approaches will be covered in the chapters that follow.