Developing Android Applications Part 3: The Environment

At the end of the last article I included a link to the official Android Hello, World application. We’re going to proceed assuming that you have worked through that, although I will re-cover a lot of the topics from there (never hurts to do something twice!). I am also going back on the promise about all screenshots coming from the Windows platform (they’ll be from Ubuntu from now on) however as stated previously, developing for the Android platform is identical across all operating systems so this really doesn’t matter, and if there’s anything that’s Windows specific, I’ll cover it in that OS. Also if you’re having problems developing under Windows, please comment and I’ll be happy to help.

Anyway, on with the show. This time we’re just going to go over the environment you’ll be working with describe of some of the files and folders you can expect to encounter, followed by a quick look at the emulator. So let’s start a new project!


Creating a New Project

Firstly, fire up Eclipse and from the Toolbar select File -> New -> Project, then choose “Android Project” from the Android folder. This will take you to a screen which prompts you for various details. This screen is actually part of the Android plugin that you downloaded last time, so all of the fields here are pertinent to your android development environment. They’ll contribute to either your file structure, your application manifest or any class stubs that get created. The “Hello World” application suggested what you should fill in here, but I’m going to fill them in slightly differently so it’s easier to see what went where afterwards. These were my settings (feel free to substitute in your own name for mine!):

Anyway, once you’ve filled in the details here, click finish and you’ll be presented with a basic Android development environment. We’re going to go through that in a bit of detail next. I am going to point out as we go along where each of the fields you entered above actually ended up, but for now here’s a quick summary;

Project Name

This will be the name of the folder that gets created on your hard drive, inside which will be your project files. It’ll also be the “root” node of your project explorer when you create your environment.

Application Name

This will go into your application manifest (we’ll come to that in a bit; it’s just an xml file describing the various properties of your application). This particular field is the human-readable name for your application, so it’ll be the words that appear under the app’s icon when you deploy it to an android device.

Package Name

A package is a similar (well, actually pretty much identical) idea to the .net ‘namespace’. Although it works and looks a bit differently, it serves exactly the same purpose. Just put com.yourname for now (I won’t go into packages in great detail here because these are Android tutorials, not Java ones)

Create Activity

This will be the class name of a dummy/stub class that will be created for you. More on the Activity object in a later article.

Min SDK version

This is another one of those items which has a shelf life. At time of writing, the newest sdk is version 2.2, which is API version “8”. The number actually refers to which SDK version you want to be able to run on: these are all forwards compatible but NOT backwards compatible! The “hello world” example suggested you enter “2” here, I’ve entered “8” to illustrate this point. You don’t want to set your minimum SDK version to be the newest version just for the sake of it. If you’re not using the features of a later SDK, why would you want to alienate a whole bunch of other potential users? Anyway, below is a handy table showing which SDK version numbers correspond with which API versions. Enter the “API version” into the “Min SDK target” field. This setting will also go into your application manifest and default.properties file (see below).

SDK version API
1.0 1
1.1 2
1.5 3
1.6 4
2.1 7
2.2 8

The Emulator

Okay, so you should now be presented with a screen showing an editor window and a package explorer on the right.

You may notice that you probably have an error being reported in the console (something about “R” not existing) and also that there are exclamations within your project explorer also suggesting errors. These will go away in a second or two (have patience!). The reason for these initially reported errors is that some of these files in your project will not have been created yet. We’ll get on to the rest of this environment in a moment, but first let’s run this default project and play with the emulator! Just select “Run” from the “Run” menu. You should already know how to run an Android application from the “Hello World” article, but if you need a refresher: just select “Android application” when asked what to run as. The emulator will take a good 20 seconds to fire up (you’ll see Android logos and things flying past). Note that once this beast is up and running, you can build and deploy your code to it instantly without having to start it up again. Basic rule then: once the emulator is running, leave it running! After it’s all fired up you’ll eventually see a screen like this;

Although, if you used different values when creating your project then the text may not be identical to this. For now, just hit the “Home” button on the right, which is the one shaped like a little house. This will take you back to the Home screen, which looks like this by default;

