The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Now that we are starting to manipulate layouts and Java code more significantly, the odds increase that we are going to somehow do it wrong, and our app will crash.
Figure 102: A Crash Dialog on Android 4.0.3
In this chapter, we will cover a few tips on how to debug these sorts of issues.
If you see one of those “Force Close” or “Has Stopped” dialogs, the first thing you will want to do is examine the Java stack trace that is associated with this crash. These are logged to a facility known as Logcat, on your device or emulator.
To view Logcat, you have three choices:
adb logcatcommand at the command line (or something that uses
adb logcat, such as various colorizing scripts available online)
monitorfrom the command line)
There are also Logcat apps on the Play Store, such as aLogcat, that will display the contents of Logcat. However, for security and privacy reasons, on Android 4.1 and higher devices, such apps will only be able to show you their Logcat entries, not those from the system, your app, or anyone else. Hence, for development purposes, it is better to use one of the other alternatives outlined above.
The Logcat view is available at any time, from pretty much anywhere in Android Studio, by means of clicking on the Android tool window entry, usually docked at the bottom of your IDE window:
Figure 103: Minimized Tool Windows in Android Studio, Showing Logcat Tool
Tapping on that will bring up some Android-specific logs in an “Android DDMS” tool window, with a tab for “Devices | logcat”:
Figure 104: Android DDMS Tool Window, Showing Logcat
Logcat will show your stack traces, diagnostic information from the operating
system, and anything you wish to include via calls to static methods on the
android.util.Log class. For example,
Log.e() will log a message at error
severity, causing it to be displayed in red.
If you want to send something from Logcat to somebody else, such as via an issue tracker, just highlight the text and copy it to the clipboard, as you would with any text editor.
The “trash can” icon atop the tool strip on the left is the “clear log” tool. Clicking it will appear to clear Logcat. It definitely clears your Logcat view, so you will only see messages logged after you cleared it. Note, though, that this does not actually clear the logs from the device or emulator.
In addition, you can:
If you crash, the stack trace might suggest that there is a problem tied to
your resources. One common flavor of this is a
ClassCastException when you
findViewById(). For example, you might call
(Button)findViewById(R.id.button), yet get a
ClassCastException: android.widget.LinearLayout as a result, indicating
that while you thought your
findViewById() call would return a
it really returned a
Often times, this is not your fault. Sometimes, the
R values get out of sync
with pre-compiled classes from previous builds. This most often occurs just
after you change your mix of resources (e.g., add a new layout).
To resolve this, you need to clean your project. To do this, in Android Studio, choose “Build > Clean Project” from the main menu.
So, if you get a strange crash that seems like it might be related to resources, clean your project. If the problem goes away, you are set — if the problem persists, you will need to do a bit more debugging.
The preview of this section is off trying to sweet-talk the Khaleesi into providing us with a dragon.