Live data from Hacker News

Mobile Multitasking

daringfireball.net

41–50 of 68 posts

Re: Mobile Multitasking

#41
post #2

I'm glad that iPhone OS is providing us an excuse to take personal computing a least a few steps down the path to where it should have gone years ago. Users shouldn't have to launch and quit applications. They shouldn't have to save and open documents. State should just persist. Always. If you pull the plug on your box you should be able to plug it back in and all state should be restored within seconds. All applicat…

I was actually thinking the same thing... It really doesn't seem like it would be too hard to do on a networked computer with access to backup on the cloud and fast uplink.

Re: Mobile Multitasking

#42

What's the link between blocks/grand central and multitasking on the iPhone?

none. grand central is a scheme to make it easier to parallelize your code, generally so it can take advantage of two or more cpu cores. not much use on iphone devices, which aren't going to have more than one core for a long time. blocks add closure-like abilities to C. multitasking, in this context, is a way to run two or more third-party apps at once. so, basically, no overlap at all.

Apple may be laying the groundwork for specialized multicore processors on mobile handsets.

Take the just-released Macbook Pros for example. nVidia's Optimus has controls at the application-level whereas Apple's technology is at the library/framework-level. There is no user interaction to switch between different graphics chipsets; depending on need for performance/battery life, the OS does "the right thing".

Ars has an article on it http://arstechnica.com/apple/news/2010/04/inside-apples-auto...

Re: Mobile Multitasking

#43
post #22

You certainly do need a task manager on Android for the simple reason that certain types of applications can be battery hogs. They may not tax the performance of the device enough to be killed automatically. I know Android 2.x is supposed to monitor battery usage but it simply doesn't work very well -- or at all in some cases. Subsonic (streaming audio client) kills my phone's battery if I don't kill it manually with…

