Tuesday, August 10, 2010

Reader Feedback: On Log Tags

Sam's Teach Yourself
Android Application Development
in 24 Hours
For the Sam's Teach Yourself Android Application Development in 24 Hours book, we received a question regarding debug tag code in Hours 9 and 10.

Log.d(DEBUG_TAG, "SHARED_PREFERENCES"); 
// (From Hour 10, Page 177)

A couple of readers have asked us: What is DEBUG_TAG? Where is it defined?

The short answer is: you need to define it! By this point in the book, we aren't displaying every line of code you need for the application to compile--only the relevant new code for that particular lesson. We assume that you've mastered certain fundamental Android skills in the previous chapters of the book. One of these skills is understanding the Log calls, such as Log.v or Log.d. which were discussed in detail in Hour 3, Page 54.  This skill is essential for debugging Android applications and is used regularly throughout the book.

Log method calls simply display diagnostic information to the Logcat logging tool, providing the developer with important information as the application executes. These calls have no impact on the actual application functionality. The calls just log string output for debugging purposes. You can include these logging calls in your applications or simply leave them out (and not provide diagnostic logging). If you want to log information using the logging calls, you will need to supply a tag string as the first parameter for each Log method. In Hour 3, we suggest that you define a logging tag for each and every Android project or class you create.

The logging tag is shown in the log output of logcat, so you can tell that the information is coming from your application, Activity, class, or method. It's that simple.
LogCat output showing all device logs. Cluttered.

You can also filter on just the tag, which shows the real power of it.
LogCat, with filter to show only the tag "GestureFunActivity"

So, when you run across a line in the book that uses such a call, we do not provide the definition of DEBUG_TAG variable. Instead, we assume you know that this is a generic logging call, and you should supply the definition of the variable somewhere in your class. For example, if you want to add logging calls to an Activity class called QuizHelpActivity, class, you should add a definition such as:
private static final String DEBUG_TAG = "QuizHelpActivity";
Or maybe you'd prefer:
private static final String DEBUG_TAG = "QuizHelpActivity Logging Info: ";
Or even something for your entire application:
private static final String DEBUG_TAG = "MyAppLogging";
Those of you who have Java experience will likely recognize that the DEBUG_TAG variable is a constant. That is to say, it has the static final qualifiers. Since the input type to the Log functions are String objects, you then know this to be a static final String. Remember that the logging tag should be descriptive for the specific application or class. In fact, it's often set to the class name, but there is no requirement to do so.

We hope this helps clear up this question. As always, feel free to email us or post a comment right here!

5 comments:

John Eric said...

Hi, I'm trying to do the first exercise in Chapter 3: Add a log tag. I've read thru the chapter several times and there are no examples of where to actually add the code. I'm clicking around eclipse like crazy, yet I can't still find a place to add code, as there are no examples in the chapter that gives me a clue. Where do you add code in eclipse to add a log tag ?

John Eric said...
This comment has been removed by a blog administrator.
normT said...

Hi, I would like to ditto what john eric says.You say that you cover logging in detail on page 54.You don't;you just brush over this topic and expect us to answer Exercise question1.I don't know where to start

Laurie Darcey said...

You define your log tag in the activity class of your choice, or at the application level. Since your application has only one activity, it makes the most sense to define it there. Page 54 does state this just below the table of log methods. It also provides a sample call once you have done so.

We do not include import statements for each method call made in the book, although we made it clear on Page 54 that this is the android.util.Log class because there are two logging classes in the Android SDK. We expect readers to look up classes in the SDK documentation if they need further instruction - a Teach Yourself in 24 Hours moves at a certain pace. The book is a companion to the SDK documentation.

You will find examples of logging used in many of the sample source code chapters.

In terms of that specific exercise, we feel we gave you ample hints. The exercise itself says: put the logging call in the onCreate() method, which is in your Activity class and we've already covered that. It then should make sense to the average Java developer that the LOG TAG would need to be somewhere in the scope of that activity as well, or it wouldn't compile.

We will consider clarifying this further in the second edition, but yes, we expect you to make such leaps of logic in the exercises. If an exercise is too difficult, consider checking this website for clarification as, in the first edition, there are a handful of exercises we do feel are too difficult based on reader feedback; however, this is not one of them.

dgun said...

The constants like "DEBUG_TAG" are defined in QuizActivity.java. Look on the CD that came with the book and then just copy it over. I have found this book to be very helpful and the reviews are much better for this book than the terrible reviews for other books on the subject. The author's comment below "a Teach Yourself in 24 Hours moves at a certain pace" is a nod and a wink to the likelihood that her material was heavily altered by goons, a.k.a. editors, in order to stuff it into the 24 hour format, thus leaving out some details she would have otherwise included. And she does state in every chapter to consult the source on the CD. In my opinion, the best way to work along with this book is to study the source code and xml files for the chapter first, and then read the chapter with the source code open in an editor for quick reference.