Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Writing 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.
Related Links
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Another common way to investigate
our app while it's running
0:00
is to use the Android log.
0:03
We can add calls to different log methods
that will write them to the Android's
0:05
system log.
0:09
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 the log remains,
0:17
often holding helpful information
about why the app crashed.
0:20
Let's check it out.
0:24
Let's start by logging some
information from our app.
0:26
Right now, we're showing a Toast when
FunFactsActivity is first created.
0:29
But our users don't really
care about that do they?
0:34
Let's comment out our Toast and
write a message to the log instead.
0:37
We write to the log
using the log class and
0:42
then one of its static methods,
just like we did with Toast.makeText.
0:44
These methods also don't return anything,
so
0:49
we don't need to store them in a variable.
0:51
Just like toasts, we can add these
log method calls all over the place
0:54
to log information about
how our app is running.
0:58
Let's take a quick look at
the documentation from the log class.
1:01
This is the reference for the log
class from the Android developer site.
1:05
If we take a look at the class overview,
1:08
it tells us that we generally
use one of five methods.
1:11
Log.v, d, i, w or e.
1:14
These letters stand for
different levels of logging.
1:19
E is for errors, w for warnings, i for
1:22
informational, d for
debugging, and v for verbose.
1:25
Which is used when you're
trouble shooting something and
1:30
want to spam as much information
to the log as possible.
1:33
Android does this so we can choose
the appropriate level for our log entries.
1:36
We can then filter only the log levels
we care about when viewing the log.
1:41
For example,
we may be troubleshooting an error and
1:45
only want to look at error messages.
1:48
If we log information about
the error with the log.e method,
1:50
then we can filter the log to see just
error messages and ignore everything else.
1:54
If we scroll down, we can see some more
of the constants and other methods.
1:59
Here's one called wtf which stands for
What a Terrible Failure.
2:04
That's [LAUGH] only for extreme errors
though and you'll probably never use it.
2:08
All right, let's take a look
at how to use the log methods.
2:12
They're all used the same way, so
let's take a look at the debug method.
2:16
On a new line let's type Log,
hit Enter to import it and then add dot d.
2:20
And autocomplete shows us this
method requires two parameters.
2:25
The second parameter is the data
we want to write to the log.
2:29
The first parameter is what's known
as a tag and it's also a string.
2:33
The tag is used to identify
the source of the log message.
2:38
It usually identifies the class or
activity where the log call occurs.
2:41
The log contains a lot of information
which we'll see in a moment.
2:46
Remember, the log contains log messages
from all apps and the operating system.
2:50
So supplying a tag lets us know
where the message came from.
2:55
And it also lets us filter by tag and
the log path.
2:59
For the first parameter,
3:02
let's type FunFactsActivity inside of
quotation marks to make it a string.
3:04
Then add a comma and
our log message will be,
3:11
We're logging from the onCreate() method.
3:16
Right, let's run the app
to see it in action.
3:20
Okay, but where did our log message go?
3:28
Let's take a look at the logcat.
3:31
It usually lives here at
the bottom under the code editor.
3:33
But if it's missing just go down here and
click on Logcat.
3:36
If that's missing too, click on
this little box to make it show up.
3:41
This is the Logcat and it has all of
the log data from the connected device
3:47
which we can see up here is the Emulator.
3:51
And if we look carefully,
we can even see our log message.
3:55
It's easy to find because the longest
currently only showing messages from
3:59
the selected application which
up here is set to funfacts.
4:02
But that's no fun, let's change that
from Show only select the application
4:08
to No Filters,
to see what the log really looks like.
4:13
[LAUGH] Now that we've got a ton of
log messages, let's do some filtering.
4:17
let's select the log level drop down and
pick Debug.
4:21
This filters the log to show messages that
are of debug level importance or higher.
4:25
That means by selecting Debug,
we'll not only see debug messages but
4:30
also info, warn, error and
assert messages.
4:34
Let's switch back to Verbose and
look at another method of filtering.
4:39
In this text field which for
4:45
some reason you can barely see on
my screen, we can search the log.
4:46
Let's search for our tag,
FunFactsActivity.
4:50
Looks like there's a lot of log messages
around our FunFactsActivity class.
4:55
Instead, let's search for a message.
4:59
I'll click the x to clear the search
box and then start typing our message.
5:02
And as soon as we finish the first word,
there's our message, nice.
5:07
Now let's hide this and
go back to our code.
5:11
A common Android practice is to add a
special property to our class called TAG.
5:14
Let's scroll up, and here, after we
declare our class, let's add a line, and
5:19
type private val_TAG in all caps.
5:23
And let's set it equal to
"FunFactsActivity" in quotes
5:28
just like we typed below.
5:32
And when we're at it,
let's make one more change.
5:34
What would happen if we changed
the name of our FunFactsActivity class
5:37
to some other activity?
5:40
Well, now our TAG would
be a bit misleading.
5:43
Instead of hard coding the class
name like we have here,
5:46
we can use a special method to
get the class name automatically.
5:49
Let's delete FunFactsActivity and
the quotes.
5:54
And instead, type FunFactsActivity
without the quotes and
5:57
then ::class.java.simpleName.
6:04
We picked simpleName because something
like qualified name would include
6:08
the whole package name.
6:11
Whereas simpleName leaves that out and
6:13
gives us just the class name,
FunFactsActivity.
6:16
Now you might be thinking,
we just typed FunFactsActivity again.
6:20
But this time,
since isn't inside a string,
6:24
the refactoring tools will
recognize it and make the change.
6:27
So if I refactor rename
on FunFactsActivity and
6:30
rename it to SomeOtherActivity.
6:34
Notice that it changes here and
my TAG too.
6:39
I don't actually want to rename this
though, so I'll hit Escape to cancel.
6:42
Now notice that our TAG
constant is still gray
6:48
because we haven't updated it
down here in our debug log/call.
6:50
So instead of this hard coded string,
let's use our TAG constant.
6:54
Then let's run the app to
make sure it still works.
7:00
And there we go,
7:08
a new log message with the same
FunFactsActivity TAG as we had before.
7:09
Logging can be incredibly helpful for
troubleshooting problems with our apps.
7:16
It's also a great way to make sure
everything is running like we expect it
7:20
to, especially when whatever we're testing
[LAUGH] is invisible on the screen.
7:24
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up