3 ms·

IPhone Background Processing: Not Fixed But Halfway There

13 points by pchristensen 18y ago

newyork1 18y ago
great stuff
- stcredzero 18y ago
  I mostly disagree. As for his 3 examples: 1) Why do we need an alarm clock? Answer: this doesn't seem like a very pressing need. 2) Why shouldn't location broadcast be rolled into the iPhone's location APIs? Answer: The location API is actually the logical place for this. Everyone rolling their own would be a waste! 3) I agree that devs should get a way to register callbacks against notifications. But this need not be in the form of a full "background process." What do you have in mind that wouldn't best be put on a server or happen when the user returns to the app? Come on, folks! The real innovation in the iPhone space doesn't have to do with rolling your own version of a Calendar, Alarm Clock, Contacts, etc... Take those as infrastructure and build innovative apps on top of that.
lpgauth 18y ago
you can build an alarm clock... just need the program to post to a server at what time they need an alarm and then at that time the server post to apple which post to you :) obviously a bad technique but apple is just moving the services out the phone so you don't load it with process
pkaler 18y ago
_I'm reposting my comment that I posted to the blog._ The alarm clock would need to run on the server and trigger a notification on the iPhone. There is a very slow task manager that can execute code: Me. Your service that is sitting on your server would push a notification. A dialog pops up on the iPhone. The user touches a button on the dialog box and task switches to your application. Having shipped games on the Sony PSP, what you are proposing is a very, very bad idea. Background processes are a bad idea for memory-constrained devices that need 100% uptime. The iPhone does not page out to disk and it has a limited amount of RAM. These resources should not be handed to background processes. Note that the iPhone notification system works just like the notification system for the XBox 360.

13 points by pchristensen 18y ago

newyork1 18y ago

great stuff

stcredzero 18y ago
I mostly disagree. As for his 3 examples: 1) Why do we need an alarm clock? Answer: this doesn't seem like a very pressing need. 2) Why shouldn't location broadcast be rolled into the iPhone's location APIs? Answer: The location API is actually the logical place for this. Everyone rolling their own would be a waste! 3) I agree that devs should get a way to register callbacks against notifications. But this need not be in the form of a full "background process." What do you have in mind that wouldn't best be put on a server or happen when the user returns to the app? Come on, folks! The real innovation in the iPhone space doesn't have to do with rolling your own version of a Calendar, Alarm Clock, Contacts, etc... Take those as infrastructure and build innovative apps on top of that.

lpgauth 18y ago

you can build an alarm clock... just need the program to post to a server at what time they need an alarm and then at that time the server post to apple which post to you :) obviously a bad technique but apple is just moving the services out the phone so you don't load it with process

pkaler 18y ago

_I'm reposting my comment that I posted to the blog._ The alarm clock would need to run on the server and trigger a notification on the iPhone. There is a very slow task manager that can execute code: Me. Your service that is sitting on your server would push a notification. A dialog pops up on the iPhone. The user touches a button on the dialog box and task switches to your application. Having shipped games on the Sony PSP, what you are proposing is a very, very bad idea. Background processes are a bad idea for memory-constrained devices that need 100% uptime. The iPhone does not page out to disk and it has a limited amount of RAM. These resources should not be handed to background processes. Note that the iPhone notification system works just like the notification system for the XBox 360.