Perception is truly reality. The way we see the world shapes how we look to solve problems. It’s with that grain of salt that I offer up this response to Mr. @JonathanPenn’s tweet to substantiate my claims on the interwebs this morning. Boy, I hate getting into these messes but he’s right to call me out and clarify. Here’s our convo:
With that history you must know that I spent years in .NET and C# so Java is going to seem like second nature to my eyes; rather than, say, a C++ programmer who will, likely, see something familiar in Apple’s Cocoa/Obj-C environment.
That said, my comment takes the following into consideration…
Java is dominant right now (stats!). In the Enterprise, they’ve got a pretty large hold on the development community and love it or hate it, that lowers the barrier of entry to developing on Android. Most Java developers will be immediately comfortable with the conventions laid out in Android’s development cycle and given there’s an exceptional Eclipse plugin for Android development Java developers don’t need to learn much more than Android’s specifics in their own language, IDE and platform of choice.
There’s a mountain of Java tutorials available. Even if you’re new to Java you’re going to be hard pressed to miss out on the latest and greatest information that the platform has to offer. My searches for information on Cocoa development have met with wildly differing opinions and little consensus. In fact, I was in the C based API on my sample app to play/manage sounds until Jon mentioned there was an Objective-C based API that could do the same thing. Even Apple’s documentation was wishy-washy on the subject until I took the time to read the Cocoa Touch programming guide for Audio (not a fun read, BTW) that it even mentioned the class Jon pointed out.
On a 1-1 basis Android’s frameworks seem to be providing developers simple abstractions to every possible task that you’re going to want to perform on the device while Apple’s Cocoa Touch frameworks seem to be a mess of improvements over Cocoa, missing abstractions and idioms are published by Apple and not driven by the community using them. AGAIN- that is conjecture but that’s what I’m seeing.
Take, for instance, the following snippets to load an internal sound file reference and play it. First iPhone -
NSString *soundFilePath =
[[NSBundle mainBundle] pathForResource: sound
ofType: theType];
NSURL *fileURL = [[NSURL alloc] initFileURLWithPath: soundFilePath];
AVAudioPlayer *newPlayer =
[[AVAudioPlayer alloc] initWithContentsOfURL: fileURL
error: nil];
[newPlayer prepareToPlay];
[newPlayer setDelegate: self];
[newPlayer play];
See, it’s not complex. The syntax is simple enough (for the AVAudioPlayer class, this is not the C API which is far more complex) but things like getting a reference to an internal URI is 2 lines of chunky code that create references that I need to track now. It’s not bad, but there should be a simple way to load our references.
Let’s compare that snippet with the Android version.
MediaPlayer mp = MediaPlayer.create(this, R.raw.mySoundFile);
mp.start();
That’s it. I’m not splitting hairs over brevity; that’s not the point, the point is that the abstraction seems to be in the right place. We know we’re going to play sounds on a device. We know that those sounds are going to be local or networked. These are clear points of abstraction in OO and should be provided to the developer (IMHO).
From my perspective I get to tell the right objects to do what I want them to do and the details and minutia are encapsulated behind a nice API. If we’re on the same topic here are 2 equally good APIs first from iPhone and then from Android
Taking a photo with iPhone (in main.m)
UIImagePickerController *picker = [[UIImagePickerController alloc] init];
picker.delegate = self;
picker.sourceType = UIImagePickerControllerSourceTypeCamera;
// cruft leading to our delegate implementation...
-(void)imagePickerController: (UIImagePickerController *)picker didFinishPickingImage(UIImage *)image editingInfo:(NSDictionary *)editingInfo
{
// now I have image reference I can use! Sweet!
}
See, there’s an operation that I know I’m going to need to perform on a phone equipped with a camera. Once you’re familiar with cocoa’s delegate/callback system then doing something with the camera is that simple. But still, I’m interfacing with a Controller object and not the Camera or “media” object. From an MVC perspective Apple’s controllers seem pretty heavy and try as I may there’s something icky. The Abstraction is there, though which is my complaint with many of the other functions I’d expect an always connected device to abstract. Let’s look at Android’s API for doing the same thing.
Taking a photo with Android
Camera camera = Camera.open();
camera.takePicture(null, null, new PictureCallback(){
public void onPictureTaken(byte[] _data, Camera _camera){
//Handle the photo
}
});
So, lines of code aside they’re very similar but the Android object API is clear and uses the same idioms it has established with other objects in the system. There’s no muddy “is it a Controller or Model” confusion. To me, that’s an simple OO encapsulation that provides an intuitive API. AGAIN: my eyes, my perspective and my opinion.
For the last few points, before I go back to exploring both of these GREAT platforms. Things that have me more interested in Android at this moment than iPhone…
1: Android is open. Which means there’s a greater chance that your app will be seen on a diverse set of devices. This is a blessing and a curse. You’ll be required to handle such discrepancies but again, Google seems to have abstracted those decisions into small questions you can ask the platform in one method. But you will have to be concerned about it and I can see a legion of experts born from this very issue. Good knew is you can sell or give away your apps on your terms. Not Apple’s.
2: Testing. Java has better support for current BDD/TDD methodologies. I’m going to state conjecture as fact here. I can’t find a great BDD framework for Obj-C and who cares if I can’t use it well in cases where I’m testing C code.
3: Memory Management is a solved problem. Google knows it, you know it. the C champions will always lay claim that Garbage Collection is slower than their own hand crafted memory management techniques and that may, in fact, be true. But by what degree? What about line of business application developers? They know the value of one less thing to worry about; one less thing that can go wrong. I know obj-C 2 has an opt-in GC but I never see it in use on the iPhone and I’m not sure why. I assumed it wasn’t supported, again, someone please let me know in the comments if this is wrong.
In the end, everything is perspective
As one who primarily has developed line of business applications and the bulk of that on the .NET platform or in Ruby, Google’s Android platform seems directly poised at the GTD crowd and Apple’s iPhone seems hell bent on restoring C++ and it’s superset Obj-C to the forefront of Alpha-Geekdom. Both are great approaches but when you couple the innovation coming out of the Android devices, the open source ease of startup, tooling support and articulate APIs; Apple needs to continue to innovate on the development side as well as the consumer side.
Apple is, hands down, the reason we’re even interested in this comparison. I love my iPhone. I’m certainly not giving up on my goal of getting in the App Store with something, ANYTHING. But I must say, if they are not cognizant of the power that Google is providing developers they may see folks piloting, prototyping and promoting Android over the iPhone.
I don’t know if it’s time for the Cocoa community to build a better boat or Apple’s but somehow, to me, that’s yet another solved problem and therefore another win for Android.
OK, Jon. I await your post clarifying all of this up for me on the iPhone side and even better, I CANT WAIT to pair with you on iPhone fun at CodeMash! ;)
