Leaving the iPhone
mattcutts.com
mattcutts.com
Jeff LaMarche, a prominent iPhone developer and author of a couple iPhone programming books, wrote about this from the opposite side: switching from an iPhone to the Nexus One. I think his take is far more interesting: http://iphonedevelopment.blogspot.com/2010/02/nexus-one-from...
One real issue I have with all of the Android phones is the four hardware buttons they all have: back, menu, home, and search. Three of the four shouldn't be there. Coming from Google, I can understand the emphasis on search, but it simply doesn't belong in a hardware button. I don't need to search while I'm playing a game, for example. Likewise, the menu button isn't applicable in all situations, nor is the back button. Of the four, only the home button really needs to be a hardware button, and it's not a coincidence that Apple made that exact design choice.
most android software is designed with these 4 buttons in mind, and i use all 4 of them very frequently. the search button is not restricted to searching the web or anything, and many applications have some implementation of searching within them. the back and menu buttons are required in almost every application since there are no on-screen buttons like most iphone applications have (which look different from app to app).
When you hit the home button, the previous application keeps running, which means it keeps eating memory, keeps using processor cycles, and keeps eating battery.
oh, you mean just like every mac os application that, when closed by clicking the "x" button, stays running unless you go through its menu and quit?
To truly quit most applications requires a multi-step navigation that is neither intuitive nor well-documented.
many have a quit function in their menu, or just hitting the back button at its main screen usually quits it. i can't speak for every 3rd party application.
The ability to have more than one GUI application at a time on a device with such a small screen isn't as important as some make it out to be, since you can't actually interact with more than one a time.
on my mac i usually have to command+tab to work with more than one application at a time. it's no different on android. holding down the home button brings up a list of running applications that looks just like command+tab on a mac, and allows you to quickly jump between two applications. on the iphone, doing that (which would require going to the home screen between each jump) would restart each app every time, losing your context.
In the early days, I was a big proponent of having Apple add the ability to run multiple apps to the iPhone OS, but I've come to change my mind on that. I think most people don't need it and Android's implementation only confirms it.
ok, then most won't use it. that's no reason not to implement it. what percentage of iphone owners use copy-and-paste of text, or holding down home and power to take a screenshot?
even if users don't want to keep switching between apps, allowing background functionality is essential for using things like pandora to play music, or a location-tracking application to keep updating your status in the background. even if you just have to switch into an app to look at a phone number, or look at a map, not having to quit those other apps is very useful.
The day of my flight home from the U.K., I set alarms on both devices (I'm paranoid bout missing flights). It took me quite literally three to four times as long to configure and enable the alarms on the Nexus One as it did on the iPhone. Add that extra time by the number of tasks you do on your phone in a given day, and it can add up to a considerable amount of time.
and this is surprising why? you're used to how it works on an iphone and aren't used to how it works on android. it would be no different if you were used to windows and switched to a mac. once you get used to the new method, you'll do it quicker than the previous one.
That one is one of the most pernicious bits of misinformation about the Android platform. Applications that are no longer visible to the user are NOT "background" applications like they are on a desktop OS. Applications that are no longer visible to the user are stopped. They no longer consume CPU resources, but the OS does hold them in memory in case the user returns to the app. Stopped applications may be killed by the OS, thereby freeing up the memory used by them, at any time by the OS when it determines it needs resources. Think of it like caching. The app state is cached in memory so that if you switch momentarily to another app (to answer a call for example) you can return immediately to the previous app with minimal delay and minimal resource cost (ie, the app doesn't need to be re-loaded, etc). The Android developer docs have more information: http://developer.android.com/guide/topics/fundamentals.html#...
The only things that truly run in the background on Android are service process. These are somewhat like worker threads that are created specifically to handle long running background tasks (like playing music, or downloading data over the network, etc).
There is absolutely no need to go through any "multistep navigation" to quit apps, nor do non-visible apps continue "using processor cycles and eating battery" (with the exception of course of apps that are supposed to be using processor cycles, ie, music players, etc. running in a background service process).
Sir, stop it. You're accusing someone of bias and then demanding they share your preferences. Nothing you've claimed here is actually strictly incorrect or "biased" towards iphone anymore than the man's opinion.
Examples for your consideration:
1. He said, "I prefer one button." You said, "but i need four for frequent use in apps!" Incorrect: No. Explicit iPhone bias? No (his explanation is reasoned and applicable to other phones).
2. He said, "On phones, I don't want multitasking due to performance and power considerations." You said, "macs multitask what now?" This is a non-sequitur. The behavior of a desktop OS has little bearing on the behavior of mobile OSs.
3. He said, "I've come to agree with Apple about multi-tasking." You said, "okay but still put it in." Not really an argument either way. What's more, you are strictly incorrect; Apple has implemented multi-tasking in the phone.
You are lowering the quality of discourse on hackernews with these histrionics. It's clear you can make a neutral and consistent argument (i.e., requests for Pandora to run in-background).
It is just a phone. Can we please be civil?
If you're not wedded to the Windows way of doing things (in which windows, not applications, are primary), it's not that unintuitive. But even if you ignore that, there's rarely any harm to leaving an app "running" with no windows open--such an app isn't doing anything anyway, so it doesn't consume CPU, and it's faster to reopen again. And for some applications--instant messengers, for instance--Windows works the same way. Even if you quit all your Pidgin windows on a Windows box, Pidgin keeps running in the taskbar. Mac OS X's global menu bar and application concept at the very least provide consistent behavior.
"on the iphone, doing that (which would require going to the home screen between each jump) would restart each app every time, losing your context."
iPhone apps save state upon exit and reload state upon start. Considering that a background app that you're ignoring is probably going to swap to "disk" anyway, that's not much different from what you'd see in a multitasking environment.
And, as I mentioned, Jeff is the author of two books dedicated to iPhone software development. What else would his blog be called? And no, he's not neutral, no one is. But Jeff isn't a Google employee.
My point was that the whole line of argument is dumb. Tell me what one author got right or the other wrong. Don't spin one as "biased" and then turn right around and in the next sentence tell me to believe another without evidence.
The former I'll overlook even if they are two and a half times as much as the latter. ($500 second hand mac mini every two years vs $100/yr.)
and the iPhone is simpler for a non-tech-savvy person to understand.
Except wifi tethering? Contrary to popular memes Google imposes a number of restrictions on the Android Market:
I think for tethering you still need to root the phone, but that is because of security restrictions for common apps. They usually can't change the routing table or something (I am not an expert on this). I think rooting is also not frowned upon on Android.
BTW.. Another difference between the iPhone and Android platforms. If an app is not in the iPhone apps store, there is literally no way for a user to install it on a non-jailbroken iPhone. With Android, it only requires checking one checkbox in the Android settings to allow you to install non-market apps on an Android phone. No rooting, jail-breaking, etc. required.
I guess we have to be worried if we don't hear from him any more.
Ultimately though, what matters the most to me is control. I have a simple rule of thumb, which is that I don’t put data somewhere that I can’t get it back. That’s the reason that I didn’t buy songs in iTunes, purchase ebooks for the Amazon Kindle, or really log into Facebook at all. It’s also the reason that I recently switched my computer from Microsoft Windows to Ubuntu Linux.
Not to make this into an OS flamewar, but is he implying that just because Windows is closed source you do not have control over your data on the Windows platform? That Microsoft prevents you or apps from doing things or prevents you from removing things once you are done?
That seems like a long shot.
I assume if you root the phone, you can also run native apps, so why shouldn't Python work?
But the supported API is Java-based, and that legitimately annoys some people even if it pleases others. Google isn't banning python, certainly, but neither are they pushing it. No different than any other phone, I guess.
I believe ASE is using CPython running as native code, with some kind of bridge into the Dalvik VM.
I'm not sure what the status if JPython on Android is, but my understanding is that for many JVM languages it's non-trivial to port to Android, since many of them are expecting to be able to JIT to JVM bytecodes. This is problematic since Android doesn't use JVM bytecodes, it uses Dalvik bytecodes.