The Android Log

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