Another common way to investigate our app while it's running

is to use the Android log.

We can add calls to different log methods that will write them to the Android's

system log.

We can then view the log in our IDE using logcat while the app is running or

even at a later time.

Even if our app crashes the log remains,

often holding helpful information about why the app crashed.

Let's check it out.

Let's start by logging some information from our app.

Right now, we're showing a Toast when FunFactsActivity is first created.

But our users don't really care about that do they?

Let's comment out our Toast and write a message to the log instead.

We write to the log using the log class and

then one of its static methods, just like we did with Toast.makeText.

These methods also don't return anything, so

we don't need to store them in a variable.

Just like toasts, we can add these log method calls all over the place

to log information about how our app is running.

Let's take a quick look at the documentation from the log class.

This is the reference for the log class from the Android developer site.

If we take a look at the class overview,

it tells us that we generally use one of five methods.

Log.v, d, i, w or e.

These letters stand for different levels of logging.

E is for errors, w for warnings, i for

informational, d for debugging, and v for verbose.

Which is used when you're trouble shooting something and

want to spam as much information to the log as possible.

Android does this so we can choose the appropriate level for our log entries.

We can then filter only the log levels we care about when viewing the log.

For example, we may be troubleshooting an error and

only want to look at error messages.

If we log information about the error with the log.e method,

then we can filter the log to see just error messages and ignore everything else.

If we scroll down, we can see some more of the constants and other methods.

Here's one called wtf which stands for What a Terrible Failure.

That's [LAUGH] only for extreme errors though and you'll probably never use it.

All right, let's take a look at how to use the log methods.

They're all used the same way, so let's take a look at the debug method.

On a new line let's type Log, hit Enter to import it and then add dot d.

And autocomplete shows us this method requires two parameters.

The second parameter is the data we want to write to the log.

The first parameter is what's known as a tag and it's also a string.

The tag is used to identify the source of the log message.

It usually identifies the class or activity where the log call occurs.

The log contains a lot of information which we'll see in a moment.

Remember, the log contains log messages from all apps and the operating system.

So supplying a tag lets us know where the message came from.

And it also lets us filter by tag and the log path.

For the first parameter,

let's type FunFactsActivity inside of quotation marks to make it a string.

Then add a comma and our log message will be,

We're logging from the onCreate() method.

Right, let's run the app to see it in action.

Okay, but where did our log message go?

Let's take a look at the logcat.

It usually lives here at the bottom under the code editor.

But if it's missing just go down here and click on Logcat.

If that's missing too, click on this little box to make it show up.

This is the Logcat and it has all of the log data from the connected device

which we can see up here is the Emulator.

And if we look carefully, we can even see our log message.

It's easy to find because the longest currently only showing messages from

the selected application which up here is set to funfacts.

But that's no fun, let's change that from Show only select the application

to No Filters, to see what the log really looks like.

[LAUGH] Now that we've got a ton of log messages, let's do some filtering.

let's select the log level drop down and pick Debug.

This filters the log to show messages that are of debug level importance or higher.

That means by selecting Debug, we'll not only see debug messages but

also info, warn, error and assert messages.

Let's switch back to Verbose and look at another method of filtering.

In this text field which for

some reason you can barely see on my screen, we can search the log.

Let's search for our tag, FunFactsActivity.

Looks like there's a lot of log messages around our FunFactsActivity class.

Instead, let's search for a message.

I'll click the x to clear the search box and then start typing our message.

And as soon as we finish the first word, there's our message, nice.

Now let's hide this and go back to our code.

A common Android practice is to add a special property to our class called TAG.

Let's scroll up, and here, after we declare our class, let's add a line, and

type private val_TAG in all caps.

And let's set it equal to "FunFactsActivity" in quotes

just like we typed below.

And when we're at it, let's make one more change.

What would happen if we changed the name of our FunFactsActivity class

to some other activity?

Well, now our TAG would be a bit misleading.

Instead of hard coding the class name like we have here,

we can use a special method to get the class name automatically.

Let's delete FunFactsActivity and the quotes.

And instead, type FunFactsActivity without the quotes and

then ::class.java.simpleName.

We picked simpleName because something like qualified name would include

the whole package name.

Whereas simpleName leaves that out and

gives us just the class name, FunFactsActivity.

Now you might be thinking, we just typed FunFactsActivity again.

But this time, since isn't inside a string,

the refactoring tools will recognize it and make the change.

So if I refactor rename on FunFactsActivity and

rename it to SomeOtherActivity.

Notice that it changes here and my TAG too.

I don't actually want to rename this though, so I'll hit Escape to cancel.

Now notice that our TAG constant is still gray

because we haven't updated it down here in our debug log/call.

So instead of this hard coded string, let's use our TAG constant.

Then let's run the app to make sure it still works.

And there we go,

a new log message with the same FunFactsActivity TAG as we had before.

Logging can be incredibly helpful for troubleshooting problems with our apps.

It's also a great way to make sure everything is running like we expect it

to, especially when whatever we're testing [LAUGH] is invisible on the screen.