Android vs iOS from a developers viewpoint

I have been writing programs since I was a child, literally. Since I was about 8 years old I’ve been coding as a hobby now I do it to pay the bills. I started off with BASIC on the C64 and Apple IIe, then moved on to Qbasic in DOS, LOGO (an educational variant of Lisp, apparently), C, C++, Fortran 94 (in college), HTML, Javascript, PHP and SQL (if you can call that programming). For a long time I dealt only with procedural code but I’ve moved to OOP in the past few years. The point is that I’ve been around the language block enough to know what works and what doesn’t. To be honest I feel a bit spoiled by PHP since it handles casting so effortlessly and because it has so many useful higher level functions that when I stepped into the world of Java and Objective-C  I was taken aback at how basic I had to keep my concepts.

I dove into Java first and found that the similarities in syntax to JS and PHP comforting and familiar. The forced OOP is good training for someone who has to translate procedures into methods in their brain. I had looked into using Eclipse previously for PHP development but at the time it seemed like overkill for most of my projects. After using it for a week I don’t know why the hell I didn’t start earlier. If you’re reading this and you’re intimidated by the complexity of the IDE, take a deep breath and dive in- you won’t regret it. The fact that all of your objects properties and methods are immediately referenced and organized allows you to make much, much faster and more complex code than if you’re using a text editor (I used gedit previously). Aside from that; the debugging, testing, organization, version control and update process are indispensable. You can get by without an IDE but it’s kind of like not driving a free Ferrari because you don’t want to learn to drive stick. But- Eclipse is not Android.

Android is basically a collection of APIs for Java. Initially I found that I was a little lost in how Android worked but once I started thinking of it as a giant object hierarchy it seemed to make more sense. I was able to get the Magic Infinity Ball app up and running in about a week (for the free 1.0 version) and fleshed out to a point that I liked it in about 2 more after that. Since this was my first OpenGL project I had 2 learning curves to overcome but my impression is that Android is a fairly easy platform to develop for and I feel confident that I could hack my way through an arbitrary project spec and come out with a working product in a reasonable timeframe. Pros and cons that stick out for Android break down like this:

The good for Android:

XML inflation - Android allows you to use XML to describe your views and objects as well as store strings and other important information (Manifest files, string lists, etc.) It’s not compulsory but it helps keep you from repeating yourself and can definitely clean up your code. I generally stay away from XML in web work because there’s so much syntax vs JSON but for more complex data it makes sense to have it organized.

Garbage collection – Coming from PHP and not having touched C in a decade I don’t even think about memory management anymore. I don’t want to. I know that GC can be expensive but the luxury of not looking for leaks is worth it as a developer. Most users won’t notice a difference and if you really think that to-the-bit memory management is an important part of modern programing you can still do it.

Familiar syntax – I jumped right into Java from PHP/JS and the syntax and structure were close enough that I was able to write my own classes and methods in the first hour. I don’t know if there’s a name for the structure of function(arg1, arg2){ code;} but it seems like it’s the most common and understandable syntax.

Intents - This is a unique feature of Android that I haven’t seen much press about, but I think it could end up being very important. Essentially intents allow apps to start other apps and send them information. Sounds lame eh? So far it is- mostly because the available intents are pretty basic (browser, maps, call, mail, music, etc.) but once the app ecosystem starts getting filled out and there is some standard for naming and calling intents you have the foundation for a complex and powerful interaction.

The bad for Android:

Documentation – I know that developer.android.com is a large resource but I find that there really isn’t much information there that’s useful to the average programmer. A good example is the new Licensing procedure- three is one page of instructions and an example implementation but I’ve found that the documentation doesn’t tell me enough about how to use the code. I end up looking back through the source and reverse engineering what I want. Which brings me to the next downfall of programming for Android-

Examples – there are simply not enough examples of working code to be able to find something close to what you want to do and reverse engineer it to your specs. E.G.  for the Magic Infinity Ball I had to have a normal 2-D canvas drawn over a 3-D openGL surface (I know this is expensive and slow and I may change it but I wanted to see if it could work). There was an example that used a similar technique in API demos but looking into it I couldn’t find any other examples. I ended up trial-and-erroring my way into it.