At this point I’m not going to go into any further detail on the emulator. There’s no need, that little robot dude on the home screen will tell you everything you need to know, and because it’s such an intuitive platform you can probably work the rest out for yourself. The only thing of note really here is that the section on the right represents “physical buttons” – these won’t be physical on all android phones but all will have “a way” of doing them (mostly this will apply to the keyboard, which on the latest HTC is a physical keyboard but on the Samsung Galaxy S is a virtual keyboard). The industry doesn’t seem to have decided which of these users perfer yet, but fortunately for Android developers, this ain’t your problem 😀 On a personal note, I consider this to be another huge advantage that this platform offers: You design your app around the concept of “the Q key being pressed” and if, eventually, the masses decide they prefer physical keyboards over virtual ones, your app will still work. The people will eventually go with what works and you’ll be there when they arrive!

When you’re done playing around, head on back to Eclipse and we’ll take a look at the development environment.


The Development Environment

Okay so now you’re back in the Eclipse IDE, take a look on the left hand side of the screen and you’ll see your package explorer (now, hopefully, bereft of any weird exclamation marks). I’ve expanded mine a bit here to show important files. Each of these is discussed in a bit more detail below:

This explorer almost totally mirrors the heirachy of files on your hard drive… but not quite! This will be a concept fairly familiar to iOS developers. The package explorer arranges things in a slightly different heirachy to what you’ll find if you browse to the project folder on your hard drive. Not dramatically different, but different none the less. Below is what they look like on my system;

Anyway: You don’t need to worry too much about that because you’ll be doing nearly all of your development from within the IDE. Worth knowing, nevertheless! Anyway: back to the IDE, what do all of these folders mean? Note that the above picture of my file system is NOT what I’m referring to below: I’m talking about the heirachy in your IDE (the next picture up!). Also, to differentiate this guide from others (otherwise, what’s the point) I’ll try and reference each of these concepts back to an ASP.net equivalent.

The node at the very top

In my case this is named “MikeysProject”. This will be what the folder is named in your file system, and is specified in the “Project Name” field when you first create your project.

The “src” node

This is where your .java source files will go. If you expand it you’ll see that the source file is already inside whatever package you defined when you created your project (in your file system, it will be inside folders named after the dot seperators, so in my case it’ll be in src/com/mikey). Drill down and eventually you’ll find a source file called “MikeysActivity.java”. Double clicking this opens the source file where you’ll find an Activity stub class called “MikeysActivity”. In both these instances, the source file and class defined within it are named based on whatever you entered in the “Create Activity” field when you created your project. You’ll put more source files into this folder as you build bigger applications. This would therefore be the ASP.net equivalent of the “App_Code” folder. It’ll all get compiled into what you would know as “assemblies” (‘class’ files in Java) when you build.

The “Android 2.2” node

The name of this node will vary depending on which version of the SDK you have installed (in my case it’s 2.2). It’s just a package explorer for the Android API. You can drill down and see all the packages available to you in the Android jar file (for the uninitiated, a jar file is just an archive of Java class files). This would therefore be the ASP.net equivalent of the “Object Viewer”.

The “gen” node

This is the stuff that gets generated when you alter any XML resource files. Remember that “R” related error you had when you first created your project? This is because the “R.java” file wasn’t generated yet. You will not need to manually edit files within this folder: The Android plugin sorts all of this out for you. More specifically, the “R” source file is a bunch of static classes generated from humanly readable XML files (which we’ll come to in a moment). You define your application’s resources in XML and the R file gets generated for you as you save them. You can then use these static classes to access the values from the XML through the the R class in your source code (although values in the R file will be pointers to memory addresses, not literal values). This eliminates completely the need to traverse nodes. We haven’t come on to resources yet, but keep this R file in mind when we come on to them next. There is no direct comparison here with ASP.net, other than perhaps the “bin” folder that contains your assemblies after a build (but this is tenuous at best, so just consider it something new!)

The “res” node

So this node is tied very heavily to the “R” class from the last node. Upon a build, the R source file is generated based on the things in this node. You can therefore deduce that “res” is an abbreviation of “resources”, and so is “R”. There are a few different folders in here. These will be used to generate the aforementioned “R” class. Before we get on to that, let’s just have a look at the XML files you have to play with here;

Things in the “layout” folder

