Entries in Multi-tasking (2)

Friday
Apr092010

iPhone Multitasking Revisited

Back in January I posted to this blog my thoughts on what form background processing might take in iPhone OS. I proposed that we would not see what you might consider, "full multitasking", but went on to explain why I didn't think we needed it (and that that would be a good thing) and what should happen instead. Yesterday Apple announced iPhone OS 4 and the headline feature, of course, was multitasking. So how did my musings (and those of the commenters to that article) stack up?

slide_5923_79686_large.jpg

I listed three primary areas that most multitasking usages involve:

1. Background apps, such as music players. The iPod app does run in the background, of course, but there is certainly a case for third-party apps such as Spotify or Last.fm to have the same ability.

This was the first multi-tasking service discussed - the background audio service. Pandora was the poster child.

2. Notifications. This is at least partly addressed by the Push Notification service that Apple now provides. More on that in a moment.

I went on to discuss in more depth what I meant by this and Apple have implemented this exactly as I proposed (although it is conceivable that they arrived at this concept independently). They have called it Local Notifications.

3. Fast switching between apps

I also went on to suggest that this is what most people want most of the time they lament the lack of multi-tasking. App switching has always been fairly smooth on the iPhone and iPad, but new services to allow apps to persist and restore their state quickly make that process really seamless - and even allow apps to respond to beings switched back to (the example given was of playing Tap Tap Revenge which, when switched back to after switching away, has paused the game and gives a 3 second countdown before resuming again).

I felt that these were probably the biggest uses of multi-tasking that could be provided without disrupting the performance and battery life. They are not the only areas, of course. I invited people to suggest other areas that could be served in a similar way.

The first comment I received was from Graeme Foster, who said:

Location-tracking apps like Google Latitude and FourSquare?

And the second, from James Webster, said:

Running the GPS and a background app would be battery intensive

I'm sure Apple were reading these comments. They have addressed both of these concerns. There are two background location services. One is based on cell tower triangulation and is aimed at Graeme's use case. The other is full on location services - aimed at navigation apps - which assume the device will be connected to power - so acknowledging James' concern.

One use, which wasn't mentioned by me or my commenters, but I did see discussed elsewhere, was for VoIP apps, such as Skype - and it was nice to see this catered for too. In fact I wonder if it becomes possible to use an iPod touch just like a normal phone now!

Another feature that I didn't bring out (but others did) was completion of upload tasks. In retrospect this is perhaps the most important from my own perspective. In another iPad related blog post I alluded to an app that I'm working on that fits the iPad like a glove (no, not literally). I'm still holding my cards quite close on that one, but what I will say is that it involves cloud syncing. The trouble with cloud sync enabled apps right now on iPhone OS is that the syncing tends to happen in the background. If the user closes the app while the syncing is in progress then, at best, the app will not be fully synced up and the "cloud" version will be out of date. At worst, if not carefully designed, data corruption may result.

iPhone OS 4 includes a service called Task Completion and this solves the problem cleanly. Tasks such as syncing and uploads that are kicked off while the app is running can continue to completion in the background even after the app is closed. This was one area that I was agonising over for my app and I'm really pleased that it is solved in OS 4.

Finally, one of my commenters, Yitz, posted an interesting link to his own blog with his views on another "iPhoneOS multi-tasking alternative". In fact the bulk of his post was arguably not about multi-tasking as such, but rather about allowing developers to write services that other apps could call into. In retrospect this is now somewhat provided for by the QuickLook framework.

So, in summary, Apple's multitasking features include everything I expected, everything I hoped for and everything I dared not dream of (or, indeed, blog about).

Now things get interesting.

Sunday
Jan312010

Why the iPad may never need multi-tasking

activityMonitor.png

Like the iPhone and iPod touch the iPad does not allow multi-tasking of third-party apps. That is, if you are using one app and want to start another you must close the first app. I wouldn't rule out that changing in a future update, but I'm more inclined to think we won't see it even on the iPad - at least not in a general form. Why?

The way I see it multi-tasking is used for three purposes:

  1. Background apps, such as music players. The iPod app does run in the background, of course, but there is certainly a case for third-party apps such as Spotify or Last.fm to have the same ability.
  2. Notifications. This is at least partly addressed by the Push Notification service that Apple now provides. More on that in a moment.
  3. Fast switching between apps

I'd say that (3) is probably the number one reason we usually have so many apps open at once. After all we can usually only interact with one at a time. As the time it takes to (save and) quit one app and start (and restore) a new one gets closer to zero our need to have the apps open just so we can switch to them diminishes or disappears. From what I have read and heard the iPad gets us pretty close to the threshold where this happens. By some reports it crosses that threshold. I'll reserve final judgement until I see it with my own hands (mixed metaphor intended).

Going back to reason (2) let me explain what I mean by being only partly addressed so far. Imagine a calendar-type app - such as Event Horizon. You set up events and appointments - which may be days, weeks or months later. Ideally the app would be able to alert you of upcoming events in much the same way that Apple's own calendar app can already do. One way to achieve that now would be to use the push notification service. This would work but has two problems. First it's a bit heavyweight. Your event data would need to be synced up to a cloud service which could then decide when to push a notification back to the device. Cloud services certainly have their place, but bringing them in solely to provide alerts seems out of proportion. Secondly it means you will not receive the notification if you don't happen to be connected at that time. You will get it when you do get online, but that may be too late! Furthermore you need to be connected for the alert to sync up to the cloud in the first place. These all seems unjustifiable limitations when it concerns data that you already hold locally on your device. Therefore I think it reasonable that some sort of Scheduled Notification API should be made available. This could work just like the Push Notification service, allowing badges, messages and alert tones to be "pushed" to the user, with the ability for the user to open the associated app straight away, or defer that until later. The difference would be that the notification would be posted by the app itself for delivery at a specific time in the future and would never leave the device. I don't see any technical challenges to providing such an API.

If a scheduled notification API is made available I think the only significant remaining need for background tasks would be for things like music players. If Apple do allow background tasks in the future I think it will be limited to these types of tasks, and very strictly policed in the app store approval process. I'll say again, I don't believe Apple will ever allow general purpose multi-tasking in App Store apps. - and I don't believe they need to with the concessions just described. Note that I am ruling out other scenarios such as video encoders or bit-torrent clients, which I don't think are appropriate apps for running on these devices in the first place. If you can think of anything genuinely useful for a significant number of people that wouldn't be covered by such provisions I'd be interested to know.

Technorati Tags: , , ,