Monday, January 16, 2012

Learning iOS from an Android Developer’s Perspective – Part 1

androidvsiosOver the last year or so, I have spent most of my programming time (at work and at home) improving my skills with Android. I picked up Android because, at the time, I didn’t have access to a Mac, and I really didn’t like the idea of having to pay Apple just to develop software for iOS (although it would have been nice to write some apps for my iPod Touch). Once Android came around and it started to turn out to be a real competitor to iOS, I jumped in.

Within the last few months, I have had the need to convert over some iOS code over to Android. Even though I have a decent amount of experience with C programming, understanding what is going on in a simple Iphone application took more time and too many questions to be worth while.

I’m sure the opportunity to check out some iOS code will come up again. So recently I picked up a cheap Mac Mini and this iOS book. My goal is to be able to understand iOS well enough to  convert between the two dominate technologies with ease. After reading the BNR’s iOS book, here are my initial thoughts about iOS:

Initially, iOS is easier to pick up

The Model View Controller pattern that iOS follows is much simpler and easier to grasp than Android’s Activities/Services. This model allows anyone to pick up the SDK and understand what the basic meaning behind any given object is. However, the ease of the iOS model is offset by Objective C’s syntax.

Even the most basic Hello World problems for iOS contain a ton of braces. It’s very daunting to look at, if you’re coming from a Java background. After a bit of time, and once you grasp the idea that objects are sending “messages” back and forth and braces are used to send any sort of message, the syntax of Objective C becomes much clearer.

UI Design is much simpler

Creating UIs in iOS is really straight forward. But having to manually connect Views in an xib file (what iOS uses to store UI details) to your source files before run time is pretty nice. It removes a good amount of boiler plate code that Android has, which involves initially hooking up to your UI.

Designing UIs is obviously going to be much easier for iOS just because of the device count. You’re only looking at a one screen size for the Iphone and one for the iPad. Coming from Android, this is a huge plus. Designing interfaces for a countless number of devices can soak up a ton of time. Having manageable hardware differences between all iOS devices is certainly a big strength of the platform from the perspective of a developer.

Memory Management isn’t so bad

Memory Management is always brought up as a negative about iOS. From my initial thoughts, it really doesn’t seem that bad. For iOS, every object that you create has a counter. An Object’s memory counter is a simple count of how many objects are actually using your object. Objects that have a memory count of zero are reclaimed, and their memory is recycled.

It’s certainly nice to not have to worry about memory so much in Android, but as long as you keep track of your retain counts for a particular object, you should be good to go. Encapsulation is required to keep memory managed correctly for iOS. You always need to know where you are in a given program.

Everything isn’t so rosy with iOS, though. Android does have some key benefits over Apple’s system. Stay tuned for Android’s strengths over iOS.

3 comments:

  1. Nice writeup, starting from iOS 5 you also have ARC (Automatic Reference Counting) to simplify memory manangement. No more retain,release and autorelease anymore unless you want to develop for devices with a lower version than iOS 5.
    I do not know about Android's documentation but the documentation you obtain from Apple is quite extensive.

    ReplyDelete
  2. Not a word about Xcode versus Eclipse?

    ReplyDelete
    Replies
    1. Sure. XCode starts out with an advantage, in that it's designed only for building iOS and OS X apps. It comes packaged with the simulator for iOS apps, and it has a lot of templates for different kinds of projects (apps, libraries and so forth). It comes bundled with really good developer documentation and really good autocomplete capability, and it leverages that autocomplete capability to let you spit out boilerplate methods and #pragmas with just a few keystrokes. Eclipse is designed to be more general and offloads a lot of work on its plugins, which is good and bad. (I have had to work on web pages before that contained HTML, Javascript and embedded PHP (yuck!) and three different syntax checkers running at the same time brought my little 2Gb Macbook to its knees.)

      Delete