Development on iPhone vs Android

As I mentioned in an earlier post, I have been working on both iPhone and Android platforms simultaneously. While the road has been bumpy, it has also been a lot of fun. I think I know enough of both the platforms to give my opinion on development on iPhone and Android.

Apple officially announced an iPhone SDK sometime in March 2008. The SDK contains an iPhone version of the Cocoa libraries called 'Cocoa Touch'. The SDK itself is a free download, but you will have to cough up $99.00 (registration fee for the iPhone developer program) if you want to run the apps you are developing on an iPhone. That is a lot when you compare it with Android, where you have to pay just $25.00 to be a registered Android developer.

The latest version of the SDK is a whopping 1.7 GB and contains the entire iPhone development toolchain including XCode, Interface Builder, Instruments, the simulator and APIs including Cocoa and Cocoa Touch. The SDK can be used to develop applications for both iPhone and Mac OSX. Android SDK on the other hand is a much more reasonable ~80 MB. Andorid SDK contains the Android API, the Android tool chain, Android simulator and Eclipse plugin called ADT.

Android Development Tools or ADT is an eclipse plugin that makes it really easy to create, build and debug Android applications.

One of the biggest drawbacks in developing for iPhone is that it can only be done on a Mac OS X machine. There is no support for Windows (which is good) or Linux (which is bad). Android SDK on the other hand is multi-platform and gives more or less the same user experience on all the supported platforms.

Disclaimer: I am not an Eclipse or an XCode expert and my comments are based on my experience (or lack thereof).

I love and hate developing on both platforms. There are certain great features which each one offers and there are features which both can improve on.

IDE:

XCode is definitely the winner here. It is very stable and takes up a lot less memory than Eclipse. The 'Interface Builder' is an awesome tool, but more about it later.

Not so easy on ADT/Eclipse. While not really an Android issue, using Eclipse slows down my machine. Once it was taking up more than 75% of the physical memory on my machine. I know, I don't have to use Eclipse. But being inherently lethargic and lazy, I never really bothered to figure out how each of the tools works.

I also find Eclipse 'auto-compile/let me display the squiggly line before you finish typing' feature very distracting and annoying. I am sure there is a way to disable it, but could never find it.

UI development Tools:
Getting the UI right for a mobile application is the key. It makes or breaks the app. I feel it is important to spend a good amount of the development time to get the UI right.

UI design on iPhone is very easy. and lets folks like me who are 'UI Design Challenged' an easy way out. You just drag and drop the components, connect the outlets and actions and you are done.

The UI design tool in ADT is useless. DroidDraw is definitely a better alternative but cannot match 'Interface Builder'. The recommended way for creating Android UI is through what are called 'layout files'. Layouts are XML files where you define the hierarchy for your UI. While the learning curve is very small, getting the elements to be at the right place drove me nuts!! There are attributes like 'weight', 'gravity', 'orientation' ... aaarrrrggggghhhh!!! There were times where I spent 30 mins writing the functionality but 3 hrs trying to get an element where I want it.

Debuggers and other tools:
Debuggers on both environments are pretty decent and I really have no complaints there.

The iPhone SDK also has 'Instruments', an instrumentation tools, that is extremely helpful in analyzing performance of the app.

Android SDK comes with Android Debug Bridge (adb) and Dalvik Debug Monitor Service or DDMS which provides a bunch of services like port-forwarding , screen capture on the device, thread and heap information on the device, logs, process information and some really funky features like spoofing incoming calls, location data and SMS.

I must admit that my knowledge of both Instruments and DDMS is very limited. I just understood enough of each to get out of some tight spots.

The Code:
Android is clearly the winner here. The API is really rich. There are things you can do which you cannot really dream of on iPhone (at least not without jailbreaking). The features I really like the best are Intents (Intents are very difficult to explain, but pretty simple to use/abuse and I recommend having a look a the documentation to really understand it). Android API also allows creating of background services opening up more creative avenues for the developer. iPhone API does not support background services yet and does not allow for more than one third-party app to run in the background.

Android API is in Java which means the learning curve is much less steep (for someone who knows Java). Not so easy for iPhone. iPhone API is in Objective-C which while being extremely feature rich is also very, for a lack of a better word, non-traditional. I found the syntax a bit weird at fast, but got over it very fast. Objective-C uses named arguments. For example, a Java method looks like:

