ObjectListField seems to be overlooked in favor of extending ListField, but to my mind this is much easier to implement. And when time is money, sometimes easier is best.
My son and I trudged through a couple of feet of snow – literally – last Friday to the Lincoln Memorial in Washington, D.C. We practically had the Mall to ourselves – government workers were making their way in to work for the first time in a week and the snow was seemingly deterring other tourists from braving the sites.
As we made our way up to the Lincoln Memorial, there was a very narrow path cleared in the marble steps leading to the top of the temple. A barricade had been partially blocking the way, but had been moved aside. We climbed up the steps, carefully watching our feet and holding onto the rail with real purpose.
We got to the top to find several military men and a park ranger.
“You’re not supposed to be here”, said the Ranger.
They were about to place a wreath on the Lincoln Memorial statue dais for President’s Day. And we were practically the only two civvies up there – aside from the photographers hired to capture the moment.
We promised we would be quiet as mice and found an unobtrusive viewing point.
And captured the moment in video below.
I’m not one to be overly patriotic. I don’t have “we support our troops” magnets or “America: Love it or Leave it” bumper stickers.
But being in that place, at that time, made me feel more “American” than I have felt in a long while.
I’ll pay you tomorrow, the checks’ in the mail… something something…
and Java is write once, run anywhere.
Just like Cobol.
I’m in the process of writing my second Java library for the same online service, TweetPhoto, in as many weeks.
A task that should be – literally – plug and play.
You know. Because the internet is like the same anywhere and Java is supposed to be, you know, one of the Lingua Franca languages you keep hearing about on the intertubes.
Let me be fair here – it’s not Java that’s the problem.
It’s what implementers consider to be essential Java to be what’s at heart.
Let’s take a simple example: ArrayLists. I’ve used ArrayLists in many, many projects. I expected to use them – and did – on my Android project. No fuss, no muss.
When I went to work on a new Blackberry project… hey, where the hell are the ArrayLists?
No, no, no silly n00b – use Vector instead. OK. Fine. No biggee. Almost as simple as search and replace; I just had to change all my adds to addElements. I’m a big boy developer. I can handle it.
OK. Anything else?
Oh yeah – gotta change my Booleans to booleans… and my parseBooleans? They all become trinary statements (you know – those funny ?: things you never bothered to learn in the K&R white book).
All right, all right. Still not crying in my milk about it.
The next one is a total head scratcher. No Apache HTTP library support?
Really, Blackberry? Really?
And before someone tells me I don’t understand the Blackberry Security model, let me just say this: don’t.
What I don’t understand is why companies make arbitrary decisions about what goes into an SDK and what doesn’t. Don’t give me the canards about memory constraints or battery life. Not a single example I gave above has anything to do with that.
Aside from me being a great big fat crybaby in this post, I am surprised that I AM surprised at running into this type of nonsense on a platform that is designed to do away with exactly this type of nonsense.
Nonsense.
Anyway, wiping away my blubbery tears and getting back to work.
I’ve had the pleasure of working on two side-by-side streams of development for the same app on two different platforms since January 1 – the new TweetPhoto applications for the iPhone and for the Android (see screen grabs below).
TweetPhoto for the AndroidTweetPhoto for iPhone
First of all, let me say that from a developer perspective, I’m one of the most platform agnostic people you’ll find anywhere. My philosophy is that money is green, spends the same anywhere, and if someone wants to build something on their favorite platforms of choice and needs someone to develop for them, then that platform is now my de facto “favorite development environment ever.”
Fact is, if one sticks around long enough, you outlive whole sets of tools, operating systems, and methodologies. That certainly has been true in my career; while I lovingly still have my IBM 360 yellow book and can still recognize a fair subset of Hollerith on sight, it’s almost as embarrassing as watching The Who play the Super Bowl to talk about it.
Wandering sidebar aside, the past six weeks have given me a fantastic opportunity to compare iPhone and Android, side by side, on the same problem set and see how the two environments stack up.
The verdict?
There are things about each SDK I really like… and there are things I really dislike equally.
In fairness, my experience on the iPhone SDK is much more extensive than on Android.
Even so, putting together the exact same feature set on the two platforms points out where one platform shines over the other in terms of ease of implementation and execution.
All of the opinions below are 100% subjective and are my own. If you have a contrary opinion, fine. I don’t care. Call a talk show or write your own post.
Development Environment
For the iPhone, you really only have one choice for developing apps – XCode. For Android, I chose to use Eclipse and the Android plugins for Eclipse.
The Apple experience is tight, feels integrated out of the box, and just works. The iPhone emulator is fantastic and works almost like the real thing.
Eclipse, since it is the Swiss Army Knife of Java Development, is not as integrated – out of the box – as XCode with regard to it’s Android implementation. The Android Eclipse plug ins work great and are powerful. I really dig Eclipse’s “Quick Fix” feature for including imports I need and recommending ways to fix broken code. What I don’t dig is starting and re-starting the various emulators when trying to debug a running Android app. Which I did tens of times each day when Eclipse lost full connection with the emulator I happen to be running.
Even so, I found the tools for controlling the features of the emulator (or should I say, emulators – you can configure an emulator AVM for each targeted device type and OS level you want) on Android to be much more powerful than the control one has – or doesn’t – over the iPhone emulator.
In a nutshell, someone proficient with Eclipse and who is a half-way decent open source / Java developer – who has never developed a mobile app – will be able to jump in and crank out working code quickly. Apple, especially to a newcomer to Objective-C, is a pretty tough slog for the beginner.
Honestly, it took me about six weeks before I really felt a mastery over Objective-C. From a standing start to finished app, it took me under three weeks to develop a professional grade Android app. Enough said.
Getting Apps to Devices
The whole process of getting certificates, creating provisioning profiles, and the whole Apple approval process is pretty daunting to a newcomer. Remembering back to when I first started to developing iPhone apps, and the time it took me to get up and sprinting, Apple’s setup is a pretty damn big barrier to entry. Heck – I still run into provisioning and certificate problems switching between developer accounts when developing for multiple customers on the same development system.
Without going through the Apple App store, your only option is to use Ad Hoc provisioning, which limits you to 50 devices per Ad Hoc provisioning profile and you have to collect device UUIDs to make it work. Factor in having to distribute new profiles each time a new device is added to keep everyone in sync and it quickly can become a real pain, especially if many QA testers are involved in a project.
For Android, you basically sign a .apk file and you’re off to the races. You still have an approval process to get on Android Market – the analogue to Apple’s App Store – but there is absolutely nothing standing in the way of you distributing your app on your own without Google standing in your way.
Advantage to Google on this. It’s worlds easier to get an app out and onto devices under Android than iPhone.
SDK Feature Comparisons
OK. Getting the nuts and bolts of making apps for each platform behind us, let’s take a look at how coding for each device stacks up.
Documentation: Android’s documentation is there… but woefully lacks useful examples in a place handy to the API call I want to make. My least favorite sentence to read in any discussion / support forum of any ilk is “well, if you check the sample apps, you’d see…” You know what? I don’t have time to read every line of every sample application. You want to see an easy to use document with ready-to-use sample code should be done? Look at the PHP.net site. It should be that easy to see how to use API calls. Apple is not much better in this regard, but on the whole the iPhone is documented much better than the Android developer site. But I’m not a huge fan of either, truth be told.
And while I’m screeding here (is that the proper pluperfrect subjunctive?) let me just say that it’s a good thing that Google exists, because I had to Google a shit-load of example code from about a hundred different places for stuff that should have been trivial to find – but wasn’t. Like camera operation. See the next section.
Using the Camera: The iPhone has a well documented interface for using it’s phone, and for selecting photos from it’s library – the image picker. Android doesn’t have a pre-packaged all-in-one interface for doing this. There is a bare bones example of how one ties into the camera, and a poorly documented – as in I had to find the solution in the wilds of the interwebs – of how one browses the camera’s gallery for photos already taken.
Let me go on the record as saying that in terms of overall code, it took a lot less code to do camera operations under Android than it did under Apple to do the same task – but that for Apple, it took me maybe two hours to get right while under Android it took me the better part of a weekend to find the right solution, and found somewhere other than on the Android developer site. The image gallery code turned out to be like two lines of Java to implement, but is almost criminally under-documented.
Screen Design: Apple – hands down – has a better screen design tool in Interface Builder than the screen design tools available under the Android SDK. I wound up doing most of my screen design using the underlying XML for each screen anyway. Having said that, creating screens to display suitably for portrait or landscape mode under Android is ridiculously easy when compared to what you have to do under iPhone. And before someone says, “well, it just works under iPhone as well”… child, please. Only if you finagle each design element individually under Interface Builder, subclass the tab controller, capture device orientation for subviews that don’t respond to the “should change orientation” messages. By a mile, this is something that Android did very well compared to Apple.
Maps: this is something that Google failed miserably at, in my very humble opinion. Under iPhone, you add a MapView and it works with just a little additional setup for scaling and setting your location. I got my first MapView in an Apple app working in like 10 minutes. On Android, you have to get the MD5 fingerprint of your keystore (where the certificate you sign your app is stored) and apply for a Google Maps key. And not just one key, but two keys – one for your debug keystore and one for your production keystore. Which means that you have to manually change your keys between the debug key (so you can see your maps on the emulator) and between the production key (so you can see maps on real devices). This is a total pain in the ass and is one more thing to forget before staging an app going out the door. All in all, it took me an hour before figuring this all out and getting my first map working on Android.
Permissions: Android has many permissions that can be set, many of which you don’t know you need until you try and run your app and have it fail inexplicably. For example, internet access is disabled by default (on a mobile device? yeah. I know). While I understand the beauty of this type of control, and that they are being safe rather than sorry, having to accidentally discover which permission is keeping my app from working is a not so pleasant experience. The iPhone SDK really doesn’t have anything like this in terms of hobbling application capabilities on such a wholesale scale (push notifications being the one notable exception).
Application Manifest: Under Android, each screen (or Activity) has to be explicitly declared in the Application Manifest – more or less a map of your application’s permissions and activities – or your app will bomb when you try to invoke that screen. I would say that this is the cause of most accidental crapping out that happens when putting apps together for the first time – forgetting to put a new screen into the manifest. Under iPhone, you typically run into a similar situation by trying to load the wrong type of view controller into an improperly defined variable – but it’s not really the same thing. Under iPhone, you know you need to load a view a certain way, and if you’ve defined the view it should work. it’s not at all intuitive that you have to remember to add your new screen class to the application’s manifest file. Or else.
Overall verdict: each SDK excels or fails because of the elements upon which they are built (amazing grasp of the obvious duly noted).
Because Objective-C is, at its heart of black hearts, just C with some objects bolted on, everything basically has to be built from scratch, especially tying UI elements together. Because Android is Java based, and most of the screen design and integration “just done” for you, the time from zero-to-application running is much smaller under Android than under Apple.
My one huge complaint about Android is that a developer has to manually bring several pieces together to do anything productive, whereas with Apple it’s download and code.
In truth, if you’re a Java developer, you’re gonna be right at home with Android and curse the Apple fan boys. If you’re an Apple fan boy, you’re gonna poo-poo the open source dweebs who have to support all of the forks that the Android environment will be challenged with as set makers try to differentiate features between their competitors.
And if you’re a developer like me, who’s just trying to pay the mortgage, feed the kids, and keep tuition current, you just hope to stay even.
Logorrhea 