previous

Time to create a project!

If you have never made an Android project before, then I’d suggest to make a Hallo World project first. Do it on your own in Eclipse. The default project that is created is a Hallo World stub project anyway. You can find help here if you aren’t familiar with Eclipse. If you are interested in the folders and files that is created (I sure was when I did this the first time) then this page explains them.

Otherwise go ahead and create a project for the game tutorial. I called my project  Tutorialgame, the Application name “Tutorial Game”, and the package name com.karlund.tutorialgame. Obviously change that to a package namespace that make sense to you. Just remember to change all references to your namespance, even the ones in the xml layouts (so you must read through them, this is the single highest possibility of bugs following this tutorial). I usually create an Activity (the main component of an Android app) which I in this example called GameActivity and I set the minimum SDK version to 4, which is Android SDK 1.6 – the most common starting point for support at the time of writing (e.g. admob needs this level).

This provides you with a stub project (Hallo World), which we’ll change in the rest of the tutorial.

Lets examine the AndroidManifest.xml file (click the file in the Package Explorer, and press the tab “AndroidManifest.xml” underneath the appearing window:

If you aren’t familiar with XML, then, welcome to the worribleness of it. It shouldn’t be too difficult to figure out though, if you need some help with understanding it you can find some help here.

The manifest file is where apps declare their capabilities, needs, core attributes  and intents. You can find a full intro here, but I’ll go through some of the important elements in this post.

As you can see all of the information we put into the Eclipse “New Android Project” dialogbox are present here. The android:versionCode and android:versionName are settings that you can use when you update your app. The Android Market (and alternatives) will use the versionCode to test if an upgrade is necessary on the handset (should be an increasing integer scheme) and the Name should be the human readable usually in the normal versioning style (e.g. 1.2.1).

An app can consist of many applications and activities, but we keep it simple here with “only” one application with one activity.

The android:label with the application tag specifies the human readable name of the application. “@string/app_name” introduces the resources management in Android projects. @string refers to the strings.xml file under the res/values folder. If you open it you’ll find it contains Name/Value pairs of strings (you can add other types than strings later if you want to), that can be accessed from all parts of the project (and you’ve just seen how you do it from xml files). This is a great system that not just aid the developer keeping the code clean, but also helps with localisation of the code. If you want to change the human readable name of the app, you can just change the value of app_name in the strings.xml file, simple as that!

Likewise the android:icon specifies the icon. You’ll notice that I’ve changed that already. Yours will read “@drawable/icon”. @drawable works like @strings, but refers to the res/drawable folders (e.g. drawable-hdpi). This is the first complicated issue we stumble upon. If you have heard of “fragmentation” of the Android platform, then this is the most common source of this. Screens on the Android phones comes, unlike the iPhone, in many sizes, resolutions and densities, and to support all of them can be a pain (I know – I’ve tried to in Rune Escape), especially if you want a consistent look’n’feel across all types of devices. These folders help you to do that, and you can create other kinds of drawable folders than the ones you are given by default. It might be too early to dive into this already, if you really want to go to this page for an introduction, otherwise just delete the folders and create a new folder called “drawable” and add these images to the folder:

icon_64.png

yellow_ball.png

background.png

This is the “old” way of handling graphics, all in one folder, and see what happens after density scaling has happened. Not the best way, but as long as you know that you really should change this approach before releasing an app to the market place, then this is fine for now. It will work, it just might look awful, and believe me, it probably will anyway, because the graphics I just gave you are quite, hmmn, crude anyway! Well, enough about graphics 😉

Next thing is the actual activity. Activities are the components that users normally “use”. This is where all the logics go. Here, we are just declaring then, so that the Android eco-system knows about the activities this app creates – very similar to the application statements except for the intent-filter. Intents are callable actions that outside apps can call. It is for instance through this system that Android “magically” knows that the browser can view http:// pages and that Android Market can display market:// sources. What we declare in the two lines of the intent-filter here is that this app can be called as a MAIN app (we won’t be creating a main, it is maintained for us), which means it can start from scratch without any incoming data, furthermore, the android.intent.category.LAUNCHER declares that this intent, and therefore the activity, should be shown in the launcher menu of the phone. More info can be found here, if you want to know more at this point….

This is all that this manifest declares, the next step is actual programming – Yay!

next