Android applications are structured like web pages, even when you look at them from a developer's perspective. Besides other things, each app consists of a number of activities. An activity is the UI you see on the screen, and there's a separate activity for each piece of UI you see in an app. For example, your Twitter app might consist of an activity for the timeline, another one for sending a new tweet, another one for setting preferences, etc. It helps to think of an activity as a web page and an app as a website consisting of a number of web pages.
When you're in AppX and want to open a document/URL in AppY, you send AppY an intent, which is a fancy word for message. Android then replaces the current activity from AppX with a new activity from AppY. But that's not all. You can directly send an intent to an activity in AppY, or you can send an intent to AppY and let it decide which activity to use for handling it. You can even just broadcast the intent and let Android decide what to do with it.
So, in reality, you're not using "apps" at all. Instead, you're using a hyperlinked collection of activities, each of which just happens to belong to a collection of activities called an app. When you look at it this way, it's just natural that Android has a home button and a back button. Both those buttons work in natural, predictable ways. If I open an unread text message from my home screen and then hit the back button, I'm back at the home screen. If I open my inbox in the messaging app, navigate to the unread text message and hit back, I'm back at my inbox. What could be more natural?
(Also, IMO, the Android API and developer tools make Cocoa and Xcode look like toys. It's like comparing DirectX with BGI.)
Talking of usability: in my experience, Android is far more usable than iOS. It might not be pretty, but it manages to get nearly everything right UI-wise. Less buttons on the phone != better usability. What if your laptop had only the 26 letters and every other function was bound to a double-tap or press-and-hold action? Double tap Q for F1, press and hold M for backspace?
Now keep in mind, I'm a vim guy. I'm by no means a fan of WYSWYG editors, but winphone's one is actually quite helpful. It makes sense though - silverlight was Microsoft's solution to flash, so they built a program that followed the same nonlinear editing model that Flash does. It wasn't a framework that they built for a phone, it was a phone that used an existing framework - and that's the reason for all of it's pros and cons.
Those two are actually very different actions in Cocoa development. From what I remember, when you use drag and drop to create objects, those objects are actually created and serialized when you save the interface file. Creating the front end in code is a very different process in comparison. I have to agree that creating iOS UIs using the Interface Builder portion does feel restrictive at first, but it's actually an amazing tool for creating and using standard UI elements.
http://www.google.com/events/io/2011/sessions/android-develo...
J2ME is Micro Edition for a reason, much of the seemingly simple on other platforms you will have to roll yourself and test everywhere.
BB dev is like swimming through treacle or as one of my colleagues put it "death by a thousand paper cuts without the relief of death at the end".
WebOS is a pleasure for web developers, but when you try and make custom UIs or deviate from the framework it can become a pain quickly
Symbian is thankfully a footnote now
Win Phone is fantastic but incomplete. I.e. not all the api's are there but the bits that are there work well.
I haven't used the latest xcode, but when I was developing for iPhone (2-3 years ago), it was god awful.
I haven't done android dev yet but the feedback I get from friends doing it on Windows is that it is a major PITA getting set up. ..
On the pro side, APIs tend to be more straightforward compared to Android. One benefit is that you can write much of your code in a synchronous style without callbacks or risking the dreaded ANR (Activity Not Responding) exception. Just don't expect to reuse a lot of your code without major modification.
What made you think WinPho is bad? Just curious.
One major pain point is dealing with fragmentation. Of course iOS is no stranger to this, but it seems Apple does a better job preserving backwards compatibility. On Android there are wholesale API changes between 1.x and 2.x, and apparently Honeycomb revamps the entire Activity UI framework. Yuck.
I don't think I agree with the entire UI framework being revamped. Can you point me to something specific?
The Android framework engineers also try often to introduce features that get back ported to older version. A good example of this is the concept of Fragments that was introduce in Honeycomb but has been back ported all the way to 1.5 (I believe).
Apparently the new Fragments API will be (is?) available on pre-Honeycomb devices as a static library, and I'm guessing there will be some compatibility with the 'legacy' Activity API in Honeycomb. Still I'm guessing there will be rough edges and unexpected incompatibilities, as there are between 1.x and 2.x versions.
My biggest gripe is that Honeycomb emulator is dead slow, so testing anything on it without a real device is really painful.
I agree that fragmentation is one big pain point of Android. It needs to be considered even between different device manufacturers, not just API changes, when it comes to things like the camera preview. UI responsiveness is another factor that is a disadvantage in Android, which has to be considered explicitly while developing.
I don't remember much of my feelings of the platforms from those early days because I was in a frenzied coding mode trying to release the first few apps in the App Store. But I do remember being frustrated by the lack of something like a GridView in iOS.
Also a lot of Android developers these days are much newer to the platform than iOS. Thus there is a certain amount of learning involved which can slow down development. As I said in the article, iterating on UI was much faster on Android than iOS which can be a big win if that's where the complexity of the app lies.
Modals mean slightly different things in Android from iPhone, they truly are something that pop up and should be immediately dismissed. So all of our media screens had to be slide in from the right instead of modals so using the back button makes more sense.
Another thing is autofilling out the user's contact information for them if we can. Android gives us richer information about device and user identity (only after we are given permission at download time of course). We can use this to make the process of setting up your contact to Bump a breeze.
Based on various comments about porting I was affraid I am missing some grand user experience pattern that exists on one of the platforms but not the other.
Honestly I should be researching this myself, I just got excited when the topic came up in your article and was sad to see that it didn't answer my every question I've been mulling over for some months now. It was my expectations what were unreasonable and not your articles content.
> One example of a future looking architecture decision is how different applications can flow back and forth between each other.
I think you mean "...how data from different applications..." or something.
