Attention internet: that’s not how Android multitasking works
Hey everybody, please stop confusing John Gruber and his legion of flying monkeys with strangely wrong statements about multitasking in Android.
On Android, apps are suspended when they are no longer visible to the user. Suspended means the app is still in memory, but it is frozen. No processing or event handling happens.
LIES. Or, more likely, IGNORANCE. Whichever it is, there is no redeeming this objectively wrong statement. I don’t know who this guy is or how much Android programming he has done. Neither did PCWorld but they still wanted to marry his “clearly, straightforwardly, simply written” bundle of bad guesses on computer phone stuff, proudly not “mired in the technical details” such as whether or not its fundamental assumptions were correct.
ANYway. That was months ago. It seemed like this nonsense would be corrected at some point by people that knew what they were talking about. But then today:
When a user switches apps, or hits the home button, your app has a brief time when it “runs in the background.” Then it becomes suspended. In its suspended state, it is still in memory, but gets no CPU cycles.
WHAT. No. But this guy actually does Android programming. What is he talking about? [You can find Michael’s response in the comments below.] Was Coderspiel itself mistaken? Let’s test it!
scala.actors.Actor.actor {
while (true) {
Thread.sleep(5000)
println("hello")
}
}
See for yourself: the world is wrong and Coderspiel is right, like usual. You just have to copy and paste that scrap of code somewhere into your Scala Android app (IF YOU HAVE ONE LAZY PANTS) and see what happens when you leave the application.
Here is what happens, for the lazies: the thread keeps printing crap forever. The app containing it can not be described as “suspended” or enjoying a “brief time”, in any universe. At some point the app may be terminated, if you open a bunch of porn from Steve Jobs’s famous Android porn store. But on our test device it ran for like an hour before we got tired and stopped it.
Crazy, right? It took just a couple of lines of code to disprove this misconception flowing through the torrent of “this thing is somewhat like that Apple thing, please RT” pieces. (Those are boring btw. At this point the only reason to read them is to drink a beer each time they type something completely wrong about Android.) How has this confusion spread so far? Surely most Android programmers know how their platform works. Perhaps they are just so admirably used to packaging long running processes in services, and recognizing that background apps may be terminated at any time, that they think of background apps as being suspended. It’s just that, crucially, they aren’t. It’s the application’s responsibility to be idle if it is not doing anything of value.
As for users and their precious experiences, this distinction is actually really interesting. It means you can do this thing where you’re reading RSS feeds in NewsRob and there’s a link you want to follow, so you “open in browser”, and then you switch back to NewsRob while it’s loading. Later, you go to the browser and the page has loaded. If you’ve used a computer since 1995, you’ve probably experienced this feature already, which is called “multitasking”. You don’t have to do anything special to make it work.
Of course, Mobile Safari is made by you-know-who, so it already multitasks swimmingly in the current iPhone OS. It will keep on loading pages while you are playing Doodle Jump. But poor iPhone Opera is crippled with amnesia: not only do loading pages fail to finish when you leave the app, they’re forgotten entirely. In iOS 4 they will pause or something, but Opera can’t just load them like normal because it is not Pandora or a jogging route recorder.
Or who knows, maybe Opera will be allowed to multitask because as a browser it’s already “duplicated functionality” and the ever-changing, non-binding platform rules are nothing but a complex piece of misdirection.
