Android for .NET Developers

Total votes: 1
Views: 27,099
Comments: 7
Category: .NET
Print: Print Article

Please login to rate or to leave a comment.

Published: 22 Feb 2011
By: Dino Esposito

Starting with this article, I'll discuss what you need to know to approach Android programming without any aid from your .NET expertise.

Contents [hide]
1 Introduction 2 Getting Up and Running 3 Creating the First Project 4 The Core Code 5 Summary

The Android for .NET Developers Series

Part 1 Starting with this article, I'll discuss what you need to know to approach Android programming without any aid from your .NET expertise.

Part 2 In this article, we'll go through an Android application that accepts input from the user and handles user's clicking.

Part 3 In this article, you will learn how to build the user interface.

Part 4 In this article, I'll be delving deep into menus and dialog boxes in Android for .NET, and discuss a few very common (and frequently used) types of menus and dialogs.

Part 5 In this article, Dino Esposito focuses on the options that the Android SDK offers for local storage.

Part 6 In this article, Dino Esposito shows how to build settings dialog boxes using a built-in feature of Android for .NET.

Part 7 In this article, I'll dissect the code of a realistic application - a waterpolo score manager - to show how to save and resume the status of a game using both the internal storage and SD card.

Part 8 In this article, I'll focus on the execution of common tasks from within an Android application. I'll build the skeleton of an application that takes a photo and emails to the specified address. For both tasks I'll use native Android components.

Part 9 In this article, I'll discuss how to arrange an Android view where the dominant element is the list. I'll start with a plain list of strings and then improve up to populating a listview with downloaded content arranged using a custom layout.

Part 10 In this article, I'll discuss the features and capabilities required by an Android application to talk with Twitter. In particular, I'll focus on authentication and updates.

Introduction

To call you a real mobile programmer, Windows Phone 7 (WP7) is not enough. WP7 is the youngest mobile platform and far from being the most used. Being part of a mobile project today means dealing with two major platforms - iOS and Android. For any .NET developer making the jump to WP7 is no big deal. Getting started with iOS and Android is quite another story. Of the two, Android is definitely the easiest to address and learn. Note that I'm talking about the ability of writing native applications using the native SDK. For .NET developers, in fact, the MonoTouch framework and the upcoming MonoDroid framework from Novell represent a shortest and viable path as they let you use C# and the .NET programming model. For MonoDroid, you can also stick to Visual Studio.

Starting with this article, I'll discuss what you need to know to approach Android programming without any aid from your .NET expertise. Therefore, be prepared to switch to another IDE and to use the Java language and a brand new SDK.

For the purpose of this article, I'll be using JetBrains' IntelliJ IDEA Community Edition, a free IDE for Java and Android development. I chose IntelliJ over the classic Eclipse IDE empowered with the Android plug-in and I'm using it for all of my Android development.

Getting Up and Running

There a couple of important things you need to do before you can install the IDE and proceed to your first hello- world Android application. First and foremost, you must install the latest JDK from the Oracle’s site. Next up is installing the Android SDK for Windows. Note that during the Android SDK installation process, you need to set up an Android Virtual Device (AVD) to run applications in the emulator. Also, don't be too surprised if you end up facing some problems with a USB driver (which is required for Windows but not for Mac and Linux). The USB driver is required to debug applications on the real device. Whether you face problems or not may depend on the specific device you use. However, information on how to work around problems is easy to find.

At this point, you go with the IDE of choice and if any of the previous steps completed successfully, you should be ready to create your first project. JetBrains has an excellent tutorial on how to get started with IntelliJ IDEA. You can find it here.

IntelliJ IDEA gives you an experience that is kind of comparable to that of Visual Studio. Don't get me wrong. however. I'm not saying that IntelliJ IDEA, or any other current IDE available, is really like Visual Studio. What I'm saying is that IntelliJ IDEA provides a seamless integration between the code editor and all the command line tools you need to use in order to compile the source, build the Android package and start the emulator. Figure 1 shows the window through which you can create and edit the AVD for testing your applications.

Figure 1: The AVD manager in IntelliJ IDEA for Android.

The AVD manager in IntelliJ IDEA for Android.

IntelliJ IDEA also makes it pleasantly smooth to download the package to a real device. All you need to do is connecting the device through the USB port. You must also configure the device to support USB debugging. In summary, with IntelliJ IDEA you click a button to build the project and either the emulator pops up or, if the device is connected, the application runs natively in the device.

Creating the First Project

The structure of an Android project is different from the structure of a .NET project, but it refers to nearly the same type of information, just outlined in a different manner. Figure 2 shows the user interface you get through IntelliJ.

Figure 2: A sample Android project.

A sample Android project.

