Okay, so we're back in Android Studio. Let's have a closer look now at this view Inspektor.
So click on the image view if it's not clicked and we've got the view inspector.
Now inside the inspector, are four lines inside the square here,
and they're used to set how the width and height are interpreted.
Now Google refer to these as the inner lines within a widget.
Now at the moment they're both using the values that we've specified in the layout_width
and the layout_height boxes. This is the 200 by 200 dp.
So that's actually called fixed,
but if I come up here and actually click on one of these, we can change them to match_constraints.
So click on that now, and you can see that we had a change with the image view on the screen and also the
mark has changed to a sort of spiky graph, a bit like the electronic symbol for a resistor.
If you click it again now, you can see that's
down here now in the layout_width. Let's change that to wrap_content and the marker's changed to chevrons. And notice
how fitStart and fitEnd work
when the horizontal width is set to wrap_content and the layout_height is set to 200 dp. The vertical and
horizontal lines change independently.
So what do they all mean?
Well at the moment we're working with an image that's actually bigger than the device screen.
The image is 640 by 480 and our screen isn't that wide.
Now please trust me on that for a moment.
It probably doesn't make sense because our nexus 4 has a width of 768, but I'll be explaining that shortly.
To prove, though, that it's wider than the screen,
We're going to click the vertical and horizontal inner lines until the layout_width and layout_height change to wrap_content.
So you can see that I've got wrap_content from our layout_width. I'm gonna do the same for the layout-height now, clicking on
it once and then clicking on it again.
You can see we've got now wrap_content, although we can't quite see that in the boxes. It's been set for both the
layout_width and layout_height.
The other thing you want to do now is come out here to scaleType and make sure that's now set to fix
XY.
So now that I've done that, the image has to be compressed horizontally.
So we've got that rugby ball or AFL football, which means it must have been wider than the available
space.
Now even changing the left margins to zero doesn't help.
So if I try doing that to zero, we've still got this issue here
where clearly, it's not fitting and I'll just change that back to 16. So ignore the numbers for now and trust your
eyes. The image itself is definitely wider than the screen.
Now it's easy to understand what these inner line settings are doing, that we've been working with,
if we use a smaller image. So I'm going to change the imageView's source attribute, which is abbreviated
to SRC.
Now because we're using the appCompat library to make our app compatible with older devices, the attribute
down here is called Source Compat, srcCompat, and it's one of the most commonly used properties that
appears in the right hand pane.
By the way, this plane is dynamic.
So if you happen to have unticked the compatibility option when creating the project, it will actually be labelled
as src rather than srcCompat. But unless you've got a really good reason, for example, you're producing
a corporate app targeting a specific version of Android that a company is settled on, then you should
really use the appCompat library and you should be seeing source compat in the properties pane,
as is showing on the screen here now.
So what I'm going to do is use the smaller ball image, the ball_100x100, so that we can get a
better feel for how this works.
Now I could just come over here
and go into that box, and you can see the name of the current image is ball_640x480.
So I could just change and type that in,
and that would certainly work.
But if I come over here and click on the ellipsis, over here, click on that, we get the resources dialogue,
and I can select the image I want from there.
So that's actually a lot easier.
It removes the risk of typing the name incorrectly. So I'm going to select ball_100
x100 and click OK.
The other thing I'm going to do is change the layout_width and height back to 200 dp, so let's go
into there, 200 dp.
And I'm just pressing tab now, 200 dp. Press enter there. Now notice that the settings and the inner lines are
linked.
When we click the inner lines, the layout-width and layout_height settings change, and also in this case, when
we typed a value, or chose one of the settings for the width and height, then the inner lines also changed to
reflect the new settings.
So in other words, we're back to a fixed setting here now.
So at this point, we've now got a 200 x 200 imageView, containing a 100 x 100 image of a
ball.
Now by the way, I've given the ball a green background, so you can easily tell when the image is
smaller than its container,
the imageView, and I chose a ball, not because I'm mad about soccer, but because it's easier to see when the
image gets skewed when it's resized, which means that the aspect ratio isn't being maintained.
Now to get a more visual idea of what happens when I change the inner lines,
you want to make sure that the scaleType is set to fitXY, which I've already set here.
So at the moment, we're using a fixed width and height, so the values for the layout_width and layout_height
are being used and the current size of the image view is 200 x 200. But if we change the layout_width
to match_constraints by clicking the horizontal inner lines,
as I've done there, you can see that the widget's now expanded to fill the screen, left to right.
Now if you've designed Android's layouts before, by the way, this may look the same match_parent, but it's
actually slightly different because it considers the constraints.
Now if you're new to Android layouts, match_parent is a way of sizing a widget so that it fits all the available
space in its parent, its parent being the layout it's been placed into. Now match_constraints looks exactly
the same as match_parent here.
It's causing the widget to expand to fill the width of the screen, allowing for the left and right
margins, and you'll see slightly different behavior once we have some more widgets on the screen.
Now if I come over here and click on the horizontal inner lines again, it's going to change it to wrap_content,
so let's do that.
This makes the widget become as wide it needs to be, to fit whatever it contains. Now because we're using
a 100 x 100 image,
the imageView is now a 100 dp wide. Because we chose fitXY as the scaleType, the image is scaled vertically
to fit the fixed height of the imageView, which is still 200 dp, so therefore the football becomes, sort of,
like a rugby ball or AFL football or Easter egg, if chocolate is more your thing than rugby.
So I'm just going to do the same thing here with the vertical sizes, and then I'm going to explain about
those strange units, the 100 dp and the 200 dp.
So I'm gonna click on that until we get wrap_content.
You can see that initially, it changed it to match_constraints, and the imageView got stretched to fit
the height of the layout.
Now I'll just do that again so we can go back and see what I did.
So I clicked that once, and you can see that the imageView stretched to fit the height of the layout, and it
looks a bit frightening rather than a rugby ball or chocolate egg.
By clicking it again, you change the layout-height to wrap_content and we get an imageView now that's 100 x
100 to match the image that it contains.
So the imageView is, basically at this point now, sized both vertically and horizontally to match
its contents, which of course were a 100 x 100 image.
Now there's still a lot to look at in this designer, and if you're used to using the older layouts that were
available, you're probably getting pretty excited about the way that this ConstraintLayout works.
But before I go on to the really exciting stuff, where we constrain widgets to other widgets, I should
probably explain what these device independent pixels or dp units that we're using are. Now our image is
100 pixels wide by 100 pixels high,
and the previous image we used was a more usual 640 pixels wide by 480 pixels high.
Now 640 by 480 is a common size because, and do you may not believe this, that was the resolution of early computer
screens.
I can still distinctly remember how excited I was when I got my first 1024 by 768 monitor. The aspect
ratio was one and a third, so the screen height was three quarters of its width.
Now the current trend is for screens to be much wider.
So we now tend to have resolutions of 1280 by 720 or HD screens of 1920 by 1080, giving an aspect
ratio of about 1.8.
But that's computer screens though, and mobile phones are generally the other way around.
So computer screens are in landscape and mobile phones,
well they're in portrait. Now different screens have different resolutions as well, and modern screens are
managing to pack in far more pixels per inch then was previously possible.
So this is the pixel density.
So if you've specified dimensions in pixels, your image might look OK on one device, but may look a
bit grim something with a different pixel density.
The number of pixels per inch varies from one device to another, and that can result in our ball appearing
in different sizes, relative to the size of the screen.
Now we're going to use the Android Studio layout designer to make it easy to see how things look on
different devices.
We're going to start on that in the next video.