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

data to the Android 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 for the log class.

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

If we 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 is for warnings, i is for informational,

d for debugging, and v is for verbose.

Which is used when you're troubleshooting something and

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

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

We can filter only the log levels we care about when viewing a 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 of the constants and other methods.

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

That's only for [LAUGH] 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.d and

autocomplete shows us that method requires two parameters.

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

But the first parameter is what's known as a tag, also a string.

The tag is used to identify the source of a 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 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 the tag and the logcat.

For the first parameter, let's type FunFactsActivity inside quotation marks,

and first let me hit Alt+Enter to import the log.

Okay, "FunFactsActivity".

Then add a comma and our log message will be,

"We're logging from the onCreate() method!");.

All 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 this little box to make it show up.

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

which we can see right here is the emulator.

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

It's easy to find because the log is currently only showing messages

from the selected application, which up here, is set to our FunFacts app.

But that's no fun.

Let's change that from Show only selected application to No Filters

to see what the log really looks like.

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

Let's select the Log Level dropdown, and pick Debug.

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

This means that, by selecting Debug, we'll not only see Debug messages, but

also Info, Warn, Error, and Assert messages.

Lets switch back to Verbose and look at another filtering method.

In this text field, we can search the log.

I'm not sure why it's so small, but it's here so let's click in it.

And let's search for our tag of FunFactsActivity.

And wow, that is really frustrating that we can't see it, and

I can't seem to make it any bigger.

So I guess we're stuck with it.

Anywho, it looks like there's a ton of messages that say FunFactsActivity.

So instead, let's search for our message.

I'll hit the x to clear my box.

So I'll type we're and once 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 field to our class called tag.

Let's scroll up.

And here, after we declare our class, let's add a line and

type public static final String and then TAG.

Let's set it = "FunFactsActivity" just like we typed below.

Remember that static final means that this tag is always available,

static, and that its value will never change.

Final, in other words, it's a constant.

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 little bit misleading.

Instead of hardcoding the class name like we've done here,

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

Let's delete FunFactsActivity and the quotes.

And instead, type FunFactsActivity, with no quotes,

and then .class.getSimpleName.

We pick getSimpleName because getName includes 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 it isn't inside a string,

the refactoring tools will recognize it and make the change.

So if I Refractor rename on FunFactsActivity and

rename it to some other activity, notice that it changes here and my tag too.

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

Now, notice that our log constant is still gray,

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

So instead of this hardcoded 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 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 isn't visible on the screen.