iPhone OS 4’s big deal yesterday was multitasking. They announced Seven Services which provide multi-tasking components to developers.
This fulfils pretty much what I was looking for in the iPhone OS: pull and background and goes even further than I had intended. It permits the backgrounding of music apps, VoIP apps, location-based apps and timers (local notifications). It permits apps which have longer processing to background their processing and permit the user to move on to do something else. To be honest, I’ve got everything I wanted.
David Kirk writes:
Following the Apple OS4 announcement today that the iPhone and iPad would be “multitasking” a lively discussion sprang up on Twitter. 140 characters is woefully inadequate for that discussion so hopefully @cimota will post this on his (soon to be) award winning blog.
First let me define my terms and concepts so we can get agreement on our vocabulary. And multitasking and multi-threading need agreement.
A general purpose computer is a collection of processors dedicated to specific functions [program execution graphics, I/O, communications, etc.]
Processors execute [we’ll not get into instruction fetch, operations, etc.] only one instruction at a time, and do so until they issue an instruction that causes the processor to “wait” for the specific completion of some other task (e.g. read / write to complete, packet received on communications line, timer to pop, etc.). If there are no other tasks ready to execute, then the processor itself will wait until it receives an interrupt from the processor handling the I/O or communications or timer. Then the operating system will “awaken” the waiting task, restore its context, and schedule the next instruction. Even non-multitasking OS’s need interrupts (DOS).
Multitasking was designed to take vantage of all those “waits” by scheduling other tasks – that are ready to execute. A multitasking OS, once one task “waits”, will restore the context of another task that is ready, and schedule it for execution. Of course if there are no other tasks ready for execution, the processor will itself wait.
One other wrinkle. Many multitasking OS’s have a priority schedule, whereby certain tasks get priority over others. For example, if a task is receiving bytes from a communications line into a buffer, its probably needs priority to empty the buffer before the next packet comes in else the buffer will be overwritten – so that task may need “priority”. This is implemented in the OS. Once an interrupt occurs, the OS decides if the task running is the highest priority task that is “ready to run”. If not the OS will store the tasks context and schedule the task which is the highest priority.
So, multitasking requires hardware interrupts and a multitasking OS that manages context and administers priority [for all compsc geeks, including the old timers, yes that is a GROSS simplification}.Multi-threading is a concept that simplifies programming in software systems that support multiple users concurrently. In essence its performs psuedo multitasking between its own threads, but never “waits” or gets interrupted from the OS. An application that performs multi-threading can its – without awareness – be multitasked.
Finally, and to the point of the OS4, the act of multi-tasking (whether or not these are multi-threading or non-multithreading applications, is transparent to the application.
David is right, right down the last sentence. Users don’t care how multitasking is implemented. They really don’t. Back in the olden days on the Mac, people were happy with the simple ‘co-operative multitasking’ that was presented by the Mac and Windows 95 and didn’t cream out for pre-emptive multitasking which came with the Windows NT kernel and (eventually) Mac OS X. They just didn’t care. They cared about the symptoms – that under the co-operative model a single application could block the whole machine and they cared about the lack of protected memory on some of these operating systems insofar as one wrong write to memory could crash the device but in the scale of things they didn’t care. The system appeared to multi-task and that’s what was important. And it’s still what’s important.
Jeff LaMarche writes on the iPhone OS4 multitasking:
I’ve used Android’s “multitasking”, and I think that Apple has been 100% right not to just port the workstation model of “multitasking” to the phone. It’s hard to say how well these new “multitasking” APIs will meet our needs as developers, but the best that I can tell from the presentation, Apple seems to have struck a good balance. Battery life can really suffer with a traditional “multitasking” approach, as I’ve discovered using my Nexus One.
I think this is very valid. We don’t need a repeat of the desktop model on mobile. As long as multi-tasking is transparent to the user, it doesn’t matter which way it is done. And if these measures mean pausing apps which are not currently being used, permitting audio, VOIP services and location services and allowing longer-timed processing to continue, what else is needed?
Would you mind linking to David’s original post?
It was an emailed PDF
Matt. Thanks to giving me space here, you’ll see how that wadi
possible in 140.
But also to take it further.
Im seeing lots of postings today that agree “what Apple have done is not true multi-tasking”. So let’s not spend anymore time down that rabbit hole.
I also agree that Apple, in a way that only Apple does really well, gave users a user friendly solution that I’ll call backgrounding.
My only issue is that the app now has to be background aware, and needs to specifically exploit certain services.
And here’s my issues
1. Apple decided *which* services to make available, based on looking at today’s apps. It certainly cannot predict where the army of app developers will take innovation on this platform in the future. So both the services and the API will evolve.
2. Now we are into backward and forward compatibity. Not only will certain apps have have base hardwarepre-requisite, but a base OS pre-requisite. Now the use will have to make all sorts of trade offs. If app A requires OSn.7 and app B requires OSn.8, which do I run?
3. There are three classes of finite resource inthe iPaltform (shorthand for iPod iPhone and iPad). Battery, cycles and memory. A real multitaking kernel could limit cycles and memory totally tranparently from the user AND the application. And I assume by doing that, would reduce power. As I user I don’t need a task manager, I just want for ME to decide what “priority theme” I like.
My disappointment with yesterdays announcement is that Apple solved one problem (gave users what they wanted) but didn’t look far enough around the corner to predict the problems that maybe lurking for user and app developers. And, really innovate on how to implement real multitasking in the usual user-centric-awesome way.
That said. I’ll still be implementing OS4 as soon as is safe.
/d
I don’t have an issue with apps needing to be background-aware. It’s a young platform with a lot of developer churn and there is plenty of opportunity for a keen upstart to produce something amazing because they chose to take advantage of certain technologies – such as these services – to give themselves a competitive advantage. Keeping up with the new APIs is always going to be something to differentiate themselves with.
Game Center, for example, will be adopted quickly, even by companies which had previously adopted OpenFeint. Because at this time you cannot afford to NOT be in at the beginning.
The hardware pre-requisite is a real one. The iPhone and iPhone 3G only shipped with 128 MB of RAM, barely enough for one application to run, never mind two. The iPhone 3GS and iPad ship with 256 MB of RAM which explains why they can have more processes running. I was concerned enough last year when they equipped the iPhone 3GS with 256MB because I anticipated that developers would target their software for the larger amount of memory and orphan the older devices. This has not really happened. Not really.
The difference between iPhone OS devices and desktop-based platforms is that the former has no concept of virtual memory as swap. Memory is always severely limited on this platform so the operating system kernel (and there is one) is maintaining a watch on processes which have potential to abuse resources – and it is a stern taskmaster.
And ask yourself – do you really need multitasking? I feel like I need it but there are things in place that means I don’t really need it. For example, use of ‘screen’ means I don’t need a persistent connection to my UNIX server. Very handy when a app closes or alternatively when I lose connection due to poor 3G coverage.
Priority themes. Explain that to my father. This is a platform to be used, not tinkered with. As Mac OS X is to Linux, iPhone OS is to Mac OS X; an order of magnitude of simplicity.
Let’s pick off a few of these.
Do I really want multi-tasking? No. I want to be able to switch between apps and return either where I left them, or where they had gotten to – backgrounding.
What I’m not excited about is that Apple has decided for me (via the services it has externalised thru it’s API) which apps I can background. What if I want Dropbox to run in the background because it takes 20 mins lapse (but very little CPU) to synch my files?
I accept that their is only real memory, and not virtual memory in the iPlatform. But even virtual memory is finite. Memory management – or convervation, sustainability – can be applied to either real or virtual. To control memory hogs, real MT OS would place task into wait state by managing it’s requests for memory. It can even terminate it if it exceeds it’s limits. Of course when multiple tasks are contending for the same limited memory, priority is given to the one which the user decides.
Priority themes? This is my requirement at innovating MTing. Let me decide the “experience” I want to prioritze. Longer battery life? Many apps running in parallel? Particular apps that are never limited? Some that are always limited?
And again, don’t put the burden on app developers to implement this thru externalized services. Ultimately the user – because of compatibility prerequisites – will be forced to make compromise decisions about which levels of OS and which versions of apps – regardless of hardware.
/d
If Dropbox want to enhance their user experience, then they will adopt the task completion API. Or someone will do one for them, charge 99c and make a few bucks. So it may take 20 minutes to sync, but there’s nothing stopping an OS4-aware app from taking advantage of that.
On the original iPhone, the memory left for apps was less than 30 MB. On the 3GS it is larger but it’s not unlimited. Without the benefit of Virtual Memory you are actually very limited in what you can manage when dealing with advanced systems which have to handle huge amounts of video data (such as the iPad needing 30-40 MB of RAM for the video display)
The burden is always on the developers in this competitive market to built the better widget. We now have potential for a background app to listen for VOIP calls while relaying our position and reporting our Pandora playlist all at the same time while typing up something in iWork. That’s pretty much the sweet spot for multi-tasking and as new use-cases appear, they’ll adopt new APIs.
There are fewer compatibility issues. Most people with iPhone or iPod touch are already on v3 of the software. A developer recently announced that around 4% of his iPhone OS traffic was taken up by original iPhones and iPod touch devices. The user never has to care – update the OS when asked, update the app when asked.
End of the day this is not about whether or not you optimise the unit to conserve battery when not connected or to ‘nice’ a process to get a few extra CPU cycles out of it. That’s what you do on the Mac if you’re hardcore and that percentage of people is sufficiently low that they don’t matter as a statistic.
This device has a battery which some folk are reporting lasts 12 hours under normal usage, not 10. They’re using it as single tasking devices. Apps released under OS4 will save their state immediately, permit background task completion, have background processes supported for certain activities and to the end user will have the same user experience as a multi-tasking machine. That’s what matters.
Again, let me pick these off.
Sure, Dropbox can implement that. But what about Mint, or Fluent News, or Digg or anything that *I* want to process in the background? Yes they can all do it, but why? Just to conform to AAPL’s ideas of how multitasking should work. I’m maintaining that there is another – possibly multiple other – ways to achieve backgrounding, without the potential problems that this implementation could precipitate.
I’m not seeing any validity in your agrument about the amount of real memory available. It is what it is, and whether AAPL deloy real MT or backgrounding it still needs to be managed/conserved? The OS can throttle performance by controlling the allocation whether or not the app is aware (via the API) or not? My point is that by giving priority to a specific task let the OS decide what resources it needs to prioritize – whether it is memory or cycles or both.
WRT conserving battery life, I can see several thingsan OS could do for that. If that was my top goal.
In the end we are agreeing on one thing. This will give user what they asked for, the ability to run things in the background. However, I keep returning to my main points. 1. That the unintended consequences of this implementation could be worse that the cure and 2. There are other implementations that would achieve the same immediate results, have no impacts on app developers and give me an even richer user experience.
Time will tell
Perhaps we should take a break and give others a chance to weigh in?
>>>Back in the olden days on the Mac, people were happy with the simple ‘co-operative multitasking’ that was presented by the Mac and Windows 95 and didn’t cream out for pre-emptive multitasking which came with the Windows NT kernel and (eventually) Mac OS X.
The first implementation of “multitasking” on the Mac was called Switcher. It was delightful thing for its time. What Apple is offering on the iPhone is more like that than, say, the kind of multitasking Palm offers on webOS. Hm.
Anyway, the Big News for me was — finally! Bluetooth keyboards can be used!
Bluetooth keyboards can be used in v3.2 – the software version that ships with iPad.
I think the multitasking being offered is a little more complex than Switcher though the constraints may be similar. iPhone OS already does ‘proper’ multitasking at the OS level, this is just at the userland level.
For me it’s the perfect compromise.
“Keeping up with the new APIs is always going to be something to differentiate themselves with.”
Disregarding the obvious disgust developers should hold for incompatible API versioning, there is a reason why the consumer should care – it favours Big Software Corporation, who can afford to have a team for that.
Thus the appstore quickly loses it’s value to independents. And the cycle begins over again elsewhere – maybe next time in shareware. No walled garden, just a plain old site with downloadable trial version, or ‘freemium’ in today’s vernacular.
I think the AppStore has been a major success for several independents as well as a solid earner for the big guys.
The new public APIs are a differentiator especially for independents who can, in general, move a lot quicker than big companies.
They’re also a reason why cross compilers are not a good idea – i.e. The new OS4 APIs won’t be supported by Adobe’s CS5 iPhone packager for at least a year. Maybe two.