Showing posts with label error. Show all posts
Showing posts with label error. Show all posts

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!

Tuesday, July 28, 2009

When "Eclipse loading framework information into layout resource editor" Fails

The Android Development Plug-in for Eclipse is a great tool many Android developers rely upon. I personally use some features much more than others. For example, I rarely use the Layout Resource editor to preview layout files. Instead, I just edit the XML directly and run it in the Emulator. (I have also been known to edit HTML with notepad, that's just how I roll.)

So it came as a bit of a surprise (read: annoyance) when I tried to do just that--preview a layout file in Eclipse--the other day and it failed. Eclipse seemed to try to load the layout designer saying, "Eclipse is loading framework information and the Layout library from the SDK folder." Then it up and failed to load it. Over and over. You couldn't see the layout preview, nor the Properties pane or the Outline mode to add new controls to the layout tree.

You might be wondering why I bothered to investigate this since I could have just gone back to the XML and blown it off. Well, I needed a screenshot of the Layout preview mode for our new book. Nuff said.

At first, I thought it was just me overestimating the tool's abilities, trying to preview a layout that was too complex for the preview (this happens often when I include some of the more complex View controls in layouts). So I created a new project with its simple default layout file, and that didn't load either. So that wasn't it.

I did a quick search on the Android developer forums and a couple people were complaining on the forums about this over a year ago. One person suggested recreating your workspace. Well, that didn't work, either. I widened my search to the web and ran across a little note on Brian Klug's wiki, suggesting that the older versions of the Android plug-in JAR files might be hanging around, mucking things up. Thanks, Brian! This sent me in the right direction.

We've had a number of new revisions of Android lately. which have improved (greatly) the Android tool chain, that have had several new JAR file updates. Next, I had to find the android JAR files on my machine. First, I checked where Brian had suggested: c:\eclipse\plugins (basically, in the plugins directory of the eclipse installation path). As my luck would have it, they were not there. Instead, a quick file search for "com.android*.jar" showed that they were hiding in C:\Users\YourUserName\.eclipse\org.eclipse.platform_3.4.0_867647348\features.

With a little investigation, I found several older versions (0.8.x and 0.9.0) of the android JAR files installed with the new ones (0.9.1 is the latest for Android SDK 1.5 r3). I shut down Eclipse, deleted all the older JAR files, leaving only the 0.9.1 versions.
Specifically, I only kept these two android JAR files:
  • com.android.ide.eclipse.adt_0.9.1.v200905011822-1621
  • com.android.ide.eclipse.ddms_0.9.1.v200905011822-1621
When I relaunched Eclipse, the layout preview began to function again. Incidentally, this was on a Windows installation of the Android tools. When I checked the Mac install of Android 1.5 R3, the JAR files were hanging about in (rather than the expected /Developer/Applications/eclipse/plugins~/.eclipse), but the layout preview did load without issue.