These will be XML files representing layouts. The ASP.net equivalent would be the “.aspx” files. We will come on to the various types of layout and how to use them in a later article.

Things in the “values” folder

These will be XML files representing string literals. The one you get for free is “strings.xml”, but you can totally add your own if you want to seperate these out into seperate files. When the R.java file is generated (more on that in a moment) the static class will be named the same as your xml file, minus the trailing ‘s’ (so in this case, strings.xml will become the “string” class in the R.java source file). If this R.java stuff isnt’ making sense, don’t worry: we’ll demonstrate it in a minute. For the time being just take a look at the “strings” xml file;

<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="hello">Hello World, MikeysActivity!</string>
<string name="app_name">Cool App</string>
</resources>

You should recognize one of these values! The “app_name” attribute on the second inner node is the name you gave to your app when you created your project. I had previously mentioned that this would end up in your application manifest, and it will, but it’ll be as a reference to this node here rather than a literal.

Things in the three “drawable” folders

There are three folders with the extensions “hdpi”, “mdpi” and “ldpi”. Unlike an iphone you can not assume the resolution that a phone will be able to display at. These three folders will adjust to whatever is appropriate for the phone that the user is using. You don’t actually need use these three folders, you can just create a new one called “drawable” and get your resources from there. You’ll find that upon initial creation of a project the only thing in these folders is the “Icon” (a little robot waving). If you want to change your applications icon, these are the things you change (the files here get referenced in your application manifest, which you’ll see in a moment). If you’re going to take anything away from this section, just take away that this is where images go and that there are various ways you can structure your folders. The only other thing to bear in mind when using images in Android applications is that the platform prefers .png files, with .jpg files being used only when nessecary and .gif files being heavily discouraged.

So this R.java file then… If you open it you’ll see that the files in the res node are almost totally mirrored by the classes generated in there;

/* AUTO-GENERATED FILE.  DO NOT MODIFY.
 *
 * This class was automatically generated by the
 * aapt tool from the resource data it found.  It
 * should not be modified by hand.
 */

package com.mikey;

public final class R {
    public static final class attr {
    }
    public static final class drawable {
        public static final int icon=0x7f020000;
    }
    public static final class layout {
        public static final int main=0x7f030000;
    }
    public static final class string {
        public static final int app_name=0x7f040001;
        public static final int hello=0x7f040000;
    }
}

To demonstrate completely the R.java file, open up the res/values/strings.xml file and stick another string in there. Just copy/paste one of the existing ones and rename the node and value. I, for example, created the following;

<string name="another">Line</string>

If I save and go back to my R file, on my system I have the following new member added to the string class;

    public static final class string {
        public static final int another=0x7f040002;
        public static final int app_name=0x7f040001;
        public static final int hello=0x7f040000;
    }

So, the member “another” is added, with a memory reference to what you can safely assume is the value “line”.

The AndroidManifest.xml File

An xml file representing various global properties about your app. If you open the file in Eclipse, it’s going to try and give you a GUI representation. You can get rid of this using the tabs at the bottom of the editor window to return to pure XML. You should recognize some of the values in here, for example: attributes within the “activity” node and the “minSdkVersion” node (both of which you specified when you created the project).

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.mikey"
android:versionCode="1"
android:versionName="1.0">
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity android:name=".MikeysActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

</application>
<uses-sdk android:minSdkVersion="8" />
</manifest>

Other nodes, such as the “label” attribute within the “Application” node, are XPATH references to the “strings.xml” file, and so indirectly are references to the values you specified when you created your project. The closest ASP.net equivalent to this is the “web.config” file (or the “global.asa” file if you never made the leap). If you’re an iPhone developer, this is the equivalent of the main “.plist” file you get when you first create an application.

The default.properties file

Leave this alone too, it’s auto-generated based on the AndroidManifest.xml file. You don’t need to worry about this for now 😀


Conclusion

Okay so that’s it for now. This guide took you through the basics of the environment you will be working with whilst developing Android applications. Any questions, leave a comment. Otherwise, I’ll see you next time for an in depth look at the Android layout model.

Advertisements

2 thoughts on “Developing Android Applications Part 3: The Environment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s