Appendix 2
Troubleshooting Your App

When developing an app, at some point you’re going to need to get information out of your code. As with most things in app development, we have a few ways to handle this. We can inspect our live code via the Android Studio debugger or log data to an output window. And sometimes, the quickest approach may be a pop-up on the screen.

As a software engineer, I feel obligated to say that debugging is the proper approach here. You should be using your debugger to dig into your code and not write any test-only lines of code in your application at any time.

With that said, let’s look at reality. Sometimes it’s easier to just throw a Toast message into the code to see what’s happening each time you click a button, or write something to Logcat. And let’s be honest, you’re probably going to do this anyway, so I might as well tell you how both parts work and how they can be valuable.

We’re going to walk through three ways to get information out of your code: debugging, Logcat, and Toast messages. For each approach, I’ll explain the proper way to use it and how to use it for troubleshooting issues or to view the current state in your app.

If you’re coming here from ​Binding a Player’s Name with Two-Way Binding​, we’re picking up pretty much right where we left off. If not, assume we’re in the Penny Drop app, just after the introduction of two-way binding. We’ve got a list of NewPlayer objects that we want to view, and I’m going to show you how to do that with all three approaches. You can then use similar approaches anywhere else in this book or whenever you’re developing apps.

Here’s what the app looks like at that point:

The binding code for the OnClickListener, which lives in the binding inside PickPlayersFragment, will look something like this:

We’ll be using this block for all three examples, so you’re welcome to open the Penny Drop code from the end of Chapter 3. You can find all that code on the book’s page on PragProg.com.