Chris Johanesen

This is my tumble log. I do web stuff for BuzzFeed. My home page is here. Thanks for stopping by.

4/13/11

themonkeysyouordered:

I got fired for having sex with this doll in the office.

Third-Party Background Processes in iPhone OS 4

The fact is, iPhone hardware is underpowered compared to desktop PCs, so Apple can’t just flip on multitasking for all third-party apps. I think they will use some clever and seemless (for users) hacks like with push notifications.

There are really three types of apps one would want to “run in the background”. And most of these don’t actually require running all the time. They simple require the ability for the app to do some things in the background.

Time Sensitive

Messaging apps generally have time sensitive data they need to deliver. The built in Mail, Messaging, and Calendar apps actually run in the background. The iPhone OS’s push notification service was added to address this need for third-party apps and I think it works really well. Do you really need your Twitter client to be always on in the background, or do you just need a notification when you have a new DM?

Always On

This is the hardest one from a computational perspective, but also will be the least used in practice. But some apps really do need to run in the background. Being able to play music in the background is one of the few situations where you truly need an app to be constantly running in the background. Apples iPod app does this. I think Apple will let third party apps (last.fm, Pandora, Spotify, etc) do the same if they are properly vetted. By which I mean you’ll have to specify that your app needs to run in the background (like developers do now if they want their app to have push notifications) and Apple will deny the app if they think you don’t really need it. I do think that iPhone OS will probably pop a dialog asking “This App Wants to Run in the Background. This may adversely affect battery life. Are you sure?”.

A Note on Switching

There’s been some talk of Apple using an Exposé-like interface to switch running apps. But that this interface will only feature icons and not full app preview. I think someone at Apple is messing with the Apple press—this app switching interface already exists. It’s called the home screen. Why would Apple create another, almost identical method of switch apps? They certainly don’t want to emphasize that some apps are running in the background and some aren’t. We don’t want to think about launching and quitting apps. We just want to switch apps.

Now, I think it could be possible that Apple will improve the home screen interface to make switch apps (any apps) more fluid. For instance, you could imagine holding down the home button will momentarily show the homepage, and then, while still holding the home button you can tap an app icon to switch to it. That makes the process less seem a little more one-step.

I can also fathom they put a little special highlight or dot next to the icon of any running app, but even this seems to break the “don’t worry about which apps are actually running” philosophy.

Periodic Updates

Every day I get on the subway and go to read an article on my iPhone only to realize I forgot to sync Instapaper. Or NYTimes, etc. Most apps don’t need to be on all the time and they don’t need to do anything immediately or exact times. What they need to do is have occasional background access to download some data. Task/note apps could also benefit form being able to periodically sync with a server, ensuring you usually had the most up-to-date data when you needed it.

While I long for this functionality I certainly don’t want to worry about micro-managing which apps get to do this while trying to make sure my phone doesn’t get to slow (like on my MacBook Pro) or run out of batteries too fast. There are three possible ways to do this without letting apps run in the background all the time.

Background Mini-Processes

Apple could let developers bundle mini background apps with their regular apps. The system would manage when and how often it ran the apps, making sure it just ran them one-at-a-time to prevent memory issues, and could even avoid running the background apps if you were low on battery power, or optionally only have them run when you’re on WiFi.

Since these apps wouldn’t be running all the time there is no risk that a user would start up too many apps and cause performance or battery-life issues. If one background process was taking a long time or using to much memory, CPU, or bandwidth the system would just shut it down.

The mini-app could be pretty light-weight since it wouldn’t need to load all the GUI frameworks. It could even be Python/Ruby/Bash script, just something that could read a config file, download some data, and save it for the real app to deal with next time you launched it.

The developer could request the app be run on a certain schedule (daily, hourly) but there would be no guarantees. The script/app would need to be able to handle situations where it was quit in the middle of doing something and be able to pick up right where it left off when run again.

This method would be the most work for developers but also afford them the most flexibility.

Push for Data

Apple could expand the push messaging service to let apps receive ‘data pushes’ from the server. When I add an article to Instapaper their server could push the file to my phone. The OS would receive the file and save it to the Instapaper apps data store. It could optionally show an alert letting me know that it’s been updated.

These special push messages could have a much lower priority than normal push messages to ensure they don’t overload the system. There would be a limit to how many or how often a service could sync/push files to your phone.

Universal Apple Sync Service

A system-wide background downloader app (i.e. cron + curl). Third party apps could register a request with it like “download this xml file from this url every hour” and the system would take care of all the work. Again, since the system maintains control it could avoid downloading if a request is taking to long or if your phone is low on batteries.

We’ll See

Obviously these last two wouldn’t be as versatile as being able to run arbitrary code that could do some extra processing or logic but it would handle 90% of the situations where I’d want a background app to run. It would also be easier for developers to use.

Or maybe Apple will do something totally different and surprising. We’ll see in a few hours.