An Android user tries out the iPhone(aaronstaley.blogspot.com)
aaronstaley.blogspot.com
An Android user tries out the iPhone
http://aaronstaley.blogspot.com/2010/06/android-user-tries-out-iphone-for.html
49 comments
> This is compared with a iPhone 3G
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)
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)
I have not noticed any slowness on the Droid however ... ?
Try going to the same webpage on the Droid and an iPhone 3G (yes, 3G). Start scrolling around; you will definitely notice stutter on the Droid that isn't present on the 3G.
>Apple is moving the goalpost for UI performance seemingly faster than Google can keep up.
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.
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.
I have a 3GS and an N1 running froyo. The iphone is still faster/smoother by a wide margin. In fact, the much touted speed improvements in froyo are hardly noticeable IMO. As a full-time Android dev, I wish they were.
> In fact, the much touted speed improvements in froyo are hardly noticeable IMO. As a full-time Android dev, I wish they were.
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.
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.
This is actually a pretty good comparison, and I can get behind his critique of the iPhone's mail app.
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.
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.
> This is actually a pretty good comparison, and I can get behind his critique of the iPhone's mail app.
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.
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 right, I should have said threads, and yes, they're a far cry from GMail conversations. I actually don't understand why conversations aren't more widely implemented. Is it particularly difficult to determine which messages belong to the same conversation?
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.
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.
> Is it particularly difficult to determine which messages belong to the same conversation?
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.
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.
> Probably, the outbox might have a different structure than the inbox, and lack some kinds of IDs.
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 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.
I sought to compare it for gmail users (which I suspect the majority of us are) - the gmail experience on Android blows away the iPhone.
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.
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.
Many people seem to think that OS 4 is going to bring this awesome multitasking. I think there's going to be a lot of disappointed people when they find out just how it works, seeing as the API for actually creating background services is crippled and the app switching is just a poorly implemented copy of Android pause/resume functionality.
It seems tailored for specific use cases and the various scenarios it handles seem to me to have been addressed well. Is it the particular scenarios that you feel aren't sufficiently well handled or is it that there are scenarios that aren't handled at all? (I'm sure there are some scenarios that aren't handled at all, but I haven't thought of any that would be glaringly missing in the vast majority of people's usage.)
Also, I'm curious what about the app switching is more poorly implemented than Android's version of the same?
Also, I'm curious what about the app switching is more poorly implemented than Android's version of the same?
That apps are killed slows it down. On Android it takes just over half a second to switch applications.
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...
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...
I've wondered why iOS kills the last app when it switches away... is it that iOS devices are more memory constrained? Is it that they don't want to disrupt the foreground app by collecting that memory when it's needed rather than immediately? Is it that they want app developers to be more careful about being able to reopen to the same spot they were, perhaps so that the experience of opening the app isn't different depending on whether the app got terminated while in the background or not (or even between device boots)?
OSX, like the Linux core of Android both support pre-emptive multitasking.
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?
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?
> 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.
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.
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.
Not really. I am not nearly ignorant enough to imply that any of the various aspects of desktop multitasking will be viable or well suited for a mobile platform any time in the future, nor would I want it to be.
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.
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.
What sorts of apps can you think of that wouldn't be implementable on iOS?
I just moved from iPhone to Android. The only thing I can't do is scroll an element in the browser. For example a DIV element with overflow:auto. On the iPhone, you just use 2 fingers to scroll it. On Android it seems to be impossible to scroll. Which means certain websites are a bit broken.
I did not know you could do that on the iPhone! Thanks for the tip. It should probably be a lot more obvious, there aren't even scroll bars on overflow:auto divs.
Agreed. It's not all that obvious... I think I just tried using 2 fingers to scroll and it worked. Unfortunately not the case (yet anyway) on Android :(
On Ubuntu 10.04 iPhone sync is supported out of the box by Rhythmbox, so this is no more an issue.
Note that out-of-the-box here refers to Ubuntu, not the iPhone, as I believe it still needs to be initially synced with Mac or Windows before use with Ubuntu.
There are two reasons I switched back to my iPhone after three weeks of having fun with the Nexus one:
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.
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.
One small point, "Google Experience" refers to the OS installed, not who the device is made by. The Desire and Droid are both Google Experience devices-Those are the only devices that get access to all the Google API's and apps.
Also, updates being slow are more often than not the fault of the carrier, not the manufacturer.
Also, updates being slow are more often than not the fault of the carrier, not the manufacturer.
That's not true. Non-"Google Experience" have plenty of access to all of the Android Google APIs, etc. If they didn't no apps that used Google Maps, Navigation, etc would work. The Google APIs are something that 3rd party apps rely on. Google restricting their availability would literally destroy the Market in one fell swoop.
The only thing that changes is whether or not they can print "Google" on the phone.
The only thing that changes is whether or not they can print "Google" on the phone.
Not true. There are 2 different versions of every android release-the "google" version and the non-google version. They have different capability. We just havent seen a major device launch without the google version.
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
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
ok. I stand corrected.
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.
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.
I too think that OEMs and carriers delaying updates will be the biggest threat to Android. It has certainly angered me to the point where I don't recommend HTC anymore and will buy an iPhone next time around.
wait 9 more hours. really.
To spare someone else the confusion I just had for a moment: Aaron talks about the WWDC Keynote that kicks off in a few hours
Not a very useful comparison at this time, since iOS 4 is about to change the email, multitasking etc. very soon.
Scrolling in the browser is indeed a little smoother on the iPod Touch compared to my HTC Desire.
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.
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.
> But on the Touch, when you scroll past a certain point nothing is rendered except a 'transparent area' style chequerboard.
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)
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)
It's a 2nd generation Touch. I've used a 3GS, but I just can't remember if it behaves the same way.
Since the 3GS (and 3rd generation iPod Touch) has both more RAM and a faster processor, you don't see checkerboards much. You still see them a lot if you scroll while the page is loading.
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.
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.
The 3GS does the same thing if the page is big (long?) enough and actually releases content so if you scroll back up it has to be rendered again.
What an unfair review. Compare like units. My Droid (especially now that it is running Froyo) has literally none of these problems. There is no lag between launching applications and when you replace the terrible stock launcher with LauncherPro, it really gives great performance. I have no shuddering and I also have Flash in my browser. Works reasonably well, especially when using 'On Demand' mode.
Reviewing Android on the ram/cpu starved Hero doesn't really give Android a chance to shine.
Reviewing Android on the ram/cpu starved Hero doesn't really give Android a chance to shine.
> What an unfair review. Compare like units.
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)
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)
I thought this was very fair, balanced and interesting. He was comparing an old Android with an old iPhone.
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.
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.
I agree that balanced reviews like this are needed but it would be even better if they compared more than one phone. On the Android side there are obviously a bunch with different manufacturers and target demographics, but even on the Apple side I believe that the 3GS will continue to be sold as a cheaper alternative to the 4G (or HD or whatever the new model is called).
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...)