someObject.someMethod(someParameter, someOtherParameter);

An Obj-C method on the other hand looks like:

[someObject someMethod:someParameter withSomeOtherParaMether:someOtherParameter];

This can make method names pretty long. For example:

- (void)loadData:(NSData *)data MIMEType:(NSString *)MIMEType textEncodingName:(NSString *)textEncodingName baseURL:(NSURL *)baseURL;

Memory management is another issue. Android supports garbage collection while iPhone does not. So, keep track of object allocations and releasing them when not required is a big task on iPhone.

Conclusion:

My goal here was not to do a feature by feature comparison, I neither have the experience or the expertise to do so. I feel that developing on both platforms have their own issues and I accept that some of these issues are probably because I did not take time to understand a feature or an API before using them.

Having said that, both Android and iPhone APIs make mobile development really a fun experience and I would find it very difficult to choose my favorite platform among the two.

I recommend this book for Android and this one and this one for iPhone.

Consuming Keydown Events

The last few weeks have been very hectic for me. I am working on my first Android and iPhone projects simultaneously and anyone will tell you that is not fun :-).

Anyway, while working on an Android app, I came across a small problem that really annoyed me. I was displaying a modal dialog and I did not want the user to navigate away from the modal dialog unless they clicked an 'OK' button.

But then I saw a problem. All the user had to do was press either the back button, the home button or the call buttons and the dialog disappeared. Now that is not what I intended or wanted and in the interest of self preservation, I started wondering how to solve the problem and thankfully found a very easy solution.

All I had to do was consume the keydown events for those buttons by overriding the onKeyDown method in my dialog class.

@Ovveride
public boolean onKeyDown(int keyCode, KeyEvent event) {
switch (keyCode) {
case KeyEvent.KEYCODE_BACK:
  return true;
case KeyEvent.KEYCODE_CALL:
  return true;
case KeyEvent.KEYCODE_DPAD_CENTER :
  return true;
case KeyEvent.KEYCODE_ENDCALL
   return true;
case KeyEvent.KEYCODE_HOME: // this does not work.
    return true;
default:
   break;
}
// pass all unhandled events to the parent class
return super.onKeyDown(keyCode, event);
}

That is it. I could now prevent users from clicking on these buttons and navigating away from the dialog.

This can be used to disable users from pressing any other buttons you don't want them to. The only exception is the 'Home' button. I am not sure if there is any other way, but this approach certainly does not work. You can find a more detailed reference on all available key event constants here.

The Android Developer Phone

I started with Android programming couple of weeks ago and was itching to get hold of the actual phone and this week my wish was granted.

Being an iPhone owner, I was very excited with the possibilities and opportunities an open platform brings. While the iPhone provides a great user experience, the lack of support for third-party background services puts a limit to the kind of applications one can write. Anyway, back to Android.

The developer phone, also called ADP1, is a SIM-unlocked and hardware-unlocked. So, a SIM card from any network. I used it with Airtel SIM and it worked without any problems (well not really but more on this later). The other great advantage with ADP1 is that since the bootloader is unlocked, advanced users can build Android from the source and flash the phone with custom or bleeding edge builds. Exciting!!

After I got the Android, I booted it up only to find that there was no way to get past the initial setup wizard. The setup wizard ties your Google account to the phone. This essentially allows for download (and sending) of emails on Gmail and syncing of the calendar app on the phone with Google Calendar and the contacts app on the phone with Google Contacts with the registered account. The only problem is that it requires a data connection (aka. EDGE) to be enabled on the SIM. There is no 'skip' button (atleast not with the stock ADP1 firmware) to skip this step, enable WiFi and register.

But I had the SDK installed on my system. So, I used Android Debug Bridge or 'adb' to skip this screen. I connected the phone to my computer and opened a terminal window and typed:

adb shell

This connected my computer to the shell on the phone. The following commands disabled the app wizard:

$ su
# echo "app.setupwizard.disable=1" > /data/local.prop
# reboot

The 'adb shell' opens a shell on the remote device from the computer. The 'su' was required since the default user on the device did not have the necessary permissions to create the file in '/data'.

This connected my computer to the shell on the phone. The following commands disabled the app wizard:

