Blog
Yesterday I shared my thoughts on Android 2.2. Today I would like to share my experience in using the Android SDK to build an Android version of the first iPhone app I ever built. The app is called Lekkerindebuurt. It is a mobile client for a website called www.lekkerindebuurt.be.
Some of the features of the app are:
- get a list of most viewed restaurants
- search for restaurants by name, place, kitchen
- see the closest restaurants around you on a map, based on your gps position
- you can favorite restaurants
- you can ask for a walking route from your current location to the restaurant
- you can call the restaurant (if a phone number is available)
- you can mail the restaurant (if a mail address is available)
- you can visit the website's restaurant (if a url is available)
- you can read comments from other people
- you can rate restaurants and leave comments yourself
- you can see pictures taken by other people
- you can take pictures yourself and upload them back to the website
The app presents this information in a tabbar interface, using navigation controllers to slide detail views in place.
I wanted to share this list so you can get an idea of what had to be done in the Android version. Basicly the Android version has all these features except taking images and writing comments. I didn't leave them out because they were too difficult but because I wanted a version 1.0 out asap. These features will follow in future updates.
The book I've used most to get started was written by Mark Murphy and published by Apress. The book is called "Beginning Android 2".
I used this book to install the development tools which include Eclipse, the Android SDK and the Android Developer Tools (ADT). Installation was a little bit tricky. In my case the latest version of Eclipse was apparently not the right one for Android development so I had to download an older version. Not a big deal.
With these tools you can create virtual Android devices which run in the Emulator. You can configure these virtual devices and give them whatever screen resolution you want which is good for testing. More on that later. When you run your app you can choose on which virtual device you want it to run.
I'm going to go through most of the features of the app and discuss whatever problems I experienced with them.
TabBar/Navigation
It's pretty easy to build a tabbed layout in Android but I didn't find a way to run a navigation controller like setup in them. As a result, when you select a restaurant from one of the lists the detail screen opens full screen. When you use the hardware Back button you get the tabbed layout back.
At first I thought "uh oh, that's not good" but it's something you get used to pretty fast. Like I said yesterday: having a hardware back button saves screen real estate and not having the tabbar items visible saves even more screen real estate.
The detail screen uses a full screen scroller to present all the restaurant information. Like in the iPhone app you swipe up and down to control the scroller. No real problems there, apart from the fact that scrolling in Android isn't as pixel perfect as on the iPhone.
Mapview
Using Google maps in iOS is pretty easy. On Android I had to fiddle around quite a bit to get them working which is strange since both are made by the same company. It involves - hold on - getting the MD5 fingerprint of your signing certificate (of course, this is done running an obscure command in Terminal). You then register that fingerprint with the Google Maps service which gives you back an API key which you then have to use in your app.
I have to admit this was pretty scary although it _did_ work first time. I think you'll agree with me that this sort of stuff shouldn't be so scary.
Custom cells
Making your app look nice when using UITableViews can be done in a few different ways. One way I use a lot is by subclassing UITableViewCell and build a nice cell layout. A similar solution is available in Android.
Multiple Android versions
You've probably seen the pie charts that indicate the versions of Android in the field. For a while there was some serious fragmentation going on. The reason for this was the speed with which Android evolved and releases were made.
Google has acknowledged this problem and less releases will be made in the future.
If you don't want to support all versions of Android with your app, it's very easy to put a minimum Android version in your app. As a result your app will not run on versions below that minimum version.
Multiple resolutions
Android's goal is a lot different than iOS' goal. Android is built to run on a series of devices. These devices can have different resolutions, different pixel densities and so on. Some claim this is a mess to develop for but it really isn't.
It really isn't.
Any good book on Android development will tell you it's not the best idea to use pixels when describing your layout. You're better off with a device independent measurement unit. These books will also tell you not to use AbsoluteLayout.
Having done web development and software development for desktops this all made perfect sense. I found the logic to be much like building a liquid website, where you describe width in percentages instead of pixels.
If you're unsure of yourself or if you're convinced that your layout will just not work on small screens, the, Android offers the possibility for developers to say "I only want my app to run on mobile devices which high resolution."
Interface builder (or lack thereof)
Without a doubt _the_ most annoying problem when doing Android development is the lack of an Interface Builder like tool. I've tried DroidDraw which is a 3rd party screen designer. I found it buggy and had to fight the urge to poke myself in the eye after about, oooooh, 2 minutes.
Unless I'm missing something very obvious you're stuck designing layouts by typing xml. Now, Eclipse does help you a lot by automatically adding closing xml tags and what not but I felt a lot of times I built and ran was simply to check the layout.
I don't agree with that.
I don't agree with that at all.
If you have a mobile OS that can run on different screen resolutions (I'll leave the fact if that's a good thing or not in the middle) you need an interface building tool of some sort.
I kept thinking how things could be so much easier layout-wise if the Android tools included a screen designer like the one in Microsoft's Visual Studio. You know, the one where you can anchor controls to edges of screens, making them resize and move automatically when you make a screen bigger.
It would make designing for different screen resolutions so much easier.
Conclusion
After reading all these problems you're probably thinking "wow, glad I'm doing iOS stuff instead". I'll admit the iOS development experience is a lot more polished and - at this point in time - it is the one I prefer.
That said, I didn't hate doing Android development. Both these os's offer very similar functionality and you feel that when developing. You find the same things, you find the same ways of working, sometimes you appreciate how one os does a certain task different than the other os.
I feel that _any_ mobile developer should find out what other os's can do and porting an app is a great way to start. Even though I only used a small percentage of the Android SDK to build this app I enjoyed doing it. There is great literature available, there is a great community, Stack Overflow is filled with questions and good answers on Android development and I was never stuck for long.
I'm also convinced that Android - along with other mobile os's like Windows Phone7 and WebOS 2 - has a great future. Mobile is just getting started.
