The log class is used to print out messages and errors, which we can read in real time using LogCat. This is an example of how to log a message:

Log.i("MyActivity", "Example of an info log");

The Log class has five methods, and they are used to have a different level of priority on the logs. This allows us to filter by priority in LogCat. There are situations when we display different logs, for instance, to see the number of job offers we download in every request. If we have a crash in our app, logs of the type error are our priority at this moment, and we want to hide other logs with less priority to find the error as soon as possible.

The five priorities are (from low to high) verbose, debug, information, warning, and error. (Log.v , Log.d, Log.i, Log.w, and Log.e)

We can filter by process with the bar at the top of the logging window. We can filter by priority and by keyword, and we can create custom filters by tag, process ID, and so on.

If the logs don't appear or they are old and not refreshing, try to open the dropdown to the right, select No filters, and then select Show only selected application again. This forces the console to refresh.

To finish with logs, we will create a wrapper and use a third-party library with the idea to be able to disable all the logs in the project by just changing the value of a Boolean. To do this, we simply create a class with the same methods of the Log class that depend on this Boolean value:

public class MyLogger {
  
  static final boolean LOG = false;
  
  public static void i(String tag, String string) {
    if (LOG) android.util.Log.i(tag, string);
  }
  
  public static void e(String tag, String string) {
    if (LOG) android.util.Log.e(tag, string);
  }
  …

We need to use this wrapper every time we want to write a log—MyLogger.d() instead of Log.d(). This way, if we change the value of the Boolean LOG in the MyLogger class, it will stop all the logs in our project at the same time.

It is recommended to use the value from the BuildConfing.DEBUG variable:

static final boolean LOG = BuildConfing.DEBUG; 

This will be true if our app is in the debug mode, and it will be false when we release the app. So, we don't need to remember to turn the logs off in release mode, and there is no risk of a log appearing to the final user.

compile 'com.jakewharton.timber:timber:3.1.0'

Timber.tag("LifeCycles");
Timber.d("Activity Created");

if (BuildConfig.DEBUG) {
  Timber.plant(new Timber.DebugTree());
} else {
  Timber.plant(new CrashReportingTree());
}

/** A tree which logs important information for crash reporting. */
private static class CrashReportingTree extends Timber.Tree {
  @Override protected void log(int priority, String tag, String message, Throwable t) {
    if (priority == Log.VERBOSE || priority == Log.DEBUG) {
      return;
    }
    //Track error to parse.com
  }
}

Logs can be used to find problems while developing, but if we master the debug mode, we will find this practice much quicker.

While we are in the debug mode, we can set breakpoints in the code. With these breakpoints, we specify a line of code where we want the execution to stop to show us the values of the variables at that moment. To set a breakpoint, simply double-click on the left-hand side bar:

We set a debug point in the response of the method that gets the job offer. We can launch the debug mode from the top bar:

If we run the app in Debug mode, Android studio will pause the execution when it reaches this point:

Android Studio will automatically prompt the Debugger window, where we will be able to see the variables at the point of execution. We can see in the preceding screenshot the job offer list and navigate to see what every offer has inside.

The important features here are the green Play button to the left, which continues the execution of our app until the next breakpoint, and the red square, which exits the debug mode and continues with the execution of the app.

We also have different controls available to move to the next line, into a method, or outside the method. For instance, consider that we have a breakpoint in the first line of the following command:

MasteringAndroidDAO.getInstance().clearDB(getActivity());
MasteringAndroidDAO.getInstance().storeOffers(getActivity(), jobOffersList);

In this case, Step Over, which is the blue arrow pointing downward, will move our execution to the next line. If we click on Step Into, the blue arrow pointing to the bottom-right corner, we will get into the getInstace() method. With a combination of these controls, we can control the flow in realtime.

With the debug mode explained, we can now move on to automated tests.