Get Your Feet Wet with Android Development Tools

Last week, Personal Capital released its Android app to the Google Play store. You can read more about it here. Developing quality apps that perform well requires more than just writing code. The Android SDK comes with a number of excellent tools for debugging and testing apps. While simple to use, they can expose some of the harder-to-find bugs and reveal opportunities for improving your code. Here are some highlights of the things we get lots of mileage from:

Eclipse

While not specifically an Android tool, Eclipse is a valuable one nonetheless. Android apps can be run with the standard Java debugger just like any Java project, and Eclipse’s debugger is no slouch with conditional breakpoints, exception breakpoints, drop to frame, and other neat features. Most of the SDK tools integrate into Eclipse as well, so all of your tools are in one place.

Logcat

Logs are especially useful when trying to reproduce a bug, both to give you a starting point for your investigation and to confirm that you’ve accurately reproduced an issue. Even when you’re not looking for anything specific there, watching the device log can be surprisingly instructive.

Reading the Logcat can be done with the Android Device Monitor tool in the Android SDK. You can start it from a command line by running <android_sdk_path>/tools/monitor. Alternatively, you can open the Eclipse perspective called DDMS to access the same features.

Select any connected device or running emulator from the Devices tab, then switch over to the Logcat tab to see the logs. There will probably be lots of messages flying by, so put part of your application’s package name in the filter bar to increase your signal-to-noise ratio. You can also filter out messages below a certain priority level by selecting from the dropdown menu. The save button in the upper right of the pane will export selected lines to a file.

Logcat with filtered messages

Logcat with filtered messages

Suppose you get a crash while running your app and you aren’t connected to a computer, or you don’t have Device Monitor running. Is there any way to retrieve those logs? Indeed there is: in your <android_sdk_path>/platform-tools/ directory is a tool called ADB. Connect your device and run the following command to dump all the log messages to a file:

$ adb logcat -d > log.txt

Of course those log messages won’t last forever, so grab them before they get pushed out of the log buffer.

Screen Capture

Yo dawg, we heard you like screenshots…

Yo dawg, we heard you like screenshots…

In case your device doesn’t have screenshot capabilities, or to spare yourself having to transfer screenshots form your device to your computer, Android Device Monitor has a screen capture utility built in.

In Device Monitor (or DDMS in Eclipse), select a device or emulator from the Devices tab and click the icon near the top. A window opens up showing a preview of the device screen, which you can save as a PNG. The preview does not update when you interact with the device; you have to click the Refresh button to reload the preview.

Hierarchy Viewer

Speaking of UI, occasionally you get some layout params wrong and a View (or, you know, half the View tree) mysteriously vanishes into nothingness. The last time this happened to me, it was in a part of the view hierarchy I certainly didn’t expect, and I never would have found it without this tool.

Hierarchy Viewer is included in Device Monitor, or you can open it as a perspective in Eclipse. In the Windows tab, select the window corresponding to the application you are debugging (the active window will be bolded). Once the View tree loads, clicking an individual View will show you a preview of its appearance on screen. Where that View is positioned on screen can be seen in the Layout View tab, and you can inspect various attributes in the View Properties tab.

A View tree in Hierarchy Viewer

If you’ve seen our app, can you guess which screen this is?

If a View that should be on screen is not visible and you do find it in the View tree, check the layout and measurement properties and see if its width or height is inadvertently being set to zero. This can happen for a number of reasons, some potentially obscure, like using the wrong anchor in a RelativeLayout or not setting the alignWithParentIfMissing attribute.

TraceView

TraceView is a profiling tool to help you determine areas of code that are performance bottlenecks. It can also alert you to operations on the UI thread that should be moved elsewhere. Due to technical limitations and to the latency it adds, method tracing is not something you would leave running for the duration of testing. Instead, you should start tracing just before performing some action of interest, and then stop tracing just after.

The easiest way to use TraceView is through Android Device Monitor (or DDMS in Eclipse). While your app is running, select the process in the Devices tab. Click the  icon at the top of the pane to start tracing, interact with the app for a bit, and click the icon again to stop tracing. TraceView will open the trace data for you to inspect.

