An Android user tries out the iPhone
aaronstaley.blogspot.com
aaronstaley.blogspot.com
This is compared with a iPhone 3G, which already has somewhat pokey UI performance compared to the 3GS. On Tuesday we will likely see an even faster CPU running the same codebase. Apple is moving the goalpost for UI performance seemingly faster than Google can keep up.
It is IMHO one of the main failings of Android - the UI is pokey in places where it will significantly and negatively affect adoption rates and user behavior. Scrolling is a pain on a Nexus One (haven't tried Froyo though, so...)
But it's comparing with a HTC Hero. While a year younger than the 3G, it's still not a "modern" android phone (not that your argument is completely wrong as it does seem, from the reviews I read on e.g. the N1 or the Incredible, that this impression of UI slowness/unresponsiveness is still there)
> It is IMHO one of the main failings of Android - the UI is pokey in places where it will significantly and negatively affect adoption rates and user behavior.
I think a bigger issue is the interface's customizability, leading to HTC shipping its own Sense UI rather than working on improving the "main" Android UI (by folding their improvements upstream)
You can't make statements like that until you have a Nexus One running Froyo side-by-side with the new iPhone. Google just introduced a newly optimized Dalvik Virtual Machine, and I expect it will be quite competitive.
So Froyo improves speed in applications, but doesn't improve UI responsiveness much?
Would make sense if most of these improvements come from the JIT: UI stuff (especially responsiveness issues) generally isn't about tight loops, so the JIT compiler wouldn't help much.
It's worth noting, though, that several of his major issues with the iPhone will disappear with OS 4.0, such as undesired screen rotation and lack of app switching (though only for 3GS or newer phones). The mail app will also get improvements like conversations, though I don't know how good its implementation is compared to Android's. I wasn't particularly impressed by it.
Likewise. On the other hand, I find interesting that (I think) he compared the iPhone's mail application with Android's GMail application. I was under the impression that Android's own mail application (for everything other than GMail) was less than stellar, but that it would be a better comparison basis (general-purpose MUA)
> The mail app will also get improvements like conversations
I was under the impression that it would only provide threaded view (much like Mail.app's own), which is a far cry from GMail-type conversation views. A nice improvement for e.g. mailing lists, but not the same thing as GMail's convos.
You're also right that he compared iPhone Mail to Android GMail, which offers a better experience than standard Android mail. On the other hand, the iPhone Mail interface doesn't get any better if you use MobileMe. Using MobileMe would have given him the equivalent of Where's my Droid?, though.
Probably, the outbox might have a different structure than the inbox, and lack some kinds of IDs.
> On the other hand, the iPhone Mail interface doesn't get any better if you use MobileMe.
Absolutely (well I think you get push support, but that's about it), and I think this here is a core difference between Apple and Google: with Google, the Service (Gmail) is given a seat front and center (its own MUA) because it's what Google "sells", whereas with Apple the service (MobileMe) is really nothing more than a perk, it doesn't have any kind of primary status on the device, and it's not expected that it be the main service for users of the device.
It should be trivial to associate the messages the mail client sends to the messages it gets from a server. If nothing else, you have the full original message.
It would also be valid to point out that Android can't sync with iTunes - if you are an extensive iTunes user, music transferring on the iPhone blows away Android's.
Also, I'm curious what about the app switching is more poorly implemented than Android's version of the same?
For apps that start fast (notepad), this is no big deal. But for things like the browser or skype, it is. It takes 4 seconds for him to switch back to swype:
http://www.youtube.com/watch?v=ThkbDcZ_9-k#t=2m30s
This is also seen when switching to the browser near the end of Techcrunch's video: http://www.mobilecrunch.com/2010/04/08/first-video-of-iphone...
The problem to be solved is how to support background processing of 3rd-party Apps without draining the battery.
Thus we are trying combinations of call-backs and App hibernation techniques.
Battery life is more important to me and I suspect most other smartphone users.
What is your evidence for OS4's multitasking being Poorly Implemented?
I recall reading an article linked from HK a few months back written by an Android OS developer who seemed to think it was a fairly solid crack at the problem.
What would you do differently?
And if they missed a use case (always possible) but still decide against general-purpose background threads (à la android/webos) they can always add a service or two for what they missed.
> What would you do differently?
I'm guessing he'd just go with desktop-type multitasking, not considering the resources exhaustion issues inherent to a mobile platform.
The fact that Apple doesn't support proper background services outside of the very basic 3 things they let an app do in the background, only support for bg notifications through a timer or their own push notification server.
I mean, I understand the power assumptions that Apple is making and claiming as benefits, but it just seems limited. I think of several applications I use that would not be implementable on iOS, certainly not without many major modifications including some weird use of the iOS push note-server.
1) the iphones touch screen. I don't care that much about the smoothness of the scrolling, but I really care about the ability of the touch screen to accurately track my finger position. While the N1 often is /good enough/, sometimes it fails badly and recognizes taps miles away from my finger. This is really bad when trying to type.
2) this might be an issue of my specific device, but sometimes I have a really bad hissing noise in my headphones. I'm constantly listening to Podcasts and Audiobooks and I can't live with that. HTC has some knowledgebase entry about this one and recommends to periodically shut the device down, remove the battery while holding the power-off button, and then reversing the steps. This, of course, isn't something I'm willing to live with.
So in the end it's build-quality that kills an otherwise superior phone for me. Too bad.
I hope Google rev's the hardware and we get a N2 that fixes these issues. Seing all the trouble with manufacturers not updating the OSes, I'd rather stay with a "Google Experience" phone as that more or less guarantees updates, so no Desire or Droid or whatever for me.
Also, updates being slow are more often than not the fault of the carrier, not the manufacturer.
Still. Phones like the G1 and the N1 seem to have closer ties to Google and seem to be updated more quickly and painlessly, hence my next try with Android is much more likely to be a N2 than any Sense-corrupted HTC thing without update guarantees.
The only thing that changes is whether or not they can print "Google" on the phone.
As an android dev, you learn not to rely on google api's for things. Much like twitter devs have learned not to trust the platform
But on the Touch, when you scroll past a certain point nothing is rendered except a 'transparent area' style chequerboard. You then need to wait for the browser to re-render the page. By contrast, the Android phone always renders the page, so you can scroll to a particular point by looking at the page as it scrolls past.
Given this implementation I'm not surprised that scrolling is smoother on the Touch.
Perhaps this limitation is Touch-specific and doesn't apply to the latest iPhone.
Re: autorotation - I much prefer the hysteresis algorithm used by Android when screenflipping - I can use it when lying on my side, because the screen doesn't flip until I've 'fully' turned the phone on its side. The Touch flips after less rotation.
It's likely an issue of RAM starving, is your Touch a first or second generation? (they have a quarter of the Desire's RAM, even the third-gen has only half the RAM)
An example, I just did: take a big, long, complicated page with lots of Javascript (say engadget.com, the regular non-mobile version) and wait until Safari is 100% done loading. You can scroll at skimming speed and I only saw the checkerboards once. But if you scroll like a madman trying to get to something near the bottom, it'll still checkerboard and make you wait for the roughly 500 milliseconds to render.
Reviewing Android on the ram/cpu starved Hero doesn't really give Android a chance to shine.
Uh that's what he did. If anything his comparison was still heavily android-tilted: he compared a 2 years old iPhone 3G with a year-old HTC Hero.
> My Droid
Uh yeah, so your idea of fairness is to compare a 2 years old iPhone 3G with a 7 month old Droid?
> Reviewing Android on the ram/cpu starved Hero doesn't really give Android a chance to shine.
Yes, because the 3G is well known not to be CPU and RAM starved (wait, it is, it has half the RAM and ~80% of the Hero's CPU)
Hopefully someone this balanced will do a fair comparison of the iPhone 4G when it comes out to one of the new Android phones hyped up after Google I/O.