There are two kinds of background processes in Android (unless it's changed since I last wrote an app, which is possible - that was for OS 1.5).

This article is describing how the main app (the bit you see) functions. When it is swapped out you get an event, then again if they are killed. The OS manages that.

However you can also write services/daemons which are persistent and (as far as I know) not suspended by the operating system. I don't believe they can present a UI but they can communicate with your main app.

These are intended for things like occasional server polling and pushing notifications to the bar. But I don't believe there is any technical restriction on using them for other things.

Re: Mobile Multitasking

#44
post #32
post #2

I'm glad that iPhone OS is providing us an excuse to take personal computing a least a few steps down the path to where it should have gone years ago. Users shouldn't have to launch and quit applications. They shouldn't have to save and open documents. State should just persist. Always. If you pull the plug on your box you should be able to plug it back in and all state should be restored within seconds. All applicat…

I'm not so sure abstracting away document open is a good idea in the long run. You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app. Abstracting away document save is also probably not a good idea unless there's automatic versioning (at least up to a few versions) built in. Also 1-dimensional lists (like the coverflow of docs in iPad's iWork) don't scale…

"You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app."

Most users of MS Word will be familiar with this.

Re: Mobile Multitasking

#45
post #19
post #18

I'm glad he made this point, but he's still not giving Android enough credit. With Android, apps can create a service that can run and do whatever it likes. It's not limited to a couple APIs. People are pretty jazzed about Skype running in the background, but they are going to be dissapointed when they realize that only means that you can keep the current call running while you leave the app. Skype still won't be abl…

Your last paragraph isn't true about VOIP apps, but I can't say more due to the NDA.

I really don't understand why Apple has an NDA on its essentially public developer program. There are so many iPhone developers that all the standard rules and agreements will be made public almost instantly no matter what.

Re: Mobile Multitasking

#46
post #26

Moore's law seems to be in full effect for handsets. I think a lot of the innovation here is a stop gap measure before these handsets have virtual memory, making the complication behind multi tasking obsolete. On a side note, I seem to take heat every time I imply that phones will end up on par with PCs. The common theme I've been pushing is that most of the developments we've seen in PCs over the past decade will re…

It gets a little silly to talk about "phones" in this context. Making and receiving one-to-one voice communications is already just one of many features, and arguably already not the main feature.

Re: Mobile Multitasking

#47
post #32

Earlier quoted context omitted.

I'm not so sure abstracting away document open is a good idea in the long run. You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app. Abstracting away document save is also probably not a good idea unless there's automatic versioning (at least up to a few versions) built in. Also 1-dimensional lists (like the coverflow of docs in iPad's iWork) don't scale…

"You lose the ability to separate your valuable data from the application, and it encourages lock-in within each app." Most users of MS Word will be familiar with this.

Only because RTF is not well-known among nontechnical users.

Re: Mobile Multitasking

#48
post #35
post #22

You certainly do need a task manager on Android for the simple reason that certain types of applications can be battery hogs. They may not tax the performance of the device enough to be killed automatically. I know Android 2.x is supposed to monitor battery usage but it simply doesn't work very well -- or at all in some cases. Subsonic (streaming audio client) kills my phone's battery if I don't kill it manually with…

I admit that in the beginning it is a bit unnerving not to be sure what the apps are doing under the hood. My response to suspicious activity is usually to uninstall the app, though. Some better monitoring device would be useful, but already you can see which services are running, and what has been using the battery. So culprits should be easy to identify and remove, without a task manager.

Android gives you a readout of which apps have been using the battery.

Re: Mobile Multitasking

#49
post #25

Earlier quoted context omitted.

Do you get acceptable battery life running an IRC client in the background? The client has to keep a persistent data connection open and will be constantly transferring data. I've not had much luck with IM clients on BlackBerry, WebOS or Android. I guess the bigger question is if the user's battery should be drained in a situation where they don't understand the ramifications of what they're doing. If you're playing…

I stay logged into gtalk on my Nexus One continuously. I don't notice any significant battery drain because of it, and I often have longish conversations with people while waiting for the train via gtalk. The gtalk app doesn't even show up as a significant user of battery power in the "Battery Use" list.

Actually, from talking with the OneSocialWeb [1] and BuddyCloud [2] guys, I understood that Android phones have a really sophisticated "always connected" philosophy. The main CPU can go into deep sleep and the phone still maintains a persistent data connection, waking up the CPU on incoming data. That's for the low-level IP stuff. TCP-over-GSM really sucks your battery.

XMPP doesn't (yet) have a standardized way of filtering data. Using Privacy Lists is a workable hack. Google implemented their own thing (using Protocol Buffers [3] to replace XML-on-the-wire, instead of gzipping as the XSF recommends). Process One has their own system as well for OneTeam [4].

The future ideal is to use SIFT [5], but it is still experimental and as far as I know, only Prosody [6] has partially implemented it.

[1] http://onesocialweb.org/ [2] http://buddycloud.com/ [3] http://code.google.com/p/protobuf/ [4] http://www.process-one.net/en/solutions/oneteam_iphone/ [5] http://xmpp.org/extensions/xep-0273.html [6] http://prosody.im/ (dammit, how do I embed URLs in the reply?)

Re: Mobile Multitasking

#50
post #45
post #19

Earlier quoted context omitted.

Your last paragraph isn't true about VOIP apps, but I can't say more due to the NDA.

I really don't understand why Apple has an NDA on its essentially public developer program. There are so many iPhone developers that all the standard rules and agreements will be made public almost instantly no matter what.

No, part of the privilege of being a registered iPhone developer is you get access to beta SDKs and information that the public does not. The idea is to give iPhone developers who are in their program a head start. The fear of getting booted from Apple's program is usually sufficient to bite your tongue before you saying something in public that should not be discussed.

As an example: now that the iPad SDK is no longer under NDA: one of the most interesting APIs in iPhone OS 3.2 (iPad) is MPMoviePlayerController gaining the backgroundView and view properties. Basically, it opened up a whole arena of interactive video applications that overlay graphics on top of live or recorded video (think watching baseball game on iPad and pulling up player's on-base stats by clicking on magic button hovering near base, true interactive TV, interactive remote control with show previews...)

http://developer.apple.com/iphone/library/documentation/Medi...

Post reply on HN