Preview
Video Player
00:00
00:00
The Android Log
8:08Writing information to the Android system log lets us check how our app is working. Even if our app crashes, the log remains, often holding helpful information about why the app crashed. Let's take a look at how to write data to the log and how to view the log from within the IDE by using the logcat view.
Another common way to investigate
our app while it's running is to use
0:00
the Android log.
0:03
We can add calls to different
log methods that will write
0:05
data to the Android system log.
0:08
We can then view the log in our IDE using
logcat, while the app is running or
0:10
even at a later time.
0:15
Even if our app crashes,
0:17
the log remains, often holding helpful
information about why the app crashed.
0:18
Let's check it out.
0:23
Let's start by logging some
information from our app.
0:25
Right now, we're showing a toast when
FunFactsActivity is first created.
0:28
But our users don't really
care about that, do they?
0:33
Let's comment out our Toast and
write a message to the log instead.
0:36
We write to the log
using the log Class and
0:40
then one of its static methods,
just like we did with Toast.makeText.
0:43
These methods also don't return anything,
so
0:48
we don't need to store them in a variable.
0:50
Just like toasts,
we can add these log method calls
0:53
all over the place to log information
about how our app is running.
0:56
Let's take a quick look at
the documentation for the log class.
1:00
This is the reference for the log class
from the Android Developers site.
1:03
If we look at the class overview,
1:07
it tells us that we generally
use one of five methods.
1:09
Log.v, d, i, w, or e.
1:12
These letters stand for
different levels of logging.
1:17
E is for errors, w is for
warnings, i is for informational,
1:20
d for debugging, and v is for verbose.
1:25
Which is used when you're
troubleshooting something and
1:28
want to spam as much information
to the log as possible.
1:31
Android does this so we can chose
the appropriate level for our log entries.
1:34
We can filter only the log levels
we care about when viewing a log.
1:38
For example,
we may be troubleshooting an error and
1:42
only want to look at error messages.
1:45
If we log information about
the error with the log.e method,
1:47
then we can filter the log to see just
error messages and ignore everything else.
1:52
If we scroll down, we can see some
of the constants and other methods.
1:57
Here's one called wtf, that stands for
What a Terrible Failure.
2:06
That's only for [LAUGH] extreme errors,
though, and you'll probably never use it.
2:11
All right, let's take a look
at how to use the log methods.
2:15
They're all used the same way.
2:19
So let's take a look at the debug method.
2:21
On a new line, let's type log.d and
2:24
autocomplete shows us that
method requires two parameters.
2:27
The second parameter is the string
data we want to write to the log.
2:32
But the first parameter is what's
known as a tag, also a string.
2:36
The tag is used to identify
the source of a log message.
2:40
It usually identifies the class or
activity where the log call occurs.
2:43
The log contains a lot of information,
which we'll see in a moment.
2:48
Remember, the log contains messages
from all apps and the operating system.
2:52
So, supplying a tag lets us know
where the message came from.
2:57
And it also lets us filter by the tag and
the logcat.
3:00
For the first parameter, let's type
FunFactsActivity inside quotation marks,
3:04
and first let me hit
Alt+Enter to import the log.
3:09
Okay, "FunFactsActivity".
3:12
Then add a comma and
our log message will be,
3:17
"We're logging from
the onCreate() method!");.
3:22
All right,
let's run the app to see it in action.
3:29
Okay, but where did our log message go?
3:38
Let's take a look at the logcat.
3:41
It usually lives here at
the bottom under the code editor.
3:43
But if it's missing,
just go down here and click on Logcat.
3:47
If that's missing too,
click this little box to make it show up.
3:51
This is the Logcat, and it has all
the log data from the connected device,
3:55
which we can see right
here is the emulator.
4:01
And if we look carefully,
we can even see our log message.
4:05
It's easy to find because the log
is currently only showing messages
4:12
from the selected application,
which up here, is set to our FunFacts app.
4:15
But that's no fun.
4:20
Let's change that from Show only
selected application to No Filters
4:22
to see what the log really looks like.
4:28
Now that we've got a ton of log messages,
let's do some filtering.
4:30
Let's select the Log Level dropdown,
and pick Debug.
4:34
This filters the log to show messages that
are of Debug level importance or higher.
4:38
This means that, by selecting Debug,
we'll not only see Debug messages, but
4:43
also Info, Warn, Error,
and Assert messages.
4:47
Lets switch back to Verbose and
look at another filtering method.
4:52
In this text field, we can search the log.
4:56
I'm not sure why it's so small, but
it's here so let's click in it.
4:59
And let's search for
our tag of FunFactsActivity.
5:03
And wow, that is really frustrating
that we can't see it, and
5:10
I can't seem to make it any bigger.
5:13
So I guess we're stuck with it.
5:15
Anywho, it looks like there's a ton of
messages that say FunFactsActivity.
5:16
So instead, let's search for our message.
5:21
I'll hit the x to clear my box.
5:23
So I'll type we're and once we finish
the first word, there's our message, nice.
5:31
Now let's hide this and
go back to our code.
5:37
A common Android practice is to add
a special field to our class called tag.
5:40
Let's scroll up.
5:45
And here, after we declare our class,
let's add a line and
5:46
type public static final String and
then TAG.
5:50
Let's set it = "FunFactsActivity"
just like we typed below.
5:58
Remember that static final means
that this tag is always available,
6:06
static, and
that its value will never change.
6:11
Final, in other words, it's a constant.
6:14
Let's make one more change.
6:16
What would happen if we changed the name
of our FunFactsActivity class to
6:18
some other activity?
6:22
Well, now our tag would be
a little bit misleading.
6:24
Instead of hardcoding the class
name like we've done here,
6:27
we can use a special method to
get the class name automatically.
6:30
Let's delete FunFactsActivity and
the quotes.
6:34
And instead, type FunFactsActivity,
with no quotes,
6:38
and then .class.getSimpleName.
6:42
We pick getSimpleName because getName
includes the whole package name, whereas
6:45
simpleName leaves that out and gives us
just the class name, FunFactsActivity.
6:51
Now you might be thinking,
we just typed FunFactsActivity again.
6:57
But this time,
since it isn't inside a string,
7:01
the refactoring tools will
recognize it and make the change.
7:04
So if I Refractor rename
on FunFactsActivity and
7:08
rename it to some other activity, notice
that it changes here and my tag too.
7:13
I don't actually want to rename this,
though, so let's hit Escape to cancel.
7:21
Now, notice that our log
constant is still gray,
7:26
because we haven't updated it
down here in our debug log call.
7:29
So instead of this hardcoded string,
let's use our tag constant.
7:34
Then let's run the app to
make sure it still works.
7:42
And there we go, a new log message with
the same FunFactsActivity tag as before.
7:50
Logging can be incredibly helpful for
troubleshooting problems with our apps.
7:56
It's also a great way to make sure
everything is running like we
8:01
expect it to.
8:04
Especially when whatever we're
testing isn't visible on the screen.
8:05