The res folder contains the application resources, such as strings to be used in the user interface, images, media content, and layout information. The src folder contains the Java classes that make up the application. In addition, you see a bunch of XML files in the root directory of the project. Let's drill down into the manifest file.

When creating the project, the first point to clear is the name of the Java package. It usually comes in the form com.Xxx.Yyy where Xxx is the name of the company and Yyy is the name of the application. You can use any name here, but this is done just to avoid conflicts with other applications.

Like any Windows application, the Android application is characterized by name and icon. The name you set through the android:label attribute in <application> is used to identify the application on the device, as in the left side of Figure 3.

Figure 3: The sample application listed on the device.

The sample application listed on the device.

It is key to notice that the label is not used to decorate the application in the menu, as in the right side of the figure. In the menu of applications, Android uses the title of the main window. You control the title of the application via the android:label attribute on the <activity> element. A few words are worthy the special syntax used to specify the label. It indicates that the content of the attribute will be read from the application's resources.

The @string prefix indicates the type of resource; the name past the slash indicates the name of the resource. String resources are stored in a strings.xml file located in the res/values project folder. Here's an excerpt:

The icon of the application is taken from the resources and its path follows the same pattern as strings:

In this case, @drawable indicates a bitmap resource and the rest of the string is the name of the file. The file should be physically placed in the res/drawable project folder. Android supports various resolutions due to the sometimes significant difference of real estate and hardware capabilities of the devices. At the project level, you have three drawable folders for three levels resolution - high, medium and low. You place in these folders different resources and Android will pick up the ones the suits better. The actual folders are drawable-hdpi, drawable-mdpi and drawable-ldpi.

The <activity> element defines the startup class - called an activity in the Android jargon - that makes the application run. The activity name is rooted in the Java package referenced in the <application> element. The <intent-filter> element specifies the intents of the application and lists the requirements it has such as using local storage or networking. At the very minimum, an Android application has the intent of starting up the main activity. The category attribute sets the type of intent; the value launcher indicates that the activity is the launcher of the application. The action attribute defines the action being performed by the intent; the value main indicates a startup task where no input is provided and no output is returned. More in general, intents in Android are just data structures referring to an operation to be performed.

The Core Code

An Android application is based on one or more classes known as activities. They extend the base class Activity and offer a few overridden methods for the runtime to call back during the execution of the application. Here's the skeleton of an Android activity:

The method onCreate is invoked each time the activity is created. This can happen in only two scenarios: when the application is starting up and when the application is re-launched after being paused. Paused applications normally are kept in memory and resumed in case the user navigates back to them. However, if the system is running short of resources it may even kill the process. Subsequently, when the user navigates back to the application, the process is restarted and the activity is created again.

In the implementation of onCreate, you call the method on the parent class and use any bundled data to restore the previous state. Just before the application is paused, and thus becomes vulnerable to being destroyed without notice, the onSaveInstanceState virtual method is invoked. This method is called to give the activity a chance to save its state which will be restored later. Any data saved in onSaveInstanceState belongs to the system and later becomes the input of onCreate when the activity is restarted. In other words, saved data is not lost with the process and is made available to the new process that runs the application for the next time.

The other fundamental step performed by onCreate is initializing the application performing any one-time tasks. The most important of these tasks is loading the user interface. In Android, you define the user interface by writing an XML file whose schema reminds .NET developers a bit of XAML. In the res/layout project folder, you create a main.xml file (the name is actually up to you) and pack it with code like below:

The LinearLayout component lays out its child elements either vertically or horizontally as the orientation attribute dictates. Android supports a variety of layout elements for an overall result that is not much different from XAML. Elements must have a layout_width and layout_height attributes. Values can be specified as absolute values in pixel or other measurements as well as through ad hoc keywords like fill_parent and wrap_content. The former indicates that the area of the element extends to fill the parent's area; the latter indicates that the size is large enough to cover the content. The TextView element you see in the listing represents a static text much like the Label element in XAML and ASP.NET. With this code in the project, what you get is shown in Figure 4.

Figure 4: The HelloWorld Android application in the emulator.

The HelloWorld Android application in the emulator.

Summary

Android development doesn't pose huge hurdles in front of experienced .NET developers. The language is very close to C# (and not so hard to understand for Visual Basic developers) and the logic of the application quite understandable. You write the user interface using an XML file whose schema is quite natural to follow once you know a bit of XAML. The event handling mechanism is not as seamless as in C# but nothing that represents a real showstopper for developers committed to Android. The painful thing for .NET developers is the lack of a designer; some free tools exist out there but none can compete with Visual Studio. Be aware of this as you take the path to Android. This article just stopped at the hello-world level. In the next article, I'll discuss a more interactive application with event handling and a more sophisticated user interface.