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