Problems with your apps will not always be crashes. In some cases, they will be misbehaviors. For example, suppose that every time you pressed the NEXT button, nothing happened. That would be a noncrashing, misbehaving bug.

In MainActivity.kt, make a change to the nextButton listener to comment out the code that increments the question index.

override fun onCreate(savedInstanceState: Bundle?) {
    ...
    nextButton.setOnClickListener {
        // quizViewModel.moveToNext()
        updateQuestion()
    }
    ...
}

Run GeoQuiz and press the NEXT button. You should see no effect.

This bug is trickier than the last bug. It is not throwing an exception, so fixing the bug is not a simple matter of making the exception go away. On top of that, this misbehavior could be caused in two different ways: The index might not be changed, or updateQuestion() might not be called.

You know what caused this bug, because you just introduced it intentionally. But if this type of bug popped up on its own and you had no idea what was causing the problem, you would need to track down the culprit. In the next few sections, you will see two ways to do this: diagnostic logging of a stack trace and using the debugger to set a breakpoint.

In MainActivity, add a log statement to updateQuestion().

private fun updateQuestion() {
    Log.d(TAG, "Updating question text", Exception())
    val questionTextResId = quizViewModel.currentQuestionText
    questionTextView.setText(questionTextResId)
}

The Log.d(String, String, Throwable) version of Log.d logs the entire stack trace, like the UninitializedPropertyAccessException you saw earlier. The stack trace will tell you where the call to updateQuestion() was made.

The exception that you pass to Log.d(String, String, Throwable) does not have to be a thrown exception that you caught. You can create a brand new Exception and pass it to the function without ever throwing it, and you will get a report of where the exception was created.

Run GeoQuiz, press the NEXT button, and then check the output in Logcat (Figure 5.3).

Figure 5.3  The results

The top line in the stack trace is the line where you logged out the Exception. A few lines after that you can see where updateQuestion() was called from within your onClick(View) implementation. Click the link on this line, and you will be taken to where you commented out the line to increment your question index. But do not get rid of the bug; you are going to use the debugger to find it again in a moment.

Logging out stack traces is a powerful tool, but it is also a verbose one. Leave a bunch of these hanging around, and soon Logcat will be an unmanageable mess. Also, a competitor might steal your ideas by reading your stack traces to understand what your code is doing.

On the other hand, sometimes a stack trace showing what your code does is exactly what you need. If you are seeking help with a problem at stackoverflow.com or forums.bignerdranch.com, it often helps to include a stack trace. You can copy and paste lines directly from Logcat.

Before continuing, delete the log statement in MainActivity.kt.

private fun updateQuestion() {
    Log.d(TAG, "Updating question text", Exception())
    val questionTextResId = quizViewModel.currentQuestionText
    questionTextView.setText(questionTextResId)
}

Now you will use the debugger that comes with Android Studio to track down the same bug. You will set a breakpoint on updateQuestion() to see whether it was called. A breakpoint pauses execution before the line executes and allows you to examine line by line what happens next.

In MainActivity.kt, return to the updateQuestion() function. Next to the first line of this function, click the gray gutter area in the lefthand margin. You should now see a red circle in the left gutter like the one shown in Figure 5.4. This is a breakpoint. You can also toggle a breakpoint on and off by placing the cursor on the desired line and pressing Command-F8 (Ctrl-F8).

Figure 5.4  A breakpoint

To engage the debugger and trigger your breakpoint, you need to debug your app instead of running it. To debug your app, click the Debug 'app' button (Figure 5.5). You can also navigate to Run → Debug 'app' in the menu bar. Your device will report that it is waiting for the debugger to attach, and then it will proceed normally.

Figure 5.5  Debug app buttons

In some circumstances, you may want to debug a running app without relaunching it. You can attach the debugger to a running application by clicking the Attach Debugger to Android Process button shown in Figure 5.5 or by navigating to Run → Attach to process.... Choose your app’s process on the dialog that appears and click OK, and the debugger will attach. Note that breakpoints are only active when the debugger is attached, so any breakpoints that are hit before you attach the debugger will be ignored.

