Understanding your development tools allow you to spend less time writing boilerplate code and solving the same problems over and over again. Here are seven tools every Android developer should familiarize themselves with to make their workflow more efficient and solve new problems.
Quick Assistant Shortcut
You might be familiar with the Cmd-1 keyboard shortcut (Ctrl-1 in Windows). It allows you to pull up quick-fix when you’re in the code editor, like this:
Did you know that you can auto complete in other places as well. For example you can turn a Java string into an XML string resource:
Not only can you invoke quick assistant in the Java editor, it’s also very useful in the XML editor. This bring us to our second tip.
Extract Style from Existing XML Element
If you have visual parameters that you use often re-use, such as a header color, drop shadow, and text style, it’s best to reduce redundancy by creating a style that encapsulates these parameters. The Android tools makes this much easier to do correctly. Just place the cursor on your view element and invoke quick assistance with Cmd-1:
The extracted style will automatically be placed in the styles.xml file, and the tool will even look for and replace other instances of the same style parameters. As you can see, quick assistance brings up other nice tool features besides extracting style.
Creating New Activities using the Manifest Editor
The next time you want to create a new Activity class, don’t use the Eclipse new class wizard. Instead, go to the “Application” tab of the manifest editor. At the bottom of the page, you’ll see a list of application nodes, including existing services and activities. Click “Add…” and select Activity. The new activity node does not yet have a name, when it’s selected the Attributes for Activity pane show up to the right:
Click on the “Name*” hyperlink and it will open up a New Java Class dialog, with Activity already selected as a super class. If you always remember to create a new Activity this way, not only is it faster, but you’ll never run into the problem where the you forget to declare your activity in the manifest, or accidentally spell activity’s package name incorrectly in the manifest.
isInEditMode() Check for Custom View
After creating a custom View of ViewGroup and inserting it in your layout XML file, the Android layout preview editor often has a difficult time rendering the new View. One problem could be that your custom view uses classes or methods available only while running on the device, but not while being rendered in the editor (eg. disk and network access). In the following snippet, a custom view uses isInEditMode to determine whether or not it is being rendered inside the editor, and if so then loads test data instead of real data.
public ChartView(Context context) { super(context); if (isInEditMode()) { addFakeChartData(); } else { readChartDataFromDisk(); }}
Traceview
Traceview is a tool for profiling the performance of your application. Use it to see how long certain methods take to complete, and how often it is called (good for performance critical interactions like scrolling and activity initializing). Go to the DDMS perspective in Eclipse, select your app’s package inside the Devices view, and click the Start Method Profiling icon (it looks like three dashes with a red circle in the corner):
The profiling begins, but it’ll look like not much is happening. Test your app by interacting with it to do some performance limited task you’re interested in. Once you’re done, click on the same icon to stop profiling. Traceview should automatically pop up and show your the result of the performance profile of all the methods that executed. The structure and analysis of Traceview is more extensive than can be explained here, check out the tool documentation for more info.
Heap Monitor
If you’re running out of memory, then if app becomes slower or more unstable over time, then it’s a good idea to what objects are being created and how much space they’re taking up. Again, go to the DDMS perspective in Eclipse. This time, in the Devices view, select your activity and click on the Update Heap icon. Again, it’ll look like nothing is happening but in the background Android tools is keeping track of where memory is being allocated.
In the same perspective, go to the Heap view and click on the Cause GC button, which triggers garbage collection. The heap monitor will update with a chart of how much memory is allocated what types of objects are in the heap. As you play around with the app, objects are will be created and destroyed. The next time you press Cause GC (or when garbage collection happens naturally), the Heap tracker will update with the latest memory analysis. If you notice that your app allocates more and more memory as you open/close/rotate activities, that could mean that you have a memory leak. With a properly behaving app, the amount of memory allocated goes up and down, instead of always up. For a more extensive look at Android memory analysis, check out Patrick Dubroy’s excellent Google I/O talk.
Allocation Tracker
Using the Allocation Tracker to see how often memory allocation occurs in your app. Usually, allocating memory often is not a big deal as long as it gets garbage collected. Sometimes, however, there are paths in your code where you want to reduce all allocations, big or small. I’m referring mostly to often triggered UI-critical tasks such as scrolling, view binding, and drawing. Since these sorts of methods are invoked on the main thread and are called frequently, even simple allocations such as creating a String may affect performance. If you suspect that might be the cause, take a look at how often allocation occurs, not just how much memory gets used. In the DDMS perspective, go to the Allocation Tracker view and click Start Tracking
. Now play with your app in an area where you suspect memory allocations may cause hiccups in your UI. Click Get Allocations and the tool will tell you what type of objects have been allocated while you were using the app.
About the Author
