Over the past few months I had the great opportunity to tackle the challenge of learning both the iPhone and Android mobile platforms for the first time as a developer. I had used both previously as a consumer, so it was interesting to finally get a chance to jump in with both feet for a work project.
I have been focused on .NET development in C# for the past 8 years, but originally cut my teeth on unmanaged C & C++ during the 90's, along with a smattering of Java development for college courses during the same time. Both platforms brought me back full circle and in some cases were frighteningly deja vu, especially since we're now 10+ years out from my work in those languages.
The following are some of my observations as a .NET managed code developer building apps for these platforms for the first time.
Frameworks and Languages
It was an absolute blast to learn 2 brand new frameworks in the span of 3 months. If you are a managed code developer and want an easy transition into mobile (this applies until Windows Phone 7 is released), I highly recommend trying Android as your first platform. Virtually every managed code concept from the Microsoft world is translated on Android in one form or another. The challenge is definitely the iPhone, but a very fun one at that.
The language, the concepts, even the message (read function/method) names are foreign and brand new for me as a managed code developer. Actually having to think about object lifecycle and release memory is so last millennium. It is also extremely powerful for the resource constraints we are currently under on our mobile devices. Apple has a great Build and Analyze tool to help you find memory leaks and unreleased objects, along with instrumentation to do the same. Though quite interestingly, virtually everyone warns you not to run memory leak tools on the iPhone simulators, as those tools themselves have major memory leaks that will cloud your data with extraneous noise.
Probably the single most powerful part of iPhone development is the UI framework that is built into the box for you. If you have wondered how so many iPhone apps work in the same manner, it is because Apple has created project templates to use their recommended UI design, along with providing specific UI elements to ensure that consistency. As a developer this is great, as I can build easy to use apps without having to bend over backward to do something that works just like the native Apps on the device. This I believe is one of the strongest unifying elements of the iPhone platform.
Objective-C itself is a very unique addition to the C language. It is very evident to see where some of its features and concepts are a workaround for the limitations of its parent language. It bends over backward to keep true C compatibility, often times to the detriment of the usability of the language for a beginner. Messages are a very interesting concept and are essentially methods or functions that are late bound at runtime. This provides a cool design concept for the iPhone API's that gives Apple some extended flexibility to add Messages to the API that your objects can handle, but at the same time don't break backward compatibility to code that doesn't already implement that Message.
Android quite simply is a modern managed platform for the mobile world. XML is the goo that defines the UI and Java is present in all its managed wonder. Even with the limited tooling (see below) Google manages to throw in small niceties to the framework that just make developers lives easy.
For this project we published a REST web services with JSON data. For the iPhone I had to find a 3rd party framework to do the JSON processing for me, Google has this built in. I also needed to customize the progress bar colors. The iPhone required another 3rd party component, Google required some minor XML definition files with new colors and the progress bars were updated.
Even beyond that Android has great localization support, and automatically pushes strings and other content out into XML resource files that can be changed on a per language basis. This is the first time I have seen this in a platform in a method that literally forces it upon the developer. Typically localization is an after thought and code becomes littered with English language questions and phrases. Microsoft makes it fairly easy to pull those strings out into resource files and so does Apple, but neither do it by default like Google does for Android in Eclipse.
The most lacking part of the framework is really the UI. While very easy to create using XML, it provides such a level of flexibility that it is very easy for developers to quickly devolve their App into a world of extremely poor usability. This is very evident in the quality of applications on the Android platform even some A-list titles aren't quite as polished as their iPhone counterparts.
Tooling is something Microsoft has always done well, especially with their most recent releases of Visual Studio, they have removed virtually any rough edge around sitting down and writing some code. Needless to say I come from a world of being very spoiled and have high expectations for what the tools should take care of for you.
Like most Apple products Xcode seems to "just work". Creating new projects based on templates for the iPhone give a great start project, dragging and dropping files between the Finder and Xcode makes added resources a breeze.
If there is a weak link in this non-IDE, it has to be Interface Builder. Applying the drag, drop, code concepts of Visual Studio leaves you completely lost in Xcode. There is a definite learning curve that requires actually picking up a book and reading through some examples (step by step ones I might add) before you really get the hang of things. Buttons and Views in IB don't automatically link to variables or messages in your code, and require a manual linking before they can be used. Given the resource starved nature of mobile, this is completely understandable, but not intuitive.
Often it is very easy to write some code, add a few variables for your onscreen controls, but completely forget to synthesize them as an IBOutlet or add a message that you forget to decorate with the IBAction keyword. This often leads to a few minutes of confusion as your save, recompile and wonder why you're getting nothing when dragging and dropping your controls in IB to your code.
That also lends itself to another unique aspect of Interface Builder; you actually drag and drop between an onscreen UI components to a visual representation of your code to pair the two items up. Granted this isn't the only method to do such, but is definitely an Apple way of "writing" code.
Before I mentioned Xcode is a "non-IDE". That applies to its 3.x and earlier incarnations. The best way to describe the UI is something like Visual Studio and Adobe Photoshop combined. Some integration, but lots of tools and document windows open everywhere, especially with Interface Builder open. It appears that Apple is well aware of this Window overpopulation as there are some great enhancements in the works for Xcode 4. (http://developer.apple.com/technologies/tools/whats-new.html) I believe some of the specifics are still under NDA, but needless to say the content they showed at this years WWDC looks incredible for the next version of Xcode, very Visual Studio meets Apple.
The biggest drawback in tooling to me is actually that lack of a true device emulator. Instead Apple has created what they call Simulators that essentially run natively on your Mac desktop/laptop. These simulators do not mimic the devices 100%. There are bugs in the Simulators not present on the devices, and scarily some of your code can run without issue on the simulator that crashes immediately on the device. This makes it incredibly difficult to build a wide array of test platforms to test your App on. Instead what we did was start collecting old iPhone and iPod touches to install different version of the iOS on for our testing.
Where Java and the Android framework may have been easier to develop in than the iPhone, Eclipse more than made up its role to increase the level of frustration in actually writing Android apps. I ended up configuring the same MacBook Pro I used for iPhone development to do the Android development.
My number one frustration with Eclipse (Galileo) is its time bombed memory leak. Upon first opening the IDE it flies along swimmingly. Documents open fast, debugging works like a charm, its a great IDE from a speed perspective. Somewhere along 2-4 hours in though, especially when doing any debugging the IDE slows to a snails pace. Documents take up to 30 seconds to open, jumping to the next line of code in the debugger can take 5-10 seconds. Its all really quite a horrible experience. I did find the references (http://www.bahtiyar.org/?p=58) to increase the amount of memory available to Eclipse (which BTW definitely don't go above the 1GB mark, otherwise it seems to crash on start) and to hard code the Java version to 1.6. All these settings seemed to do was to increase the amount of time before the IDE slowed to a halt. Since this appears to be such a widespread issue one can only assume it is being worked on and should be resolved in the not-to-distant future.
Eclipse also has a very primitive user interface builder for Android. There are some bugs, like failing to display a TabHost and TabWidget, that appear to have been around for quite a while, but have not been fixed. Once you get it down though, it is very nice to be able to build out the UI in XML, very much in the same fashion as MS developers we have begun using XAML for UI design.
Finally one of the stranger features of the IDE is the background compilation. While in itself a very nice "instant" feedback while writing code, I did run into a few situations where I introduced an error, either in XML or my code, and I could not for the life of me get that error cleared out. Since there appears to be no method to Clean Targets or Rebuild the Project, the error just hung around. It would only disappear when I changed other code, which seems to have caused the whole project to recompile.
To learn each of the platforms I spent quite a bit of time in the online developer documentation from each company. Both have some great intro and starter documents to get the tools installed and get your first Hello World application built. In addition to these I also read through some developer books (my first computer books in a while). These included:
Beginning iPhone 3 Development - This is an excellent introduction to writing your first Apps for the iPhone
More iPhone 3 Development - An equally excellent add-on to the beginning book. I highly recommend both as a beginner.
Beginning Android 2 - Of the 4 books, this is the lowest quality of them all. It reads more like official documentation delivered by Google than a good introduction book. It is often at too high of a level of discussion to be useful. I'd pass on this and go right to the Pro book.
Pro Android 2 - This is the same level of quality as the iPhone dev books. A recommended starter resource, even though its titled "Pro".
Overall this was a great learning experience for me, and both Apple and Google have great platforms to develop for. Each have their pro's and con's, but both are sure to get better in light of the level of competition in the mobile space. If you haven't checked out mobile development and you have access to a Mac, I'd highly recommend installing Xcode or Eclipse and giving it a try. As I mentioned in a previous post the world is going mobile and as a developer it'll do nothing but benefit you to have some experience with these platforms.