Vmheader
 

Archive for the 'Programming' Category

Android vs iOS Development: A Developer's Perspective 01/06/2012 at 05:16AM

I avoided Android development for a really long time, primarily because I love iOS and I consider the Android user experience to be a bit rough and I think that turned me off to developing for Android devices. The fact is, though, that Android owns the market share for smartphones and as a mobile developer that means that it's an important area to gain experience in. While switching over to Android I made some notes about differences and comparisons between developing for iOS and Android.

Since I am trying to compare areas of development, I will refrain from doing too much comparison of the user-experience between Android and iOS. However, I will say that my grandma (who can't figure out a DVD player) could understand how to use an iPhone. I guess that's the beauty of all of Apple's products. "Simplicity is the ultimate sophistication" -- Steve Jobs. Okay, back to being unbias.... Here is a list of the areas that I will be comparing:

  1. Accessibility
  2. Learning Curve
  3. Memory Management
  4. Documentation
  5. Creating Layouts
  6. XCode vs. Eclipse
  7. iOS Simulator vs. Android Emulator
  8. App Store Regulation
  9. Other Factors

 

If you are wondering why I didn't include Blackberry in my comparison, it is because I do not think that the Blackberry development nor user experience comes close to comparing to that of Android or iOS. Google and Apple dominate the smartphone market and I do not see that trend reversing anytime in the near future. I question whether or not people that claim they prefer Blackberry have ever even used Android or iOS (sort of like how a lot of people think Windows is better than Mac -- until they use a Mac).

 

Accessibility

Accessibility is a weakness for iOS. If you know anything about Apple then you know that XCode will never be available for platforms other than Mac OS. Eclipse is available on Mac, Linux, and Windows and you can install the Android SDKs on any of those platforms. To develop for iOS, you need a Mac.

While iOS is tied to Apple's devices, Android is adaptable by manufacturers and thus accessible across a wide range of devices and inheritently a wide range of prices. iOS is not available on all carriers and even if it was not everyone can afford to fork out the money for an iPhone or iPad.  Android is accessible to more consumers than iOS and in my opinion that is why Google is the leader in the market for smartphones.

 

Learning Curve: Java vs. Objective-C

Java is a widely known programming language and thus Android is easy for many developers to pick up on. Then again, this means that the market for Android developers is more competitive which could have a negative impact on wages (I would be interested to view a comparison on developer wages between iOS and Android). Unless you have done Mac or iOS development you won't know Objective-C, so the learning curve for iOS is a bit larger than the learning curve for Android.

If you don't know Java nor Objective-C, it will more than likely be easier for you to pick Java up then it will Objective-C. Java is similar to other programming languages, specifically ECMAScript, whereas Objective-C is rather unique. However, I know both Java and Objective-C pretty well and I can say without hesitation that I prefer Objective-C.

This is too short of a post to do a full comparison of Java vs. Objective-C, but the bottom line is that for most developers Android will be a bit easier to pick up on than iOS will be.

 

Memory Management

Many Android developers argue that memory management on iOS is too time consuming. On Android, you don't have to manually manage all of your objects. The Garbage Collector comes around and handles that for you. Well guess what? As of iOS 5, iOS has something far better than a Garbage Collector: it has Automatic Reference Counting (ARC). The rules of Objective-C have changed and a new compiler called LLVM has been added as of iOS 5. Now, iOS developers have to do the same amount of memory management as Android developers do. Here's the difference: the Garbage Collector is a process that runs on your Anroid device to manage memory. This means that the Garbage Collector itself uses up some of your hardware resources. ARC, on the other hand, is a feature of the LLVM compiler. With ARC enabled, the compiler uses rules to insert memory management logic into your app's code at compilation. The concept behind ARC is to have developers write less code without sacrificing performance.

Even without ARC, my personal opinion is that when it comes to mobile development, manually managing memory is way better than having a Garbage Collector running. Hardware resources (memory, drive space, CPU power) on mobile devices are limited. Most mobile devices have only a fraction of the memory an average laptop would contain. If you rely on a Garbage Collector to manage your memory, you will inevitably end up with objects you no longer need sitting in your limited memory space for longer than you need them to. If you manually manage your memory, you can deallocate objects as soon as you no longer have any use for them. The icing on the cake is that memory management in Objective-C is really quite easy. You can get the basics of memory management down pretty fast.

Whether or not ARC is enabled, in my book memory management in iOS beats Android's Garbage Collector any day of the week.

 

Documentation

Both Google and Apple have come up with some great documentation for their platforms. However, sometimes I find that the collections of example code is lacking for Android as well as for iOS. In general, I personally have no large complaints about the documentation for either of the operating systems. I am not saying that either are perfect, though. For iOS I have sometimes found myself stuck when I need to dig past the basics to do something that requires a bit of complexity. An example of poor documentation and a lack of example code is Core Audio. I remember spending weeks trying to do something that should have been rather trivial because I could not find any good examples or descriptive documentation. Android might have a slightly better collection of example code than iOS does. Maybe Google is less concerned with protecting their source code and more open to showing developers how to get things done.

 

Layouts: XML vs xib

Both Android and iOS have visual layout editors. In Android these layouts are essentially written in XML, whereas in iOS they are .xib files. The layout editor in XCode is much smoother than the layout editor for Android. The nice thing about the XML layouts in Android is that they make it easy to reuse code (copy & paste). You never really edit an xib file with a text editor (although I have a few times) because they aren't designed to be edited by hand. I think that designing layouts is about equally efficient in the two operating systems.

 

IDE War: XCode vs. Eclipse

Eclipse wins in one and only one way: it is compatible with Linux and Windows (which we already covered in accessibility). To use XCode, you need a Mac.

Eclipse reminds me of Firefox in that it is slow, bulky, and consumes way too much memory while it is doing way too little work. I find this pretty hard to move past. Eclipse is mainly a Java IDE and if I were doing Java development I would definitely use Eclipse, but when comparing Objective-C development in XCode vs. Java development in Eclipse I rule that XCode is way better. Anyone that has used Eclipse enough is familiar with the following error "java.lang.OutOfMemoryError: Java heap space". I have had Eclipse run out of memory just trying to open an XML file. And even if it doesn't run out of memory it is extremely slow at parsing files. I have heard people say that it is because Java does not handle text well. Well guess what? Eclipse is a TEXT EDITOR! If it can't handle text well, then how can it ever be good at what it's made for? Worst of all it feels like every piece of code in Eclipse runs on the main thread. I have spent entirely way too much time staring at a spinning color wheel while Eclipse is locked up.

Apart from Eclipse being slow, it is in desparate need of a redesign. There is some cool stuff in Eclipse that should be more accessible. Also, I don't want to have to switch to "Debug Perspective" everytime I am trying to debug my app. I want to be able to rapidly develop and debug and I don't want my window to have to change when switching between coding and testing.

 

iOS Simulator vs. Android Emulator

One of the great features of both the Android and the iOS development experience is that you don't even need to own a device to develop an app (although you really should). This is great for testing code while rapidly developing. Not having to install/launch the app on a device everytime you want to test something out really cuts down on development time.

The iOS SDK features a device simulator and the Android SDK features a device emulator. So what's the difference?

The Android emulator mimics both the software and the hardware of a device. You can setup a new emulation device with specific hardware parameters (i.e. the amount of ram available on the device). The iOS simulator only mimics the software of the device and it can theoretically access whatever power is available on your computer. You might be thinking that the Android emulator sounds much more logical than the iOS simulator since it can match the actual performance of a device. Here's the problem: IT CAN'T. The Android emulator is awful at matching the CPU performance  of a device. In fact, the entire experience on the Android emulator is extremely slow. When I launch an app on the iOS simulator from XCode, it installs and is up and running within seconds. In my experience being able to quickly debug code on the iOS simulator and later test on an actual device is by far superior to the development experience of the Android emulator. Sometimes I think that I could draw screens on paper faster than the Android emulator can render them.

 

App Stores

This ruling here is pretty much up to the individual. As we all know, Apple is very strict with their acceptance policies and Google is the exact opposite. One downside to Apple's process is that it often takes weeks to get an app into the store. With Android your app is available almost immediately.

I used to jailbreak my phone all the time so that I could use the MyWi tethering app. MyWi lets you create a wireless network that runs off of your iPhone internet connection. This means that I could use my iPhone as a source of internet for my laptop or iPad. Apple actually recently released a tethering app to the App Store, but it was taken down a day later. I doubt that Apple will ever let this product exist in the App Store, probably partially due to pressure from carriers (since carriers make money by charging users fees to enable tethering on their accounts).

While Apple can be overbearing, I do think that some form of regulation is a good thing. Providing security for the end user and preventing malware is crucial. Probably a medium between Apple and Google's policies would best serve consumers.

 

Other Factors

  • Android is fragmented. There are many versions of the operating system out there. I won't expand on this because I haven't personally ran into any issues with this yet. Android development is a bit more similar to web development in that you need to make sure your app works across many operating systems in devices. With iOS, worst case scenario you have to test your app on about 10 devices (assuming that you want to test on all versions of the iPhone, iPod Touch, and iPad), compared to about 200 Android devices.

 

Conclusion

So which mobile platform is better? It's hard to say. Android has a larger share of the market but developers still seem to make more money off of iOS. I will leave the ultimate decision up to the reader.

[[x alloc] init] is for noobs 11/05/2011 at 05:43AM

Why do I constantly see people writing "[[MyClass alloc] init]"? [MyClass new] is the same thing, so stop writing those ~10 extra characters. Just felt like I had to say something. Noobs.

P.S. it turns out "new" is actually older than "alloc init" but they're still the same exact thing.

P.P.S. I probably wasted more time writing this blog post than anyone has ever wasted by using the "[[MyClass alloc] init]" syntax.