You want to debug GeoQuiz from the start of your code, which is why you used the Debug 'app' option. Shortly after your app is up and running with the debugger attached, it will pause. Firing up GeoQuiz called MainActivity.onCreate(Bundle?), which called updateQuestion(), which hit your breakpoint. (If you had attached the debugger to the process after it had started, then the app likely would not pause, because MainActivity.onCreate(Bundle?) would have executed before you could attach the debugger.)

In Figure 5.6, you can see that MainActivity.kt is now open in the editor tool window and that the line with the breakpoint where execution has paused is highlighted. The debug tool window at the bottom of the screen is now visible. It contains the Frames and Variables views. (If the debug tool window did not open automatically, you can open it by clicking Debug at the bottom of the Android Studio window.)

Figure 5.6  Stop right there!

You can use the arrow buttons at the top of the debug tool window (Figure 5.7) to step through your program. You can use the Evaluate Expression button to execute simple Kotlin statements on demand during debugging, which is a powerful tool.

Figure 5.7  Debug tool window controls

You can see from the stack trace on the left that updateQuestion() has been called from inside onCreate(Bundle?). But you are interested in investigating the NEXT button’s behavior, so click the Resume Program button to continue execution. Then press the NEXT button in GeoQuiz to see if your breakpoint is hit and execution is stopped. (It should be.)

Now that you are stopped at an interesting point of execution, you can take a look around. The Variables view allows you to examine the values of the objects in your program. At the top, you should see the value this (the MainActivity instance itself).

Expand the this variable to see all the variables declared in MainActivity, in MainActivity’s superclass (Activity), in Activity’s superclass, in its super-superclass, and so on. For now, focus on the variables that you created.

You are only interested in one value: quizViewModel.currentIndex. Scroll down in the variables view until you see quizViewModel. Expand quizViewModel and look for currentIndex (Figure 5.8).

Figure 5.8  Inspecting variable values at runtime

You would expect currentIndex to have a value of 1. You pressed the NEXT button, which should have resulted in currentIndex being incremented from 0 to 1. However, as shown in Figure 5.8, currentIndex still has a value of 0.

Check the code in the editor tool window. The code in MainActivity.updateQuestion() simply updates the question text based the contents of QuizViewModel. There is no problem there. So where does the bug originate?

To continue your investigation, you need to step out of this function to determine what code was executed just before MainActivity.updateQuestion(). To do this, click the Step Out button.

Check the editor tool window. It has now jumped you over to your nextButton’s OnClickListener, right after updateQuestion() was called. Pretty nifty.

As you already knew, the problematic behavior is a result of quizViewModel.moveToNext() never being called (because you commented it out). You will want to fix this implementation – but before you make any changes to code, you should stop debugging your app. If you edit your code while debugging, the code running with the debugger attached will be out of date compared to what is in the editor tool window, so the debugger can show misleading information compared to the updated code.

You can stop debugging in two ways: You can stop the program, or you can simply disconnect the debugger. To stop the program, click the Stop button shown in Figure 5.7.

Now return your OnClickListener to its former glory.

override fun onCreate(savedInstanceState: Bundle?) {
    ...
    nextButton.setOnClickListener {
        // quizViewModel.moveToNext()
        updateQuestion()
    }
    ...
}

You have tried out two ways of tracking down a misbehaving line of code: stack trace logging and setting a breakpoint in the debugger. Which is better? Each has its uses, and one or the other will probably end up being your favorite.

Logging out stack traces has the advantage that you can see stack traces from multiple places in one log. The downside is that to learn something new you have to add new log statements, rebuild, deploy, and navigate through your app to see what happened.

The debugger is more convenient. If you run your app with the debugger attached (or attach the debugger to the application’s process after it has started), then you can set a breakpoint while the application is running and poke around to get information about multiple issues.