Tag: debug

Troubleshooting multi-threading problems related to Android’s onResume()

This post is a continuation of a previous post I wrote about best practices for using onResume(). I found a particularly testy bug that caused me 2 hours of pain time to track down. The tricky part was it would only show up when there was no debugger attached. Right away this told me it was a threading problem. I suspected that the debugger slowed things down just enough that all the threads could complete in the expected order, but not the actual order that occurred when running the device in stand-alone mode.

The test case. This is actually a very common workflow, and perhaps so common that we just don’t think about it much:

  • Cold start the application without a debugger attached. By cold start I mean that the app was in a completely stopped, non-cached state.
  • Minimize the app like you are going to do some other task.
  • Open the app again to ensure that onResume() gets called.

Now, fortunately I already had good error handling built-in. I kept seeing in logcat and a toast message that a java.lang.NullPointerException was occuring. What happened next was troubleshooting a multi-threaded app without the benefit of a debugger. Not fun. I knew I had to do it because of the visibility of the use case. I couldn’t let this one go.

How to narrow down the problem. The pattern I used to hunt down the bug was to wrap each line of code or code block with Log messages like this.

Log.d("Test","Test1");
setLocationListener(true, true);
Log.d("Test","Test2");

Then I used the following methodology starting inside the method were the NullPointerException was occurring. I did this step-by-step, app rebuild by app rebuild, through the next 250 lines of related code:

  1. Click debug in Eclipse to build the new version of the app that included any new logging code as shown above, and load it on the device.
  2. Wait until the application was running, then shutdown the debug session through Eclipse.
  3. Restart the app on device. Note: debugger was shutdown so it wouldn’t re-attach.
  4. Watch the messages in Logcat.
  5. If I saw one message , such as Test1, followed by the NullPointerException with no test message after it, then I knew it was the offending code block, method or property. If it was a method, then I followed the same pattern through the individual lines of code inside that method. This looked very much like you would do with step-thru debugging, except this was done manually. Ugh.

What caused the problem? As time went on, and I was surprised that I had to keep going and going deeper in the code, I became very curious.  It turned out to be a multi-threading bug in a third party library that wasn’t fully initialized even though it had a method to check if initialization was complete. The boolean state property was plainly wrong. This one portion of the library wasn’t taken into account when declaring initialization was complete. And I was trying to access a property that wasn’t initialized. Oops…now that’s a bug.

The workaround? To work around the problem  I simply wrapped the offending property in a try/catch block. Then using the pattern I described in the previous blog post I was able to keep running verification checks until this property was either correctly initialized, or fail after a certain number of attempts. This isn’t 100% ideal, yet it let me keep going forward with the project until the vendor fixes the bug.

Lessons Learned. I’ve done kernel level debugging on Windows applications, but I really didn’t feel like learning how to do it with one or multiple Android devices. I was determined to try and narrow down the bug using the rather primitive tools at hand. The good news is it only took two hours. For me, it reaffirmed my own practice of implementing good error handling because I knew immediately where to start looking. I had multiple libraries and several thousand lines of code to work with. And, as I’ve seen before there are some bugs in Android that simply fail with little meaningful information. By doubling down and taking it step-by-step I was able to mitigate a very visible bug.

10 Best Practices for Developing JavaScript Widgets

I’d like to offer updated, practical recommendations to developers who are building widgets. Widgets are essentially a mini-application within your web app that provides specific functionality, for example the map switcher widget included as a screenshot in this post. In May 2010, the OpenAjax Alliance published the Metadata 1.0 specification to define a set of standards for widgets. This was a great start, however in the last two years there have been some significant advancements which render some potions of this spec aged and in need of updating. And, since I’ve run across quite a few widgets in the last several years that seem to consistently have certain problems, this post attempts to provide guidelines for anyone looking to make their widgets significantly more re-usable.

State and Display Properties. All widgets need to make their State accessible via public setters and getters which, at a minimum, includes visible/not visible. Getter properties simply offer developers a way to determine whether the widget is visible or not. So, I add that there also needs to be a way to set the State as visible/not visible. Advanced widgets also need control over inline and block positioning.

Persistence. Widgets need the ability to maintain certain aspects of State and persist between app or browser restarts. For example, primary text fields should be persistent after an end user restarts the browser. The corollary is that there also needs to be functionality to clear persisted data.

View Transitions.Widgets must also persist fully and correctly through view transitions. This has to do with mobile web apps designed to mimic native app functionality that occurs when a user switches between different views within the same app.

Auto-resize. Widgets must auto-resize to their container. The sheer popularity of smartphones and tablets is driving this requirement. For example, when a phone is turned on its side, a widget should automatically fill the new dimensions of the container. If your widget doesn’t auto-resize it will significant limit it’s marketability for mobile devices.

Events. Widgets must have a clearly defined life cycle that is accessible via events. At a minimum this includes when the widget is initialized, after specific actions, and upon an errors. Events need to fire when they are expected to and not before or after. This is especially important for mobile apps where event bubbling, or even CPU/Memory overload, may cause delays in the callback. A properly wired event will fire as expected 100% of the time.

Namespace. Widgets must use name space separation so as to not cause variable and function conflicts. For example, don’t name your widget Class “AppWidget”, a best practice alternative is to call it “com.mycompany.AppWidget”. This also includes protecting your global variables to reduce “leakage” outside of your Classes.

Public Properties and Methods. Only properties and methods that are internal should be kept private. All other properties need to be public.

Documentation and Code Comments. This is an age-old problem. Here’s another way to look at it: in many cases, lack of documentation costs other developers significant lost time, effort and money. The one to two minutes a developer saves by not writing a comment could cost another developer hours, days or weeks of frustration.

Cross-platform compatibility. Clearly document which platforms the widget was tested on. If you haven’t been testing your widgets cross-platform then you need to be. If you only designed your widget for a specific browser, that’s okay as long as it’s documented. At a minimum, truly cross-platform widgets will have been tested on the latest production versions of Firefox, Chrome, iPad/iPhone (Safari), Android (native) and IE.

Debugging. If your widget uses an obfuscated JavaScript library, consider providing either a debug version, or a version that includes public (debuggable) methods alongside the private and obfuscated ones.

Debugging Web Apps on Android’s Mobile Browser – Part 2

In addition to the suggestions listed in Part 1, I forgot to mention one more tool. There is a lesser known browser that can be quite handy for debugging: Firefox mobile. This relatively unknown sibling of the full-blown desktop browser actually has a fairly nice, built in debugger. The one major caveat is that it doesn’t work as well as the native browser for HTML5, CSS3 and some JavaScript, but it may be just the tool you need for some quick debugging, on-the-fly. Besides it fits in your pocket along with your other mobile apps, and you don’t need Logcat.

Step 1 – place your finger in the middle of the screen and drag it to the left. Click the gears icon at the bottom right of the screen.

Step 2 – In the upper right hand corner of the next screen, click the bug icon

Step 3 – Scroll down the datagrid to view errors.