Great. So to move one step closer to building awesome apps
like the ones you submitted to the discussion forum,
we're going to learn about how to build up the Sunshine UI.
We'll do a quick recap first to help remind you of the concepts
that you learned in lesson one.
In order to build a UI in Android, we use Views.
Views are rectangles on the screen,
and we may or may not see the borders of that rectangle.
Essentially, a view handles drawing and event handling,
and all the basic widgets in Android extend from this base class.
The Android design guide has visual examples
of these basic building blocks of apps.
For example, we have the basic text field, as well as editable text fields.
You can do auto complete on them, and it comes with text selection as well,
where it pops up a contextual action bar, for you to copy and paste.
There are also buttons,
and also a suggestion to use borderless buttons.
It also has spinners,
where you can select from a drop down menu.
There's also checkboxes, radio buttons, on/off switches,
and they also have some progress bars.
There's a ton more basic widgets here, and also in the Java docs.
Check those out, and even ones that aren't listed here.
You'll come across them as you need them.
Now, if you want to display multiple views together,
you'll need a view group.
A view group is a container for children views.
Here are a couple of common view groups, which Dan introduced earlier.
First, we have a frame layout.
A child that gets added will be default positioned
in the top left corner of the view group.
If you add a second view here, it will overlap the first one.
So typically, we only have one child per frame layout.
Next we have a linear layout, it's composed of children
either in a horizontal row or in a vertical column.
We can also specify layout weight.
Layout weight allows us to distribute
the width or height of a parent across the children.
For example, this has weight one, and this has weight one
then the width of the parent can be split across them evenly.
Then we have a relative layout where we can specify that a view
should be aligned to the parent's left, top, right or bottom edge.
We can also specify that one view should be relative to another view.
It doesn't fill up the spaces nicely compared to a linear layout,
but there are pros and cons to each.
There's a grid layout where the views fill up cells in a grid.
You can also have views that span multiple cells.
I also want to point out that a view group is a view.
In our code when we refer to a list item layout
as being a single view, that just means the root view
of the whole view hierarchy for that layout.
Chances are that root view is a ViewGroup,
so it contains children views as well as ViewGroups.
So basically you can nest ViewGroups within ViewGroups.
The reason why we care so much about parent child view relationships,
is because the way a child view gets laid out depends on its parent.
The simplest example of this is specifying a view's width and height.
By now you've seen that every view requires a height and width.
The two possible values are either wrap content or match parent.
This diagram shows all the possible combinations
for width and height for this text view.
This is the balance of the view when we set wrap_content
for height and width.
This is what happens when we do match_parent for the width
and match_parent for the height.
And this is what happens when both are set as match_parent.
It fills up the full dimensions of the parent.
When you run this on the device, all of these would visually look the same,
because you wouldn't see these boundaries.
So why does it matter which one we pick?
Well, it matters as soon as you have other children
that need to be beside this view.
Another reason is if you want to specify gravity.
Let me spend a quick moment explaining gravity.
Say for example, you have this text view within a frame layout.
By default, the text is left aligned, and in this case, no gravity is set.
If we specify gravity equals center,
then it will center the content within the text view
Vertically it can't move because it's already centered,
but horizontally it does shift over to be in the middle.
Instead of this, if we specify layout gravity equals center,
that means to center horizontally and vertically within the parent.
So we grab the whole child text view and we move it into the center.
Now it can't be centered horizontally because it already takes up the max width
of the parent. If we really want to move the content to the middle,
then we should specify wrap content on this text view,
so that it can be moved to the center with this attribute.
You can also specify padding and margin on views.
For example, if you added padding on this text view,
then it would shift the content inside by x amount on all sides.
If you specify layout margin to be x, then remember that the parent is
the one who will be interpreting this layout prim.
In this case, it adds a margin of x all around the text view.
The text view is only this size.
When you render both of these, they would visually look the same.
Here's one case where it could matter.
If this was a button and you pressed it,
there could be a gray background here showing.
In some cases you may want padding or margin or both.
All views have a visibility property.
For this image view, it can be visible, invisible, or gone.
If it's invisible then it's not shown, but there's still a place holder for it,
we still have to go and measure the size of it.
If it's gone, then it's not even in the layout.
It's as if it didn't exist in the XML.
You can also toggle the visibility of a view dynamically during runtime.
In the Java doc, you can find all the possible XML attributes
for that class.
It also shows inherited XML attributes, for example, from the view class
for this image view,
and then it shows the corresponding Java methods for those attributes.
Now as a briefer, now we have some basics to help us get started,
but definitely check out the developer site for more details later.
Much like the real world, if you were working with a team
to build an Android app, you would start by implementing the wire frames first.
This has a correct flow for how the user will interact with the app.
But it doesn't have the final visual look and feel yet.
We'll build this up step by step, starting with the main activity
then we'll move on to the detail activity and then later build up the tablet UI.
Then we'll receive a set of visual marks, red lines and assets,
all of this will help us build a pixel perfect layout