TraceView at a glance

TraceView at a glance

The top pane will show a timeline of thread activity, while the bottom shows profile information for all method calls that took place. In the timeline, you can zoom in and out with your mouse scroll wheel, or click and drag a horizontal region to zoom in. Pay particular attention to the Main (or UI) thread; any unusually long gaps in the timeline could indicate something making your app unresponsive.

The bottom pane shows all the method calls and reports data regarding execution time (real time or percent of total), both exclusive and inclusive. Exclusive time is only the time the method was executing instructions; inclusive time also counts calls to other methods. You can drill down through method calls and sort them by any column. Sorting by exclusive real time, for instance, could help find particular methods that are taking the most time to process.

Drilling down in method profile

Drilling down in method profile

Wrap Up

Sometimes the simplest thing—screenshots, exported logs, etc.—vastly improves our ability to turn around a bug posted to our issue tracker. Other times, you need comprehensive measuring tools to pinpoint a critical flaw. Whatever platform you are building for, tools like those packaged in the Android SDK are invaluable. Even for non-developers, these tools can be leveraged to help understand the behavior of the app and provide better feedback for developers.

If you are already using these tools in your development process, great! Consider introducing all of your engineers to them as well. Empower others to explore, get their hands dirty, and perhaps engage in the feedback part of your development loop; they’ll probably appreciate the knowledge you’ve shared. And don’t count out your client base either—believe it or not, even some of our end users send us logcat output on occasion.

November Architecture Update

 

We have a simple engineering philosophy: our user experience has to be the absolute best, and our calculations 100% accurate, while everything else just needs to be “good enough” for “now.” This is why we can release high quality products early and fast. Behind the scenes, however, we are continuously refactoring our code base as “good enough” changes over time.

Our November release went live with a new HTML5 dashboard and account detail screens, as well as many interaction, performance, and refactoring upgrades for the web application as a whole. Here is how we did it:

Distributing Static Content We now serve all web application assets packaged and minified from Amazon’s CloudFront. This helps us serve our static content (js/css/media) to end users with low latency and high data transfer speeds. It also helps us separate the concerns of static content (front end) and server webpages (back end), which reference the static content. This gives us the ability to change static content at any time without having to re-deploy our entire application. Faster iterations. Better products. You can read more about it here.

Responsive Design One of the biggest variables in web interface engineering is client screen.  Our new HTML5 dashboard uses CSS media queries to offer a responsive design, rendering a single column for common resolutions, and two columns for wide resolutions. This wider resolution provides an efficient use of space and access to interface elements without the need to scroll. This gets us one step closer to providing that “financial picture at a glance” goal.

Financial Visualizations These are the interface embellishments that bring our web application to life.  We chose Raphael.js, a vector drawing API which makes programming SVG with javascript a pleasure.  We took this customized approach, rather than an out-of-the-box charting solution, because at Personal Capital, the defaults just aren’t good enough. We work very hard to design the most effective charts we can, and even harder to make sure that when we release them they live up to customer expectations. New visualizations featuring custom algorithms can be seen on the new dashboard and account management screens.

Datagrids This is the bread to our visualization butter. In one month, we switched over to a custom HTML5 implementation (from our previous Flex-based implementation) improving not just performance, but the set of features as well. Searching, sorting, and editing are all upgraded and we added a couple new features like multi-row editing and tag sorting. Angular.js is the technology that allowed us to achieve these gains in such a short period of time. Angular makes re-rendering based on live updates a non-issue, as the markup itself clearly and concisely documents what it will express as the data changes.

Polymorphic Backbone Views: Backbone framework has proven to be both scalable and fast. On the scalability side, the ability to extend and polymorph Backbone’s views helped tremendously in simplifying the code for Account Details. On the performance side, we were able to greatly reduce the number of unnecessary HTML redraws by writing custom functions that would update specific DOM elements.

That’s it for the new web app updates this month. Stay tuned for the next round of web app improvements in January!