Awesome now it's time to assign values to these new variables.

Let's start by adding four new lines to the bottom of onCreate.

Then on the second new line let's add a comment, // Assign

the Views from the layout file to the corresponding variables.

It's important that we don't assign the views until

after the call to setContentView.

If we try to access a view from our layout before calling setContentView,

it won't exist and we'll get an error.

On the next line, let's start typing factTextView and then an = sign.

And now what we need is a method that will take in the ID that we set on the layout

and return our TextView.

Fortunately, every activity has a method for this, and it's called findViewById.

Let's start typing findViewById after the equals sign.

And notice that as you're typing the auto complete feature is filling it in below.

Android Studio analyzes what we're typing offers suggestions that

match what we've typed so far.

Automatic code completion is awesome, it's super convenient, and it makes it so

that we only need to remember the first few letters of something and

Android Studio will take care of the rest.

Now we can either finish typing this method, or

we can just hit Enter to select it from code completion.

And now we see a hint about the parameter we need to use here.

The findViewById method requires an ID as its parameter.

But rather than just type in the ID from the layout,

we must refer to it through a generated resource class.

When we built our project, Android automatically builds a class for

us called simply R, which stands for resources.

This class contains all the IDs of our files and

the res directory, as well as a ton of other default resource IDs.

If we open the project pane and

switch to the project perspective and then drill into app,

build, generated, source, r, debug, and

then our package name, we can even open the R class.

Though notice at the top there's a warning saying,

files under the build folder are generated and should not be edited.

We're not here to edit anything, it's just nice to know where the R class comes from.

Let's close this and switch back to the Android perspective.

And I'll hide the project pane again.

Back in funfactsactivity.java, let's type a capital R followed by a dot.

Then we need to pick which type of resource we're looking for.

Since we're looking for an ID, let's type id followed by another dot.

And look at that, it's showing us the IDs that we set in our layout.

Let's pick factTextView, and hit Enter to select it, and semicolon.

Now depending on which version of Android you're using,

you might see an error, like I do, or

if you're targeting a newer version of Android, everything will be just fine.

So what happened?

Let's take a look at some code to see what changed in the new version of Android.

Here we've got a Java project where we've mocked out some classes from

the Android API.

We start by creating a fake view class, and

then we create a button and text view classes that extend from our view class.

Then we create an activity class and give it a findViewById method that takes in

an integer and returns a view, just like you'd find in the actual activity class.

Inside this method, we create a local view variable.

And depending on whether the ID is a one or a two, we set it equal to

either a new button or a new text view before returning a view variable.

Finally we've got a main activity class which extends from activity, and inside

that class' constructor we try to set up two variables, a button and a text view.

This is the same error I'm getting back in Android Studio, incompatible types.

It's expecting a button but we're setting it equal to a view to fix this.

Since we know that findViewById with the parameter

of 1 will indeed return a button, we can just cache the returned

value to a button by adding the word Button and parentheses.

And we can do the same thing for

a text view by using Alt Enter to apply a quick fix.

However, in Android Oreo they made a change to the way we

use findViewById that means we no longer need the cast.

So let's undo the casts.

And now let's take a look at how they change the findViewById function.

Up in the findViewById method, instead of returning a view,

we want to use something called generics to let us return multiple types.

Don't worry too much if this part doesn't make sense.

What's important is how it affects our view variables, not how it's implemented.

Let's start by declaring our generic and

what types it's allowed to have inside angle brackets.

Here we're declaring a generic, named T, and

saying it can only be a class with the view class as a parent.

Then instead of returning a view, let's return our new generic type, T.

Finally since we've changed the return type from View to our generic type

that extends View, we need to add a cast to our view variable before we return it.

Perfect, now we no longer need to add a cast to our findViewById calls.

Though since this change is fairly recent, you're likely to encounter

a lot of code that still uses casts with findViewById.

So if you see any code that's still using casts and

it's not giving you issues, feel free to ignore it.

You're just on a newer version of Android than we are.