Xcode and Android

Posted: May 4th, 2010 | Author: Julio Hernandez-Miyares | Filed under: Mobile, Technology, xcode |

Xcode

This is not necessarily an Xcode versus Android post, if it were , it would be a long post. I actually use both (though am more familiar with the Android java centric model based on past experience) and I am enamored to the extent one can be enamored of integrated development frameworks of both platforms

Being a normally fickle person when it comes to these type of things, my “enamored” meter is recently leaning towards Xcode. The reason is simple. Even though my familiarity with Objective-C needs a lot of addressing vis a vis java, Xcode’s InterfaceBuilder draws me in as a convert. I am not prone to wanting to deal with layout issues of any sort. Just not in my dna. Mostly result of a lack of patience of working through the grunt level but critically important aspects of having a well tailored, crisp UI where things line up , the colors make sense and appeal to the user even on an unconscious level and the application’s interface holds together following explicitly documented and promoted style guides. Of course, InterfaceBuilder doesn’t have any magical charms that takes a poorly thought through design and make it work aesthetically. That would be asking too much. Nevertheless I can take something produced by someone expert in design for mobile devices and quickly translate it to an artifact that closely resembles what has been provided.

I feel quite at home with Android’s version of an InterfaceBuilder, defining a layout via XML and with it’s rudimentary drag and drop of UI artifacts unto a Window canvas but I generally spend most of my time dealing directly with XML to flesh out the UI and then tinkering with the directives to make it look right. The layout view helps of course and I find myself in it often enough. Nevertheless it does not compare to the power of Xcode’s Interface Builder with it tight coupling of device style guides, frames and arrows that show how well centered visual objects are to each other and to the container itself and that visually guide you to get it just right without guess work. Additionally , connecting the visual components to the actual code objects that express the purpose and functionality of the visual components has a much more natural feel within Xcode’s InterfaceBuilder. All of the class objects are defined in header files ie *.h and then through drag and drop operations those objects can be connected with their visual counterparts including events that flow between exercising the UI artifacts and the class methods that implement the behavior.

From a personal perspective and therefore less meaningful , going for the Android development environment is my greater familiarity with java. Once becoming familiar with the pattern of typical Android development which had a relatively steep but short lived curve, becoming conversant with Intents and Pacelable and how they wire the application together, the language never got in the way. Objective-C is in the way not because of any inherent deficiencies but solely because of the less familiarity with it’s syntax then anything else. Once I become comfortable with the syntax, I expect to be more fully drawn to the Cocoa/Xcode