That did the trick. The home screen appeared after reboot. I played around with the phone for some time before I started itching for 'cupcake'.

'cupcake' had a couple of features I wanted to try out including a soft keyboard and the A2DP bluetooth profile.

So, I downloaded and built the Android source code. What was amazing was that the entire source code built without any issues the first time. Well, almost. The default Makefile target was not set for the device. I read through the documentation and found that there were some additional steps for building Android for the device.

I followed the instructions as is and after about 45 minutes or so, I had the 'cupcake' version built and ready for flashing.

Here are the instructions for flashing the device. Please try it at your own risk :-)

1. Go to the Android source code root folder on your machine.
   
2. Ensure that 'out/target/product/dream' exists. We are interested in 'system.img', 'boot.img' and 'userdata.img'. Make sure all the three files exist. If they don't then follow these instructions exactly and try again.
3. Locate 'fastboot'. On my system I found it under 'out/host/darwin-x86/bin/fastboot'.
   
4. Execute the following commands (I included the outputs I got):
   

$ ln -s out/host/darwin-x86/bin/fastboot out/target/product/dream/fastboot
$ cd out/target/product/dream/fastboot
$ ./fastboot -w
erasing 'userdata'... OKAY
erasing 'cache'... OKAY
$ ./fastboot flash system system.img
sending 'system' (53946 KB)... OKAY
writing 'system'... OKAY
$ ./fastboot flash boot boot.img
sending 'boot' (1418 KB)... OKAY
writing 'boot'... OKAY
$ ./fastboot flash userdata userdata.img
sending 'userdata' (2 KB)... OKAY
writing 'userdata'... OKAY
$ ./fastboot flash reboot
rebooting...

After reboot I had the latest (and not necessarily the greatest) version of Android :-).

My experience with Android (and the device) has been positive so far. I have been updating the Android source code on my machine daily and am seeing quite a few changes being committed every day which is great.

My next goal is to try out the custom firmware by JesusFreke, an xda developer, which appear to be much better than the stock firmware. I will keep everyone posted on how that experience turns out.

Last week Palm announced their much anticipated Palm Pre mobile phone. The Palm Pre features a slide-out QWERTY keypad to complement its 3.1-inch touchscreen display, a 3-megapixel camera with flash, EV-DO Rev. A/HSDPA connectivity, Bluetooth, GPS, WiFi, Bluetooth 2.1 with A2DP and EDR, proximity and light sensor, accelerometer, 8GB internal memory, and runs on their latest mobile operating system, the WebOS. The Pre will be one of the first smartphones to feature wireless charging, achieved using electromagnetic induction and the use of an optional wireless charging dock, dubbed the 'Touchstone'.

While watching the Palm Pre CES launch video, I couldn't help but feel that Pre had features that iPhone could have easily had. The card view makes multi-tasking a cinch and 'Synergy' which brings all your email accounts and contact and calendar information from various sources into one place is not all that difficult for Apple to implement. Maybe in firmware v3.0 along with cut and paste.

WebOS looks very promising. Development for WebOS will be through an yet-to-be-released-to-public RAD framework called Mojo. Support for background apps and 'direct access to the device's capabilities' has been confirmed by Ars.

Slated for release in the first half of 2009 in the US, Palm Pre definitely brings innovation and life back to the struggling company. Here are some positive and not so positive reviews about the Palm Pre.

Personally, I think the CDMA only support (atleast for now) is a bummer. While waiting for Palm to bring out the GSM model, I cannot wait to get hold of the SDK and play around with it.

Update: Good article on Engadget titled 'What Apple could learn from Palm's WebOS'.

QR Codes

I met up with Srikanth at Cafe Coffee Day last week. While we were sipping some overpriced beverages, our conversation went around to the topic of 'mobile tagging'.

The image below explains what mobile tagging is all about.


You just point your phone's camera to a 2D bar code, take a picture of it and decode it. There are several 2D bar code formats but one of the most popular is QR (or Quick Response) code.

QR codes can contain anything from plain alphanumeric text (or a website address or an SMS message) to airline tickets. The Japanese even use QR codes on graves. Check out this interesting article about potential uses of QR code in India.

There are several QR code generators out there including one from Google. Download a QR code-reader for your phone from BeeTagg and find out where the code below takes you :-).