Over the last few weeks I’ve spent time diving more into native Android development, and I thought it might be useful to share some of my impressions and thoughts on ways in which to approach learning this type of engineering.

Briefly, for some background, I originally began developing HTML websites in 1997. At that time JavaScript was an after-thought, PHP was a baby and ASP had not even hit the scene. As the sites I built started to become more sophisticated, I began to use PHP and JavaScript. In around 2000 I began using Flash. Once ActionScript 3 and Flex 2 were introduced, Flash became one of my primary development platforms, while I still heavily relied on PHP, MySQL and JavaScript.

You’ll notice that I did not mention Java in my background, so to make this move into native Android development, I had to learn a brand new language — for the first time in a while. Java shares many characteristics with ActionScript 3 and PHP5, which helps with the process of picking up the basics. And, as I run across new parts of Java that I don’t understand or need better explanations I’ve been using the book “Sam’s Teach Yourself Java 6″, which has been great as a reference to learn some of the features that are new to me in Java.

While I’ve found that many of the features in Java enable enhanced flexibility and expressiveness in code structure, many such features, of course, can take some getting used to.

One example of such a feature are inline class declarations. Java does not treat methods as first class citizens, callbacks such as the ones needed to handle mouse clicks. Thus, event handling is achieved through the implementation of interfaces outlining the functionality that a component provides for a mouse click. This separation of responsibilities is a nice design. However, Java allows you to create an implementation of an on click listener interface inline, in a function invocation, which is the style I’ve seen used in many of the code examples. I feel that this makes the code more difficult to read. I’m sure there are valid arguments for this syntax, but I just don’t care for it; I’ve grown accustomed to one class per file.

I used ADT to author my first native Android project, and this definitely helped as I’m already quite comfortable with the Eclipse IDE. The Java tooling is very robust in Eclipse. I’m looking forward to also trying IntelliJ for Java, as I’ve heard very positive things. But I just didn’t want to deal with any extra hurdles during my first attempts at developing both Java and Android. And this is one thing I’d really recommend: don’t take on more new concepts, languages and tools than you need to. If you don’t need to learn a new tool at the same time as learning a new language, that will make it much easier to learn the new language.

The Android unit testing integration is decent in ADT, although I found the need to install the APK file on the device or emulator to be a bit cumbersome. I hope to get some time before too long to try additional unit testing frameworks for JVM, circumventing the need to install on device for each test run. The refactoring and error messaging in ADT are both fairly robust (and I now have a much better understanding of what SourceMate is trying to bring to ActionScript 3 and just how many developer productivity features are missing from Flash Builder).

Thus far, I’ve enjoyed working with the Android SDK, though I still have much to learn. The most helpful resource I’ve found is a community written Android Cookbook (http://www.androidcookbook.com) that is in the process of being turned into an official O’Reilly publication. Here I was able to dive right into the ins and outs of Android including the Android lifecycle, handling events, the component set and the anatomy of a basic app.

Android was designed with mobile devices in mind and, as a result, the Android SDK contains some unique characteristics when compared to equivalent developer resources for desktop or web. As an example, Android applications do not have a ‘main’ source file from which an application is compiled. Nor does an Android ‘main’ class, or Activity, have a constructor or main() method from which the application initializes. An Android application is defined by a manifest that defines which Activity or screen/view should be presented to a user when Android receives an ‘Intent’ to open or view something. Android will then take the Intent expressed by the application and process it by displaying to the user the appropriate screen if possible, otherwise Android will open the Intent when it is able (like after a phone call is over for example). While the approach solves many issues that developers don’t usually handle in web or desktop applications, such as an application’s flow being interrupted by a phone call, this also poses new development challenges that require new approaches and solutions.

Another aspect of the SDK that I appreciate is the “R” class, which contains references to all of the resources of an application (images, strings, and layouts). The R class provides a clean and centralized way to access the different resources of an application by centralizing magic strings, view layouts, and application image assets all referenced by a unique integer value that gets assigned to them. The only catch I’ve found here occurs when you do not have the Build Automatically feature on by default, in which case, if you add resources to the project and fail to build, the files will not be accessible using the standard notation. For example, if you add a file named myMainLayout.xml in the resources/layouts folder you would access it using “R.layouts.myMainLayout”. With Build Automatically turned off the compiler will not generate an integer value for “myMainLayout” and an undefined property error will be raised by the IDE. Either ensure that you trigger a manual build, or turn on Build Automatically to prevent this potential time-suck.

Android’s handling of view definitions will be familiar to Flex developers. As with Flex, Android SDK provides two options to handling the definition of a view: by code and by markup. I have not yet seen any posts or articles on whether your app incurs a performance hit when using XML files for views, but I do not believe that there is (there is no mention of it in the Android developer documentation at http://developer.android.com/guide/topics/ui/declaring-layout.html). The ADT plugin also has a layout resource editor for you to build your views with a drag and drop interface. Unlike the Flex design view this view editor is responsive and helpful. The view editor lets you easily navigate through the properties of a UI component (which is a nice way to learn new components). Once you have a view set up in the editor, utilizing that view in the application is quite simple; the Android SDK executes all of the XML handling for you, requiring you to use a line of code in your Activity class that looks something like this:


public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.myViewLayout);
}


The last item I wish to note about the SDK is the strict feature. Enabling strict mode will actually help you identify aspects of your code that are impeding application performance. Not only do you benefit from the speed of the Java SDK for Android, but you also get guidance from the platform itself, alerting you to bottlenecks in your code. Further, the message will provide suggestions on how to remediate the infraction. This is a great timer saver to help you avoid many of the common pitfalls of starting with native Android development.

Remember: learning a language can be a challenge, especially if it’s been a while since you’ve had to pick a new one up. It makes sense that you may stumble out of the gate, hitting some hurdles. I hope that this article (and the many others that will follow it) helps you feel a bit more comfortable diving into these tools that, I believe, are poised to bring a new wave of innovative creations to interactive production, as more and more talent becomes increasingly sophisticated in how to use them.