Fragmentation - I haven’t had any problems with fragmentation yet because I’ve intentionally avoided incompatible features beyond 1.5 but that’s a problem in itself. As more advanced features are added in future versions (openGL ES 2.0 ?) there will be some tough choices to make for developers and it will probably come down to numbers in the end.

This summer was my first time using Objective-C and really didn’t want to hate it. I know it’s a 24 year old language that hasn’t really changed much since the days of NeXT but I intentionally put aside any reservations, went out and got a book (The Big Nerd Ranch Guide to iPhone Programming) and  dove in.The first thing I noticed was the syntax. If you think your grandmother is wordy, you haven’t met Objective-C. I know that some people find it comforting to list the names of each argument each time you call a method but it seems redundant to me. The architecture of the language, however, seems to be very lean and efficient. There are is little opportunity for error since everything is so tightly controlled but it seemed like much of the freedom and creativity I can feel when I write code was lost to fighting with syntax and Xcode. There are some methods that are available for iOS that include time-saving functionality but seem like they restrict your options especially in how your views work. Overall it seems like if you work exclusively in Objective-C you will probably be comfortable and fast enough to compare with other languages but if you get used to another approach you may find it very hard to translate your thoughts into bits.

The good for iOS:

Lean code – The structure of Objective-C lends itself to paced and intentional code that doesn’t leave much room for error. This means that your app will probably run more efficiently but will probably also take longer to write. The forced memory management also helps wit this but given the option I’d rather have a GC and slightly slower code.

Higher level functionality – this is probably a temporary advantage as more libraries and examples are developed for Android but there are methods for calling URLs and 2D openGL that saved me who knows how much time. There are a lot of legacy functions from NeXTSTEP that are still used (every method that starts with NS)  but the ability to, for example, make a swipeable multi-page app quickly is an attractive aspect of developing for iOS.

Documentation – Objective-C has superior documentation, although it sometimes gets in the way when you’re doing something fast like looking for argument options. Documentation is like money or food- I’d rather have too much than to little. You can always Ctrl-F your way through it but if it’s not there you can’t. I found that each method has an appropriately verbose description, notes, and sometime examples.

The bad for iOS:
Wet – One of the cardinal rules of programming is “Don’t Repeat Yourself”. Every time you copy and paste code from one part of your project to another you increase the maintenance load and introduce a place for errors to occur. Objective-C requires that you repeat yourself three times in two separate files to declare a property. That sucks. Don’t even try to defend it.

Wordy – I was surprised at how much I had to type to get anything done. I think there may be some defensiveness among iOS-only developers about this for example in the book I bought (pg 23-24) there is a specific comparison they make for a line in Objective-C

[arrayInstance replaceObjectsInRange:aRange withObjectsFromArray:anotherArray range:anotherRange];

which they claim would look like this in Java

arrayInstance.replaceObjectsInRangeWithObjectsFomArrayRange(aRange,anotherArray,anotherRange);

I have never run across any method with a name like that anywhere but Objective-C. It’s not necessary and it makes your code base hard to read. The book claims it makes it more clear but hovering over a method name in Eclipse calls up the full description of the method and arguments if you need them. The Objective-C approach strikes me like someone writing the definition of a word from the dictionary each time they type it.

Memory Management – I know this speeds up performance but it’s marginal and the interference with the creative aspect of writing code makes it a pain in the ass. I understand there is a plan to implement a GC in a forthcoming version of iOS and I think that reflects the feelings of a lot of developers who are frustrated with chasing leaks.

Mac Only – This is pretty obvious and has been covered in other places but the fact that I had to drop $500 on a new Mac mini for the privilege of using Xcode is disappointing and makes me resent Apple for allowing development in other languages a month after I bought it.

I can’t really say that one platform is better than the other but I can say that I find Android much easier and more intuitive for development. Now that Apple is allowing other languages I may look into alternate approaches MacRuby for iOS? that may allow faster and easier development. Those are just my thoughts on the matter, if you agree or disagree let me know.

-T. Markle