Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mobile Multitasking

daringfireball.net

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Mobile Multitasking

#31

Post by thwarted »

jsz0 wrote: post #25
pkulak wrote: 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…

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.

Re: Mobile Multitasking

#32

Post by zhyder »

mrshoe wrote: 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 well. These problems are dealt with more effectively by hierarchical folder systems of today's desktop OSes than by the iPhone OS. They're not as foolproof, but there's real benefit in exchange for the complexity.

I agree with you about application start/stop though. Also, IMO infinitely adjustable/overlappable windows in desktop OSes don't add much value either. A simpler windowing model (maybe a little like webOS's cards; the iPad's is too extreme) would probably be better.

Re: Mobile Multitasking

#33

Post by [deleted] »

wvenable wrote: post #13
mrshoe wrote: 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…

If you want to edit a document and then save it as a new document you have to make that choice before you start editing on the iPad. A lot of people are going to destroy a lot of documents that way. It could be a simple fix to still keep the same model but right now it's not very intuitive.

[deleted]

Re: Mobile Multitasking

#34

Post by bruceboughton »

mattparcher wrote: post #30

His closing thought on the matter: "You know what iPhone OS is missing that Mac OS X has? The SPOD." ("Spinning pinwheel of death", "rainbow beachball of death", etc.: http://en.wikipedia.org/wiki/Spinning_wait_cursor ) I'm nearly ashamed to admit I have never noticed it's absence until now.

It doesn't have the SPOD, but it does occasionally freeze with an app in an unusable state. The SPOD is only not there because they didn't add it, not because an unresponsive system is impossible with the iPhone OS.

Re: Mobile Multitasking

#35

Post by Tichy »

jsz0 wrote: 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.

Re: Mobile Multitasking

#36

Post by mattdw »

ajg1977 wrote: post #27
mattdw wrote: post #23

Earlier quoted context omitted.

Of course, then you have to deal with resources – like when you unfreeze your app partway through typing a word, but in the meantime the user has changed keyboard layouts, or you unfreeze the camera program but meanwhile something else has been using the camera and left it in a different state. Better to persist as little as you need, and deal with everything else through clearly defined lifecycles, IMO. Although, I…

Good points - except that under iPhone OS 4.0 the OS and apps already have to handle these situations. Apps compiled for 4.0 are "frozen" when backgrounded. When they are brought to the front, either from the new task pane or their icon, they are unfrozen and restored to a running state. If the iPhone becomes low on memory it terminates frozen apps from least to most recently used. So since these apps are already sus…

Ah true. Maybe they just want to avoid eating into the limited number of writes flash mem handles?

Re: Mobile Multitasking

#37

Post by ZeroGravitas »

bruceboughton wrote: post #34
mattparcher wrote: post #30

His closing thought on the matter: "You know what iPhone OS is missing that Mac OS X has? The SPOD." ("Spinning pinwheel of death", "rainbow beachball of death", etc.: http://en.wikipedia.org/wiki/Spinning_wait_cursor ) I'm nearly ashamed to admit I have never noticed it's absence until now.

It doesn't have the SPOD, but it does occasionally freeze with an app in an unusable state. The SPOD is only not there because they didn't add it, not because an unresponsive system is impossible with the iPhone OS.

SPOD doesn't mean an unresponsive system, just an unresponsive app so this a functional regression in iPhone if you can't switch to other apps while the frozen one recovers.

Re: Mobile Multitasking

#38

Post by biafra »

thwarted wrote: post #31
jsz0 wrote: 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.

The reason is that Google has control over the XMPP server. They do not need to send you presence notification if your gtalk client is not in foreground. Just staying online is not the problem. The problem is that usually with XMPP the server sends presence asynchronously. There is no standardized way for a client to request not being send those. If you happen to have 200 or more users in your roster there is always someone going away or coming back. Receiving those packets is draining the battery.

If your XMPP server happens to support privacy lists you can request not being send those presence notifications for a while. But at least some servers do not send the last presence when you clear that privacy list. And at least some of those servers do not allow you to get presence for all users in your roster by sending only one (unaddressed) request for presence. You have either to send all users in your roster that request or drop the connection and reconnect to get the current presence of all users.

Re: Mobile Multitasking

#39

Post by Maktab »

vsync wrote: post #10
mrshoe wrote: 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…

You mean, following down the path that Palm OS devices used since first released in 1996?

Or Newton OS devices from 1993. This isn't the first time that Apple has tried to build a computer with seamless state persistence and without a traditional exposed file system.

That said, neither Palm OS or Newton OS could multitask. Android and the iPhone OS seem to have found a very elegant approach to that particular problem without compromising the user experience.

Re: Mobile Multitasking

#40

Post by brisance »

wvenable wrote: post #13
mrshoe wrote: 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…

If you want to edit a document and then save it as a new document you have to make that choice before you start editing on the iPad. A lot of people are going to destroy a lot of documents that way. It could be a simple fix to still keep the same model but right now it's not very intuitive.

Well that's because we as users have been conditioned to make a copy of a document whenever an edit is required.

What should've been taught, from the very beginning, is that we really should be working on versions of the original document. Not that it's an easy problem in itself to solve... refer to various versioning systems as examples.

Post reply on HN