Hacker News Reader

Comment by bmalicoat | Hacker News Reader

The only issue I take here is the iPhone is supposed to not need an instruction manual, everything is supposed to be intuitive. Adding multitasking like the Android means every user becomes an accountant keeping track of what's running and what should be killed. Activity or task managers are most definitely not intuitive. Most apps don't have any business running in the background, saving and resuming states seems to work in most cases especially with smart use of push notifications.

I've really only seen a couple compelling use cases and that is Pandora (basically music running in the background for the uninitiated) and the YC Wakemate app. Anyone have any others that couldn't be solved with push?

View on HN

The big issue is that it imposes a high mental cost for switching between applications. If you're browsing on Mobile Safari and you want to look up something in another app, you generally wont, because by the time you get back to Safari you may have lost the page you were visiting and in any case the startup times can be pretty atrocious.

On the Pre, which has the best multi-tasking implementation I've seen, these sorts of tasks are a no-brainer. You know that your previous applications is just a couple of swipes away, so you're never afraid to leave it.

Constantly shutting down and restarting applications may be good for performance and battery life, but the user experience is hampered.

Well the developer can implement a great experience but the problem is the onus is on them, the OS doesn't do anything to save/resume the state. Some apps, Tweetie for instance, does a great job resuming, others dump you at the front gate and make you watch splash intros which is terrible. So I guess my vote is for built-in support for saving state.

Which is why Safari IS actually multitasking. You can leave it, launch another app, go back to it and be right back where you are. Sometimes Safari doesn't quit and you're back in a millisecond. Other times the OS closes the browser in the background, and you will have to wait a few seconds while Safari reloads the page you were visiting.

It's surprising how few people realize that the built-in apps (Mail, iPod, SMS etc) run perfectly in the background. The lack of multitasking is limited to 3rd party apps, which helps explain why most iPhone users never complain too much about the lack of real multitasking.

But Safari being multitasking only solves the "browsing -> other -> back to browsing" case, right? "Something else -> Safari -> back to the first something else" needs the something else to be multitasking enabled or good at storing its state.

Trying to predict what the users will and won't ever need to switch to and from and back to again is a crap shoot in general. Sure one can get it right much of the time, but why not just suck it up and make the overall solution better so there aren't those cases where one guesses wrong.

From the outside, this feels like a bizarre, "accept no criticisms of an Apple product as valid" kind of thing. Stuff like Browser Duo and mini apps make it clear that the longer Apple doesn't solve this in general, the more other developers will put together "do x and y at the same time" applications. Does it really seem better to have these kludges than a general solution?

"something else" -> "web browsing" -> back is handled by the application wrapping the Safari web browser using the included browser control in the API.

Good point. I was just doing an inversion in the example to simplify the argument mechanics a bit.

But doesn't that wrapping rely on something else's developers realizing that the user might want to go off to the browser and back? What if it wasn't Safari in the middle but any one (or three) of the numerous other programs the user might want to take a side trip through. It gets back to the crap shoot of trying to guess every multi-application use case that will be wanted. All this to defend not putting together the general solution which is entirely doable to begin with.

That's a strawman. Android users don't need to keep track of what's running and what should be killed at all. The OS keeps track of it all.

Android actually has a pretty damn clever model where normally Activities are killed whenever they're not visible (similar to the iPhone model). However, and application can register service processes that run in the background to do things like play music, check for updates (email, IM, etc).

The difference between the Android and the iPhone model is actually pretty small. The main difference is that on the iPhone, only certain Apple provided apps can do things like play music in the background, get background notifications, etc. In Android, third party applications can also be written to do those things.

But in the most common case of apps that don't do things in the background, the application lifecycle of iPhone apps and Android apps is actually quite similar.

Reply on news.ycombinator.com