IOS vs. Android from the Trenches
devblog.bu.mp
devblog.bu.mp
The problem with this is some apps already use those gestures for other things.
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?
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.
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.
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.
My biggest gripe is that Honeycomb emulator is dead slow, so testing anything on it without a real device is really painful.
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 :|
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 :-)
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.
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.
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.
E.g,
<LinearLayout
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="@drawable/slate">
</LinearLayout>
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.
> 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.
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.
As an Android developer and a long time Android phone user, I have to say that this can _never_ happen. Do you have a real example?