I use an Android every day, and my wife has an iPhone. The absolute biggest thing that annoyed me about using the iPhone after being used to the Android is the lack of a dedicated hardware back button. The problem you describe about an app opening the browser and then trying to get back to the app on the same screen you left it is so irritating in iOS - It's a huge glaring issue that is seamless on Android.
Since iOS4 if you double-tap the home button the left most icon in the application switcher is the last application you were in. Probably not as seamless but it prevents accidental back button presses which is something that has caused me problems on Android. If I buy another Android phone I will definitely try to find one with hardware buttons that are not located directly below the display.
I bet about the same percentage that know about the long-hold of the home button to bring up the task switcher in Android (not many). I was amazed that my wife, who has had an Android phone for a year, didn't know about that one...
It isn't a task switcher though is it? It just lists the apps you used recently, not the ones that are open. AFAIK you need a separate app that is binded to the home button to get different behavior.
Even more fun in the iOS 4.3 devices you can do multi-touch gestures to get to the other apps, home screen or swipe between running apps. Video: http://www.youtube.com/watch?v=wvxSSGUtTYA
This is a deeper philosophical issue. With Android you have to remember your usage history to know what the back button is going to do. In iOS you're never going to accidentally switch to a different app. Once you get used to one philosophy the other will become annoying.
Disclaimer: I'm a long-time Mac user and developer, but these days I mostly write iOS apps. I'm that annoying guy who mutters Cocoa method names in his dreams. I own a HTC Desire, but I've never written an Android application. Not yet, anyway ;)
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?
As an iPhone, Android, and WebOS user hands down WebOS has the best navigation implementation of all of them. Activities are in cards. Cards are stacked in the order you use them. You can go from phone to contacts to webpage in the same stack and you can pick any item in that stack, no backbutton needed. It has a dedicated gestures area which is more powerful than 4 buttons and definitely better than one.
I imagine Android could easily display Activity switching and Activity Stacks as webOS-like cards. RIM engineers quietly admit they stole the PlayBook's app switching GUI from webOS cards.
Google did hire away the designer, Matias Duarte, from HP/Palm. I wouldn't be surprised to see more WebOS-like GUI actions in future versions of Android.
The browser never takes you to a different app and there is a forward button as well if you don't like where it takes you. I'm not saying that iOS task switching is good, I'm just saying there is a reason that there is no global back button. I expect that Apple will make changes to task switching one way or another eventually but it's not going to be with a back button.
That's a nitpicky distinction based on the meaning of "app". The back browser certainly can switch you between applications. A user will be equally "confused" by their screen switching from facebook to gmail as they will if it switched to the photo app or whatever.
I'm just saying there is a reason that there is no global back button
Because as part of the original design, iOS had no particular place to go back to other than the home screen...hence the singular home button...which actually is a global back button of sorts.
On quibble: In Android the back button really seems to serve the purpose of "take me anywhere BUT here". I have no real cognitive sense (generally) of where I am in the stack. I simply hit the back button until I get back to something that looks familiar.
I love these compare-and-contrast articles about developing on different smartphone platforms, but I'm interested to see how the second-tier ones go, as well. I've heard that webOS is a delight to develop on, WinPho is bad, and I'm not sure about Blackberry OS or the other lower-tier ones.
I'm doing Winphone dev right now, so hopefully I can share some insight into it. It's not necessarily bad, it's just restrictive. The APIs right now for silverlight applications on the winphone (the primary development framework, the other being XNA) are pretty sparse. If you want to do something outside of the scope of what silverlight provides, then you're going to be flustered. That said, the WYSWYG (expression blend) editor for animations and basic app construction is the best out there in my experience. On android and iphone I typically just wrote front end by hand. While the drag and drop functionality in xcode was very nice, I felt restricted by it. Eclipse's WYSWYG editor feels like an afterthought rather than a primary feature.
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.
> On android and iphone I typically just wrote front end by hand. While the drag and drop functionality in xcode was very nice, I felt restricted by it.
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.
There was an interesting talk at I/O that focused largely on the Eclipse WYSIWYG tools that I was watching earlier. Having mostly done my best to ignore them before now, the tools are looking in a much better shape than they once were.
I've been developing for mobile for nearly ten years and trust me when I say unless you need to support a particular device avoid the legacy platforms, at least until you have a proven mass market app.
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
Xcode has taken a big step forward with version 4. It still has some teething troubles (it seems to get sluggish after about six hours of being open, at least on my machine), but features like code completion actually work now. Most of the time, anyway. :)
BB is sort of like programming in 1999. You've got an ancient JVM version, so you can't use very many 3rd party libraries. The default widgets are completely style-free so any chroming you want to add is a custom job. Even persistence becomes tricky as java.io.File isn't available.
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.
I personally love how android handles the latest activity window by dragging down the top area. Is there something similar on iOS4?. This and the back button are really good features.
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 haven't researched Honeycomb in detail, but current apps work just fine on Honeycomb as long as you say in your manifest that you support large screens. Bump for example, works just fine on the Xoom without any custom work (obviously we haven't optimize for the tablet form factor yet though).
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.
With Bump 2.0 we decided to throw out 1.x. We are only supporting Android 2.0 and up, 1.x is small enough that it doesn't matter for us anymore. This way we can focus on making the app that works better with a smaller number of differences to deal with.
That said, yes, there are definitely rough edges in 1.x to 2.x, hopefully less so to 3.x. I think only time will tell as things surface in communities like Stack Overflow.
We have got into minor issues with Honeycomb - the new selection/copy/paste in the text areas took our app by surprise. The other thing was TAB key events that don't get fired from the Honeycomb keyboard even if tab is inserted to the text correctly. However these are probably edge cases.
My biggest gripe is that Honeycomb emulator is dead slow, so testing anything on it without a real device is really painful.
This is because the Android emulator is a real emulator emulating an ARM instruction set on your x86 box (it uses QEMU), whereas the iPhone Simulator is a proper port of CocoaTouch to Mac OS X.
I think both of them suck. The Android emulator is slow and the iPhone Simulator is inaccurate[1].
Here's an effort to port Android to x86: http://www.android-x86.org. I see a a 100% x86 Android emulator running on VMWare in the near future. Tasty :)
--
[1] For example, the iPhone Simulator lets you use NSFileManager to create files and directories inside your app bundle. This does not work on the actual device. I ran into this during a demo :|
Interesting, I'll keep that in mind if/when I get to deeper Honeycomb development.
As for the emulator, Android is notorious for it's terribly slow emulators. I've basically stopped using them and only use actual hardware to test on. The emulator is good for surfacing race conditions that only show up on super slow devices tough :-)
As someone who has developed exclusively on Android, this article seems like an interesting read, especially because it is written by someone who has programmed in iOS before moving to Android ("porting" iPhone app to Android). I wonder if the take would be different when I/someone move(s) to iOS from Android.
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 didn't mention it in the article, but I did Android programming before I did iOS. I was doing Android programming before the iPhone SDK came out in 2008. When the iOS SDK came out, I moved to the platform that had real users and phones. Android didn't have actual phones until late 2008.
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.
Interesting to hear the differences between the two platforms re: design constraints. Helps explain a lot about why it takes many other apps so long to develop an android version. Looking forward to a better Android version of Bump, since the last wasn't always reliable.
I actually don't think it's faster or slower to develop on one platform vs. another. The speed of releases you might see from companies probably has more to do with their release cycles and resources they devote to it.
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.
I often hear about important UI changes when porting from iPhone to Android to make the app look more native. Could you (OP or anyone else with the experience) be more specific of what they are? Some examples?
Sure. One of the things that we do in the iPhone app is to open each of our media screens as modals, then when you bump we slide in the chat screen that shows the data that was transferred.
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.
Ok, thanks. It seems that apart the obvious stuff (Menu+Back buttons) it is mostly tweaking the app to use the correct widgets/APIs for the task.
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.
Iphone apps need to display Back, Search, and Menu buttons. With Android there is no need to display them in your app since there are dedicated physical buttons for them.
I was excited when he started talking about the resolution differences but then quickly bummed that he didn't even scratch the surface to talk about just how the changes affected the development.
He did talk about it. He says that the declarative XML layouts make it easy to iterate the UI, but hard to make it pixel perfect, and is therefore akin to web design.
I am the author of the article. What aspects do you think I missed that you'd like to know more about? My first draft was much longer with a lot more details but I was worried about a writing a book instead of an essay :-)
I've been kicking around the idea of rewriting some of my apps for Android and the resolution differences has always been a big worry of mine. As another commenter pointed out you did allude to the Android UI being more like a scalable interface you don't always have control over but sometimes we still have to use pixel perfect designs, even on the web. For using the standard UI elements it makes sense to fit in with a scalable design but I've thought at length about games and how that would work across different resolutions without being able to rely on using high and low res graphics. iOS gives me a lot of crutches to just know what systems I have to support and the shear variety of screens and systems gives me a lot of pause for the layout or number of versions I'll have to package up.
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.
I am not sure how it helps to game developers but it is pretty concise guide for general app development.
We have gone through the screen size adjustments and minor incompatibilites across versions when porting to Galaxy Tab (I have summarized the experience in the blog: http://touchqode.com/blog/008_developing_for_galaxy_tab.htm ) and then when Honeycomb came out.
But more often than not it is our hackiness or vendor fancy tweaks that cause problems rather than the android itself.
If you have an application that runs only on cell phones, you shouldn't be worrying about different screen sizes. Have you used layouts in Qt or any other UI toolkit? UIs on Android work in a similar way. Android will properly scale your UI to different screen sizes, just like a Qt window can be resized without crapping up its layout.
About graphics: Google defines 4 screen densities: XHDPI, HDPI, MDPI and LDPI. You create separate graphics for each of them and import them into your project. Android will automatically pick the appropriate version of your artwork depending on the device your app is running on. No manual work required.
See that @drawable/slate in there? Android will try to find the appropriate version of "slate.jpg" (or "slate.png", or whatever) from one of these directories: res/drawable-hdpi, res/drawable-mdpi or res/drawable-ldpi. If it can't, it'll try to look for the file in res/drawable[1]. So you have 3 versions of the file residing in 3 separate directories.
Don't worry about screen sizes. They don't vary too much anyway. Phones these days lie somewhere between the 3" to 5" spectrum. Not much of a difference for most apps, unless your UI is doing something very special.
---
[1] This is the default project structure; you can probably change it.
I actually really meant this from a UI perspective where the _screens_ from different applications can flow back and forth between each other. But data is an equally important point to bring up.
There's a negative aspect to the multi app ui history model as well though in that its easy to create confusing app launch and back button behaviors. Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser.
Having the ui stack capability across apps is great but as a developer it requires some extra effort to avoid confusing incidents like this for users.
