MWorks blog

First, a bit of background. I’m a bit of a geek, I love command lines, if it has a CPU – I’m interested. I use Mac, Windows, Linux, Android, iOS … They are all fun!

I have written Mac OS X applications since its release (JellyfiSSH 1.0 was released on Mac OS X 10.1) and have written a number of iOS applications for myself and a few other companies. One of the larger iOS project owners requested that it be ported to Android – so we did. I thought I would put down a few notes on Android because you have all the twitter “experts” rambling on about how Android is fragmented and has multiple screen sizes and on and on – but the reality is – it’s actually not that hard. I now laugh out loud when I see those “twexperts” go on about Android – it is VERY clear they haven’t even opened the SDK.

I’ll probably break this up into this 101 intro to get people started, and then a more advanced blog post later on. This isn’t a tutorial or a how to guide – just a few comments to break down the barriers.

Get Started

First things first – install Eclipse and the SDKs. Follow the instructions here. Once you have Eclipse and the SDK installed, go to the Android SDK and AVD Manager under the WIndow menu and look at Available Packages. I installed all Android SDKs back to 2.0. Forget 1.x – support from 2.1 onward and you’ll cover the majority and you avoid the fragmentation issues completely.

While you are in the SDK and AVD Manager – go ahead and make yourself a nice little virtual machine to test code on. Use a screen of 480×800 should be a good all rounder.

Follow the instructions here on making your first hello world application and run it on the emulator. Yes, the emulator is really, really, really, really slow (it’s OK once it has booted). If you can fork out for a $299 Samsung 550 or even better – a Nexus. The Nexus is supplied by Google and is a plain vanilla install of Android which is the best way to develop. (and you get updates directly from Google rather than your carrier)

Projects

The project bar on the left (after making Hello World) has a few folders and files in it.

The src directory contains all the source code. The language is Java. I ported Objective C virtually line for line into Java. Some things in Java are not as nice as Objective C – some things are better. An example would be joining strings together.

Objective C: myString = [myString stringByAppendingString:@" hello kitty"];
Java: myString = myString + “hello kitty”;

The gen directory is where all the object files live. Not too interesting.

The Android 2.1-update1 directory has all the includes/libs for that SDK. Good to browse through as a beginner.

Assets is where you can put items such as images, sounds, SQL databases – anything which you want to call on to use. They have a file system path which means they can be referenced that way.

Res is like the Resources directory in XCode. It contains all sorts of things including layouts (covered later), high/medium/low res graphics directories and a values directory for storing strings and translations etc.

AndroidManifest.xml is a very important file – similar to info.plist in your XCode project

I didn’t really get into proguard – but it scrambles your byte code from what I could see in your final compile.

Res directory

Here is where a lot of the action takes place. (Well, except for the code – but I expect you can figure that out) Firstly, the directories for the various resolution images are optional to use. If you load up your graphics into drawable-hpdi (hi resolution) and don’t put graphics into mdpi or ldpi – it will still work. The results are just better if you put the graphics in. You also put your icon.png into here too and put in a reference to it in your manifest file (it will be there by default):

<application android:icon=”@drawable/icon” android:label=”@string/app_name”>

Next, layouts.

Lots of non-existent issues here. If you look into a layout directory, you will see something like this:

The XML files you see here are like XIB (NIB for old schoolers) files – but for each screen. If you double click on one of these, you will get a GUI editor and a raw XML editor. You can drag in objects and then right-click on them to set attributes and properties. Easy.

And you can even choose different device screensizes and orientations to see how it will behave. Not too dramatic.

You set a unique ID for each of the elements and then you can use the Android resource manager to get/set data and/or behaviors. I read a couple of tutorials and looked at some sample code – and it was done.

For example, when the application starts up, I wanted to show the splash screen. So, in the OnCreate() for the main thread, I added:

setContentView(R.layout.splash);

which uses the Resource manager (R) and looks into the layout directory and displays a layout called splash. (splash.xml)

The code for layouts themselves is just XML and if you have had experience with html, it isn’t too much harder than using tables and CSS etc. By using nested tables and layouts, you can get them to dynamically scale to any screen size. The very basic layout you see above scales down to 2.7inch screens right up to 10.1″ tablets. It actually works VERY well.

(TIP: NEVER specify px (pixels) in your layouts, use dp instead. It auto remaps the numbers for you. Example, if you want a button to be 38pixels high, use 38dp and Android will remap that to the various resolutions and sizes for you. It works.)

I think I’ll leave it there for now. I guess I wanted to illustrate that while different – they are similar and you shouldn’t think that it is a nightmare to develop for. If I believed the “twitterexperts” out there – I wouldn’t have started this project. Now it is finished – it wasn’t that hard! This project looks easy, but it does have an onboard SQLite database, macro conversion and display with images in the search results etc.

I might go and port this to Windows Phone 7 – just to see how that works…