Getting The Best Out Of Eclipse For Android Development
Getting into Android development can be quite a challenge, particularly if you’re new to Java or Eclipse or both. Whatever your past experience, you might feel tempted to start working away without checking that you’re making the best use of the IDE. In this article, we’ll go over a few tips, tools and resources that can maximize Eclipse’s usefulness and hopefully save you a few headaches. You might of course already be familiar with some (or all) of them and even be aware of others that we haven’t covered. If so, please do feel free to mention them.
I’ve used Eclipse for Java development on and off for a few years, having recently started learning Android casually. I’m surprised at the lack of easily digestible material online about basic aspects of Android development, such as the topic of this article. I’ve found some useful information out there in disparate locations that are not particularly easy to come across. Most of the online content is still in the official Android Developer Guide, but it has to be said that it is pretty limited in practical material.
Further Reading on SmashingMag:
- Get Started Developing for Android with Eclipse
- Get Started Developing For Android With Eclipse, Reloaded
- Four Ways To Build A Mobile Application: Native Android
The aim here, then, is to provide a concise overview of Android development tools specifically in Eclipse. If you’ve already started developing for Android, you will almost certainly have come across some of them, but a few might be new to you, especially if you’re learning Android casually or part time. If you’re approaching Android as a Java developer and are already accustomed to Eclipse, you’ll likely grasp this material well.
Get To Know Eclipse
Going over some features of Eclipse itself that would be useful for developing Android projects would be worthwhile. If you already know your way around Eclipse, you can probably skip these first few sections, because they’re really aimed at people who are learning to use the IDE purely for Android development. Later sections include tips on using Eclipse specifically for Android, so you might find a bit or two in there that you haven’t explored yet.
The Eclipse IDE, with the “Hello Android” project open.
Eclipse has a huge amount of flexibility for creating a working environment for your development projects. Many display options, tools and shortcuts in Eclipse enable you to interact with your projects in a way that will make sense to you directly. Having been an Eclipse user for a reasonable amount of time now, I still discover features in it that I had no idea existed and that could have saved me a lot of hassle in past projects.
The Eclipse user interface provides a variety of ways to view the elements in any project. When you open Eclipse, depending on which “perspective” is open, you will typically see the screen divided into a number of distinct sections. In addition to the code editing area, you should see various aspects of the project represented in particular “views.”
A perspective in Eclipse is a group of views arranged to present a project in a particular way. If you open the “Window” menu, then select “Open Perspective,” you will usually see at least two options: “Debug” and “Java.” The Java perspective will likely form the basis of your Android development process; but for debugging, there is an Android-specific perspective called DDMS. Once you have set a perspective, you can still make alterations to the visible views, as well as adjust the layout by dragging the view areas around to suit yourself.
In general, when developing Android projects, some variation of the Java perspective is likely to be open, with the option of a few additional views, such as “LogCat,” where you can send and read the runtime output of your app. The Dalvik Debug Monitor Server (DDMS) perspective will likely be useful when the time comes to debug your Android applications. The tools in this perspective come as part of the Android software development kit (SDK), with Eclipse integration courtesy of the Android Developer Tools (ADT) plugin. The DDMS perspective provides a wide range of debugging tools, which we’ll cover in brief later on.
Make Use Of Views
By default, the Java perspective contains the main area to edit code and a handful of views with varying levels of usefulness for Android projects:
- Package Explorer. This provides a hierarchical way to explore your projects, allowing you to browse and control the various elements in them through a directory structure.
- Outline. Displays an interactive representation of the file currently open in the editor, arranged as logical code units, which can be useful for quickly jumping to a particular point in a big file.
- Problems. Lists errors and warnings generated at the system level during the development process.
- Javadoc. Useful if you’re creating your own documentation using Javadoc or using other language resources that have this documentation.
- Declaration. Particularly useful if your Android projects have a lot of classes and methods. You can click on a variable or method in your code to see its outline here, and then click within the view to jump to the point where the item is declared.
You can open new views in Eclipse by selecting “Show View” in the Window menu and clicking from there. Many of the available views won’t likely be of any use to your Android project, but it is worth experimenting with them. If you open a view and decide that you don’t want to display it after all, simply close it. Adjust or move open views to different locations in Eclipse by clicking and dragging their edges or the tabbed areas at the top.
Java Views Relevant to Android Development
The ADT plugin for Eclipse includes a variety of resources for Android development within the IDE, some of which we’ll cover in the sections below. Eclipse has additional views for general Java programming, some of which naturally have a greater potential for usefulness in Android development but don’t appear by default in the Java perspective. In my experience, views that are useful for Android development include “Call Hierarchy,” “Type Hierarchy” and “Tasks.”
The Call Hierarchy view displays an interactive list of the calls for any particular method, class or variable, so you can keep track of where your code excerpts are being called from. This is particularly useful if you’re altering existing code and need a sense of what will be affected.
The Call Hierarchy view for a method in one of my projects.
The Type Hierarchy view is relevant to Java projects that involve inheritance, which basically means that it’s relevant to all Android projects. Whenever you have a class that extends another class, this is inheritance and, thus, an instance when the Type Hierarchy view can be informative. If you’re not yet familiar with inheritance in Java, taking the time to at least read up on the basics is well worth it, because the technique is key to Android programming.
The Type Hierarchy for a user interface element in an Android project.
The Tasks view is one I personally find helpful, but it really depends on how you choose to organize your projects. Think of the Tasks view as an interactive to-do list. For example, to add a task when you haven’t quite finished a particular bit of implementation but need to address something else right away, write a code comment, then right-click in the border area just to the left of the editor section, choose “Add Task,” and set your options from there. Once tasks are in a project, you can read them in the Tasks view, jumping to an individual task in your code by selecting it here. Tasks are also highlighted in the right-hand border of the editor.
The Tasks view, with a random comment in the “Hello Android” project.
Android Debugging Views
The DDMS perspective contains several views for Android development and debugging. When you first open the perspective, you might feel a little overwhelmed, particularly because the views are all presented side by side in a rather convoluted arrangement. Chances are that once you learn the purpose of one, you’ll decide whether it’s relevant to your project; for a basic project, many of them will not be.
If you feel that closing some views would make the interface an easier environment to work in, then go ahead and close them; you can always open them again later. Starting simple is sometimes best, and then adding elements over time as they become relevant. In the early stages, your Android project is not likely to be complex anyway.
Let’s go through each DDMS view in Eclipse, with a brief note on its purpose and use. The information is tailored to each view and so is pretty varied, but includes device, memory and process management.
The Devices view provides an overview of your running AVD emulators together with processes in operation, and it is the starting point for exploring your projects for the purpose of debugging. This view presents shortcuts to some debugging operations, so you can select your app’s processes from here to see the other debugging operations in action. In most cases, you can view information in the other DDMS views by selecting a running process in the Devices view while your app is running in an emulator, then using the buttons at the top of the view to capture debugging information. When you do this, you’ll see some of the other views being populated with data.
The Devices view, with a process selected for debugging.
The Allocation Tracker view is particularly useful for apps that have significant demands on performance. This view provides insight into how the Dalvik Garbage Collector is managing memory for your app. If you’re not familiar with garbage collection in Java, you might want to read up on it, as well as familiarize yourself with basic principles of efficiency in Java programming, such as variable scope.
The Allocation Tracker view in the DDMS perspective.
The Emulator Control view enables you to emulate specific network contexts when testing your apps, allowing you to see how they function with varying constraints on speed, latency and network connectivity. A vital tool if your app depends on such external connections.
The Emulator Control view with telephony settings.
The File Explorer view enables you to access and control the device’s file system (not the file system in your application’s structure as with the Package Explorer view). Using this, you can copy files to and from the device’s storage system; for example, in the case of an app storing data on the user’s SD card.
Looking at the SD card directory on a virtual device using the File Explorer view.
The Heap view is another tool for analyzing and improving memory management in your app. You can manually control the Garbage Collector from this view. If you are unclear on how the constructs of your Java code relate to heap memory, this is another area you might want to read up on.
The Heap view for a running app.
The Threads view enables you to access information about the threads running in your application. If you are unfamiliar with the concept of threads, then this view won’t likely be of use to you. Typically, an Android application runs in a single process on a device, but if you implement a deeper level of control over your app’s processing at the level of threads, then this view will be relevant.
The Threads view for a particular running process.
The LogCat view is useful for most Android apps, regardless of their complexity. A variety of messages are automatically outputted here when you run your app, but you can optionally use the view as your own custom log. You can create log messages in various categories, including “Debug,” “Info,” “Warning,” “Error” and “Verbose,” which is typically used for low-priority information such as development trace statements. In the LogCat view, you can then filter the messages in order to quickly scroll to those you’re interested in. The messages are also color-coded, making them a little easier to absorb.
The LogCat view as a virtual Android device starts up.
A DDMS perspective view can optionally be added individually to the Java perspective if you find it useful for development as well as debugging. Eclipse is designed to enable you to interact with the project’s elements any way you like, so don’t be afraid to experiment with the interface.
Exploit The Design Tools
The design tools in the ADT have undergone major improvements in recent releases, so if you’ve been disappointed by them in the past and perhaps opted for other tools to design your Android apps, having another look at them now is well worth it.
In the Graphical Layout view, you can view your designs with various settings for device software, hardware as well as orientation. The current version generally gives a greatly improved level of control over widgets, views and rendering than most previous versions. You can manage user-interface elements here using the graphical interface, rather than having to implement every aspect of your design in XML code.
The graphical view of an app’s XML layout.
Design and Graphical Utilities
The ADT plugin update of June 2011 introduced a variety of visual refactoring utilities. While your XML layout files are open in the editor, you can browse the options in Eclipse’s Refactoring menu for Android, choosing from various labor-saving tools such as “Extract Style,” which provides a shorthand method of copying style attributes for reuse.
The Resource Explorer is a handy interactive way to explore your application’s resources without the hassle of searching the file structure in the “res” folder via the Package Explorer. Although not exclusively for design purposes, the tool is useful for checking what design resources are in your application’s structure. Depending on the app, your Resources directory might also contain menu, array, string and value items.
The Resources Explorer showing the Resources directory for an app.
On the subject of resources, the Resources interface for any XML files in your app enables you to manage such data graphically, if you prefer not to handle the XML code manually. This can be an effective way to manage both elements and attributes for your application’s XML data.
A graphical view of the XML file for arrays in an app.
Various visual interaction tools for XML resources have gradually been added and improved in the ADT plugin. For example, the Manifest file can also be viewed graphically when you want to control the tags in it, including “Permissions,” “Application” and “Instrumentation.”
An application’s Manifest file, presented graphically.
Set Your Android Preferences
The “Eclipse Window” menu provides access to the Preferences settings for the environment as a whole, with a dedicated section for Android. You may have used this when you first installed the SDK but might not have been in there since then. It’s worth having a look through the options and experimenting with them to create the environment you want.
In the Android section, the “Build” settings include your saved edits to the project’s files, and they also point Eclipse to your keystore for signing the application. The LogCat section lets you set properties for appearance and behavior in the LogCat view. Other options include choosing properties for the DDMS, the code editors and the launch process for the emulator.
Use The Android Run Configuration Options
When you launch your Android project using the Run Configurations menu, you can choose from a range of additional options to suit the functionality of your app. With your Android project selected, choose the “Target” tab to see these options. The first section covers the more general launch parameters for the emulator, including control over speed and latency on the device. This feature is useful if your app depends on a network connection and you want to see how it functions with limited connectivity.
Emulator Command-Line Options
The “Target” tab also allows you to enter command-line options for the emulator that launches your app. Using these, you can tailor the appearance, properties and behavior of the emulator as it launches your app. A lot of options are here for various aspects of the device, including the following properties:
- UI. Includes scaling the display window and setting the DPI.
- Disk image. Includes the device’s SD card and cache memory.
- Media. Covers audio and radio properties.
- Debugging. Enables and disables specific debug tags.
- Network. In addition to network speed and latency, you can specify DNS and proxy servers.
- System. Includes slowing down the device CPU and setting the time zone.
For a full list, see the Developer Guide.
Choose Useful AVD Configurations
When you create virtual devices in Eclipse using the Android SDK and AVD Manager, through the “Window” menu you can choose various settings, including API versions and hardware configurations, such as the size of the SD card and screen, plus optional hardware components. The sheer range of options can leave you wondering where to start, but the feature at least gives you some idea of how your apps will look and function on various devices.
Entering the details for a new AVD.
To create a virtual device, select “New,” enter a name and choose “Options.” You can edit your devices later if necessary. To start an AVD running, select it in the SDK and AVD Manager and click “Start.”
Choosing from a variety of AVDs to start running.
Some developers prefer configuration options that match the range of Android devices currently in use, which obviously vary widely, with multiple phone sizes and types, not to mention tablets. There is no dedicated resource for finding this data, but a number of websites list these configuration details periodically, so you can do a quick Web search when testing an app for release to find the most current information.
It must be said that there is a real limit in value to using actual device settings, because the emulator is merely a guide: it doesn’t replicate the look and feel of different devices with any authenticity. These limitations are especially pertinent when you consider the third parties involved, such as HTC’s Sense interface, which will substantially alter your application’s UI. This is why testing on actual devices is also important, but that’s another topic. The range of devices running Android will obviously continue to expand, so the feasibility of covering a significant chunk of them becomes more and more remote.
Rather than focusing on actual devices in use, another way to approach the AVD configuration settings while you’re in Eclipse (i.e. when you’re still developing rather than testing) is to simply try to cover a range of settings and to explore particular hardware and software configurations that could affect your app’s functionality. Visually speaking, it goes without saying that a relative rather than fixed design will cope better with various screen sizes.
Get And Keep Yourself Acquainted With Developer Resources
As you’re by now aware, if you weren’t already, the Android Developer Tools plugin is what allows you to develop, run, test and debug Android applications in Eclipse, together with the software development kit. Like Eclipse itself, both the SDK and ADT plugins offer many tools, many of which you could very easily remain unaware of and only a few of which we have touched on in this article.
The Android development resources undergo regular updates. You might be one of those people who are always on the ball, but if you’re anything like me, you’ll rarely find the time to keep abreast of these developments, especially if (like me) Android development is not your full-time job.
The Android Developer Guide lists the various tools in the SDK, many of which you will not need to access directly, because the ADT plugin and Eclipse will handle interaction with them. But it’s worth browsing the list fairly regularly, just to be aware of the tools available. Even if you’re only getting into Android casually, these utilities can make an enormous difference to how productive and enjoyable your app’s experience is. The Android Developers Blog is another good source to keep abreast of developments.
The ADT plugin itself comes with a wealth of features and is regularly updated. The Android SDK Guide also has a page on the plugin, outlining versions and features; again, well worth checking out regularly, because there may be significant updates. Checking for updates in Eclipse through the “Help” menu is another good habit.
Android apps are, of course, extremely varied, so the utility of any given development tool is necessarily relative. Keeping a eye on updates to resources needn’t take up much time, because in many cases the updates will be irrelevant to you. But discovering the ones that are relevant could seriously improve your Android development efforts.
Following Best Practices
If you’re interested in developing a best-practices approach to managing and documenting your apps, check out Apache Maven, which uses the project object model (POM). If you’ve already used Maven for Java development in Eclipse, the Android plugin and Integration tools will enable you to adopt the same development practices for your Android app. You can learn more about Maven on the Apache website, and you can learn about getting started with it for Android on the Sonatype website.
- “Android Development Tutorial,” Lars Vogel
- “SDK Tools,” Android Developer Guide
- “Using DDMS,” Android Developer Guide
- “ADT Plugin for Eclipse,” Android Developer Guide
- “Introduction to Android Development Using Eclipse and Android Widgets,” IBM developerWorks
- “Eclipse Shortcuts,” Lars Vogel
- “Eclipse Documentation,” Eclipse Foundation
- “Eclipse IDE Tutorial,” Lars Vogel
- “Develop Android Applications With Eclipse,” IBM developerWorks
- “Eclipse Tips and Customization,” University of Tennessee
- “Ten Tips for Android Application Development,” Zigurd Mednieks
- “Android GUI PSD Vector Kit,” Smashing Magazine
- “Designing For Android,” Dan McKenzie
- “Get Started Developing for Android with Eclipse,” Chris Blunt
- “Get Started Developing For Android With Eclipse, Reloaded,” Chris Blunt