Apple's iPad

[Asher]

Sure it will. For something like Pandora, the "REAL app" is the code that streams and plays the music. The rest of the app is just an advertising delivery system.

The disconnect here is you've no idea what you're talking about.

It's smoke and mirrors. If the REAL APP was running and TRUE MULTITASKING was supported, the developers would not need to go out of their way to develop a way for people to listen to music outside of the application. Apple would update the OS then all existing apps would work with true multitasking. You could open up Pandora, hit play, go back to the homescreen, launch a Twitter client...and both would keep running, and music would keep playing. With zero code change required.

Apple has approximated multitasking for many common situations (7 of them) via developer service APIs, but it is not true multitasking.

You may argue that it's just as good to the end user, which is true to the extent that it can be implemented. But that doesn't make it true multitasking, and it doesn't make it good to the developer (in fact, it is a headache).

Just like what happens during focus changes on any system, although this is, admittedly, a pretty extreme example.

This is patently not true. If you lose focus on iTunes on MacOS X or Windows (true multitasking systems), they keep on playing. If you lose focus on a movie playing in a movie player, it'll keep on playing on OS X or Windows (but will NOT ever keep on playing, even in iPhone OS 4.0, for iPhone).

[Hauldren Collider]

And in Windows Vista and newer it'll even keep rendering the whole window. Compositing

[Vanguard]

The disconnect here is you've no idea what you're talking about.

It's smoke and mirrors. If the REAL APP was running and TRUE MULTITASKING was supported, the developers would not need to go out of their way to develop a way for people to listen to music outside of the application. Apple would update the OS then all existing apps would work with true multitasking. You could open up Pandora, hit play, go back to the homescreen, launch a Twitter client...and both would keep running, and music would keep playing. With zero code change required.

Apple has approximated multitasking for many common situations (7 of them) via developer service APIs, but it is not true multitasking.

What is the difference between 'approximated' multitasking and 'real' multitasking? I don't see any. These 7 services multitask. Period They run while other apps are active. That is what multitasking is. They do it.

You may argue that it's just as good to the end user, which is true to the extent that it can be implemented. But that doesn't make it true multitasking, and it doesn't make it good to the developer (in fact, it is a headache).

In some ways it will be simpler for the developer. As I said earlier, what Apple is basically doing is finding which apps people want to multitask on their phones and absorbing most of the functionality of those apps into the OS. This should make it easier to program these sorts of apps, not harder. Just let the OS do the work.

This is patently not true. If you lose focus on iTunes on MacOS X or Windows (true multitasking systems), they keep on playing. If you lose focus on a movie playing in a movie player, it'll keep on playing on OS X or Windows (but will NOT ever keep on playing, even in iPhone OS 4.0, for iPhone).

And if you lose focus on Pandora, in 4.0 it will continue to play. Just like in full grown OS X.

Movies probably will not. But you don't want them to anyway. You want them to suspend, which is presumably what will happen.

Sure, the parts of Pandora that aren't music streaming and playing will get suspended. But this is pretty much what happens when you change focus anyway. My word processor does not continue to write my reports when I switch to Firefox. Well, I don't think it does. Maybe it writes slashfic while I am busy surfing and posts it under a pseudonym. Or maybe it doodles cartoons and submits them to the New Yorker.

But whatever Word does when I am not using it (and I am not going judge), mostly it is just suspended. Input from the keyboard is suspended, which is why I don't find all this stuff I just wrote in the middle of my report. Output to the screen is suspended, which I why I don't see a ghostly image of my report behind the Apolyton forums. Auto-correction is suspended so I can mispell words. Word under Vista is largely suspended when it does not have focus, just like most apps under 4.0.

Sure, apps won't be able to do computation in the background on iPhone OS 4.0. But guess what? You can't do that anyway. Because it is a phone. There are not enough cycles, not enough ram and not enough mAh hours. The N900 may have some capabilities that the iPhone won't. But trying to use those capabilities would slow the UI to a crawl and run down the battery in a couple of hours. Which is why most Maemo apps end up doing only what the iPhone will be able to do---- suspend while not in use, except for VoiP, mail and music.

[Asher]

What is the difference between 'approximated' multitasking and 'real' multitasking? I don't see any.

That is, indeed, the problem. I've tried to explain this, but you do not and will not understand.

These 7 services multitask. Period They run while other apps are active. That is what multitasking is. They do it.

Those 7 services multitask, but those 7 services are not technically part of the application. I'm not sure if you have a CS background (it's apparent to me that you do not), but those 7 services are actually Operating System threads, not real app threads. They have functionality which allows them to execute some code the app can expose, but it's not true multitasking simply because you are not running two or more full apps at once -- you are running one app at any given time with the OS polling and probing other apps for snippits of code in the background. This is not true multitasking.

While this implementation does, in fact, run two threads at once and by some very loose definition does "multitask", the fact that it is only possible to do so in a very limited fashion with very limited resources and only by the explicit actions of the running OS makes it a smoke-and-mirrors implementation.

If we actually used your logic, every app multitasked since version 1 of the OS since you could control the iPod from within any app. Every app multitasked once push notifications were enabled, also... Apple has essentially just extended the capabilities of that smoke-and-mirror mechanism to run 7 more types of background tasks, but this is not the same as multitasking.

The "background threads" are, in fact, completely separate from the apps themselves that are supposedly multitasking.

In some ways it will be simpler for the developer. As I said earlier, what Apple is basically doing is finding which apps people want to multitask on their phones and absorbing most of the functionality of those apps into the OS. This should make it easier to program these sorts of apps, not harder. Just let the OS do the work.

This is pretty epicly retarded.

If the OS supported true multitasking, every app would multitask without any extra work. Ever. Period. This is obviously the easiest way for developers to get multitasking working.
Instead, Apple has provided a very limited framework with very strict (and hard to attain) resource consumption guidelines which require new code to be written, debugged, and maintained to support background tasks. This is not, in any way, easier for the developers.

And if you lose focus on Pandora, in 4.0 it will continue to play. Just like in full grown OS X.

No, Pandora will not keep playing. Pandora will spawn a background system thread which will keep playing. This is the distinction that is very important to developers and important to the definition of a true multitasking OS.

Think of it this way: Instead of Pandora.exe keeping running while you play another app, Pandora.exe actually exits and a significantly smaller Pandora.svc (service) starts up and handles the audio streaming. In a true multitasking environment, Pandora.exe keeps running because you've not quit it. In iPhone OS 4, Pandora.exe actually "sleeps". Which means it's not true multitasking.

Movies probably will not. But you don't want them to anyway. You want them to suspend, which is presumably what will happen.

I'm not at all interested in your excuses for why it's not possible. Fact is, in a true multitasking OS, it would work just like every other piece of software.

A true multitasking OS lets 2 or more applications run at any given time. It doesn't care what they are or how it does it. You can run multiple tasks and the OS lets you. This is true multitasking, this is how desktop OSes work. This is not how iPhone OS works.

But whatever Word does when I am not using it (and I am not going judge), mostly it is just suspended. Input from the keyboard is suspended, which is why I don't find all this stuff I just wrote in the middle of my report. Output to the screen is suspended, which I why I don't see a ghostly image of my report behind the Apolyton forums. Auto-correction is suspended so I can mispell words. Word is almost completely suspended, just like most apps under 4.0.

But Word is not suspended. If you check your process explorer, it's still very much an active process. It's still in RAM. It is still running. It could still be running a grammar checker. It could still be spooling your document to the printer.

Similarly, if you're performing Excel calculations that take 5 minutes to do, when you tab out of it, it is NOT suspended. It continues to calculate and perform like an app even though it's not in focus.

You are confusing your terms again. "Suspended" has a very specific usage in computer science. A process or application is "suspended" when it is not currently active. It is not currently active when it is not loaded in the system RAM and does not have access to CPU cycles. The fact that the screen is minimized does not mean it is suspended.

[Hauldren Collider]

Ignoring Vanguard on any and all CS topics from here on out seems like a wise course of action.

[Vanguard]

Those 7 services multitask, but those 7 services are not technically part of the application.

This is hair-splitting. All modern operating systems have large and complicated sets of services (or daemons). And all (non-trivial) programs use these services. For many apps access to these services is almost the only thing the application does. So if the services continue to work over another program, that is multitasking, at an application level at least.

I'm not sure if you have a CS background (it's apparent to me that you do not), but those 7 services are actually Operating System threads, not real app threads.

Do you have a CS background? It is a little hard to tell. Half the time you sound as if you might know what you are talking about. The other half you post total nonsense such as:

No, Pandora will not keep playing. Pandora will spawn a background system thread which will keep playing. This is the distinction that is very important to developers and important to the definition of a true multitasking OS.

For some reason you seem to think that Pandora will stream and play music using one set of code when it is active and another, completely different set of code when it is inactive. This is so obviously not what is going to happen that it is difficult to see how you can believe it.

Clearly under 4.0 there will be a new class of "semi-public" services usable both by the OS and by apps. Apps, of course, will have a different set of policies than the OS, but the services will basically be the same.

So Pandora will not use "Pandora music playing" when it has focus and "OS music playing" when it does not. It will just use the "music playing" process and the "data streaming" process, both when it it has focus and when it does not.


So nothing changes when you switch applications. The semi-public "music playing" process continues without interruption. There is no need to "spawn a background thread" owned by the OS.

You are confusing your terms again. "Suspended" has a very specific usage in computer science. A process or application is "suspended" when it is not currently active.

Yes, I was a little bit loose in my use of the word suspended. I did so for purposes of simplicity and brevity.

Of course, what I did not do was use the word 'thread', when what I really meant was 'process'.....

[Dinner]

It looks cool but I still don't know what it would do to justify me buying it. I already have to carry around a laptop and it doesn't look like the Ipad will replace a laptop and the laptop does just about anything the Ipad does, more or less, so I don't think I need it. It seems like a cool toy but still just a toy.

[Asher]

This is hair-splitting. All modern operating systems have large and complicated sets of services (or daemons). And all (non-trivial) programs use these services. For many apps access to these services is almost the only thing the application does. So if the services continue to work over another program, that is multitasking, at an application level at least.

No, it's not hair-splitting. I'm talking about how it works. You're talking about how the user may perceive things in some situations.

I am explaining it is simply not true multitasking, which means multiple applications can run at any given time without any specific, limited code to enable it to continue when the focus is off of it.

Do you have a CS background? It is a little hard to tell. Half the time you sound as if you might know what you are talking about. The other half you post total nonsense such as:

For some reason you seem to think that Pandora will stream and play music using one set of code when it is active and another, completely different set of code when it is inactive. This is so obviously not what is going to happen that it is difficult to see how you can believe it.

That is exactly how it works. It's in the developer documentation which, IIUC, is now publicly available. You need to write specific additional resource-constrained callback functions to get this to work, it does not work with existing code.

Pandora itself and the code that'll play Pandora music while it's in the background are completely separate processes (AND threads). It is possible for Pandora to design it to always use the "background thread" to play music even while the app is in the foreground, but this has no impact on the lack of true multitasking (see below for more)

If you switch focus from Pandora to another app, then check the list of running applications & processes, the "Pandora" application & process is no longer running. By definition, this is not a true multitasking system.

Instead, you will see an Apple-owned daemon start up with low-priority thread.

If your argument is that because Apple's solution lets multiple threads run at once, where the non-focused app is a very restricted, specific-purpose thread, it is "true multitasking", then you utterly fail. It can't be true multitasking if the developer is given a specific framework to enable it with an extensive list of restrictions.

Simply put, true multitasking allows any application to continue running when the focus is not on it. That's the definitive definition of the term. If you're arguing that this is "just as good", you are wrong. If you're arguing that it may be "good enough" in terms of the demands of the device itself and how most users will use it, you'd probably be right and I'm not arguing that. I'm just pointing out that it's not true multitasking, it's an approximated implementation of it using multi-threading.

So nothing changes when you switch applications. The semi-public "music playing" process continues without interruption. There is no need to "spawn a background thread" owned by the OS.

It is indeed possible for Pandora specifically to always implement the actual music stream processing in a multitasking-enabled thread, but this is a specific implementation detail and not at all relevant to the discussion of true multitasking, which would involve the entire application being kept in memory...not just specific parts of it.

[Asher]

http://arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-android.ars

Apple takes aim at Adobe... or Android?

The already strict requirements that must be met for an application to be published on Apple's App Store are set to take a turn for the worse, as Apple's NDA-protected license agreement has now updated an already annoying existing clause, Section 3.3.1, to make it even more offensive.

The original clause stated:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

This clause has already frustrated developers in the past because there are tasks that developers would like to perform that can only be achieved through private APIs; though some have taken a risk and submitted applications that use such APIs, the result is often that the application is denied. The new version of 3.3.1 reads:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Things just got a whole lot more restrictive for iPhone developers. What this change means is that developers can no longer use software like Novell's MonoTouch, Unity3D, or Ansca's Corona to develop iPhone applications, and tools like Appcelerator's Titanium and PhoneGap are looking questionable. MonoTouch, Unity3D, and Corona allow developers to use the C# language and Lua scripting, respectively, to write iPhone applications. Titanium and PhoneGap allow application development using JavaScript and HTML; because they use WebKit behind the scenes to run that JavaScript, they might be OK.

The reasons that developers like and use these tools are many and varied. Titanium, PhoneGap, and Corona, in particular, offer rapid iPhone development environments that are simpler than the Cocoa and Objective-C environments used for native development. As such, they offer their users quicker, more responsive release cycles, and lower development costs. Unity3D provides a range of features to game developers like a 3D engine, a physics processing engine, audio processing, and so on—features that would be prohibitively expensive for most developers to write from scratch. MonoTouch more simply allows the use of a different programming language and different libraries, ones that certain developers might be more comfortable with.

A significant product that is soon to be added to this list of development tools is Adobe's Flash CS5.
The real enemy: Adobe

As is now well-known, Flash isn't supported on the iPhone (the license conditions prohibit that kind of runtime application), so in response, Adobe has given Flash CS5 the ability to produce iPhone applications, in a broadly similar manner to how the other tools work. As Adobe explains, Flash CS5 completely skips Objective-C, instead plumbing into the iPhone compiler to directly produce executable code.

Apple's seething dislike for Adobe has become increasingly apparent in recent years. It's a dislike that in many ways makes no real sense: most of Adobe's biggest products don't compete with Apple's (and vice versa), and using Adobe's applications has traditionally been one of the biggest reasons that people have chosen—and stuck with—Apple's platform. But that's all in the past; Apple has Flash in its sights and is doing its best to destroy it.

Adobe, for its part, has made some non-commital comments on the issue; the company still plans to ship Flash CS5, but its ability to create iPhone applications might turn out to be short-lived, to say the least.

Apple's new 3.3.1 restrictions have been met with some disdain from the developer community, too, and it's no surprise. After all, if followed literally, they'd prevent developers even from writing English language specifications for their programs—since such applications would not be originally written in one of the blessed languages! A case could be made that the rule change prevents even thinking or talking about iPhone programs. Of course, the App Store gatekeepers will not be quite so absurd, but there's certainly ample scope for inconsistent application of the rules. Nothing new there, unfortunately.
The other real enemy: Google

As well as hurting Adobe, and certainly tarnishing the company's brand new product, this move hurts Android. In fact, I think the harm done to Android could end up being even more substantial than the harm to Adobe. Although I would say that the biggest virtues of these banned tools are faster, easier development, the fact is that they also often encourage cross-platform development. Flash is perhaps the most obvious example of this, but MonoTouch, Unity3D, and Titanium all enable developers to write applications that are more easily ported to non-Apple platforms such as Windows and Android. Such conversion is not necessarily automatic—applications will typically need some amount of tailoring to adapt them to the different environments—but it's a big help.

Minority platforms are always going to be the biggest beneficiaries of cross-platform development. It might be hard to justify developing an application for a minority platform from scratch. But if I can take a program for the majority platform and then put in an extra 10% development effort to cover the minority too, that's a much more appealing prospect. Though Apple does not dominate the smartphone market taken as a whole (Symbian is the runaway leader, with RIM's BlackBerry in second place), I think it's clear that in the narrower market of, shall we say, mobile phone-computers, Apple is the leader. Symbian and BlackBerry devices are all too often relegated to being little more than phones with e-mail, and though applications can be developed for both, they have not inspired developers and users in the way that iPhone and Android have.
No real defense

Some observers strive to justify this decision by claiming it's better for Apple's users, because in their world all cross-platform apps are bad, so they're better off without. It's true that cross-platform apps often buck platform UI conventions, and so end up feeling kind of alien—available on lots of platforms, but not really fitting properly on any of them (as anyone who's had the misfortune to use iTunes on Window will testify). But it's not as though being platform-specific is some guarantee of quality. There are plenty of lousy natively-written iPhone applications out there, and these are often produced in a cookie-cutter fashion, so that they can be churned out en masse. In contrast, there are also lots of good cross-platform programs out there.

Nowhere is this more apparent than in the world of gaming. Games are in many ways a class of their own, because games generally offer unique user interfaces: interfaces that are tailored to the game, rather than leveraging the platform. And there are certainly a lot of developers out there producing high quality, popular games using tools like Flash. This idea that cross-platform applications will be bad, such that Apple's users are better off without them, just isn't universally true.

Yes, some cross-platform applications will be bad. Some native applications will be bad, too. The reasonable, equitable solution is not to ban the use of tools that produce cross-platform applications. It's to say "applications must conform to all appropriate user-interface guidelines" and ban any application that doesn't. This is something the company is already doing anyway, and something that's unlikely to be a big issue. The existing development toolkits for iPhone make it easier to produce cross-platform applications, but certainly don't enable the kind of Write Once Run Anywhere approach that Java once promised. They just enable developers to migrate the "working parts" of their applications from one platform to another. The all-important user interfaces will still need to be customized to the needs of the different mobile OSes.

No, this policy change can't be attributed to a desire to ensure the quality of the user experience. It's about control. Developers must choose to target iPhone explicitly, or not at all. Apple doesn't want anyone to even consider writing applications for other platforms, and is going to stand in the way of anyone trying to do so.
Open hostility

Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple's Xcode doesn't. Sometimes it's just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn't just hurt competitors. It hurts developers on Apple's platform, and in turn hurts the platform itself.

The absurdity of this is even more apparent if one thinks back to the initial announcemnt of the iPhone. The iPhone was never going to have an SDK. The mantra was "use web applications". Indeed, that was one of the driving forces behind Apple's creation of a first-rate mobile browser. Since the browser was going to be the application platform on iPhone, it had to be good. And indeed it was. The company was reluctant to produce an SDK; this was not simply a case of managing expectations, and keeping quiet about the SDK until it was good and ready. It was a sincere desire to use the web as the development platform. The eventual decision to release an SDK caught many within the company by surprise.

Web apps are still an option, of course, for developers willing to live with their inherent restrictions. For those who can stick with C and C++ for the majority of their development, some level of compatibility between iPhone and other platforms is still possible. But both options still fail to give the considerable benefits that the third-party development platforms provide.

Apple's current—and in our opinion, objectionable—position is now close to the complete opposite of its initial stance. From promoting openness and standards, the company is now pushing for an ever more locked-down and restricted platform. It's bad for competition, it's bad for developers, and it's bad for consumers. I hope that there will be enough of a backlash that the company is forced to reconsider, but with the draw of all those millions of iPhone (and now, iPad) customers, I fear that Apple's developers will, perhaps with some reluctance, just accept the restriction and do whatever Cupertino demands.

****ing Apple. They never change.

BTW, Wiggy, you can see why I don't accept your BS about how people shouldn't whine if things are only exposed in the private APIs. They're explicitly forbidden.

[Vanguard]

It looks cool but I still don't know what it would do to justify me buying it. I already have to carry around a laptop and it doesn't look like the Ipad will replace a laptop and the laptop does just about anything the Ipad does, more or less, so I don't think I need it. It seems like a cool toy but still just a toy.

Yeah, it is a little too expensive now. It is very nicely built and the screen is great but it is just not highly competitive with other means of doing the same thing.

There is some value in the base model, I guess, but the 3G ones with 32gb are over-priced.

When Apple can sell the 32gb 3G model for $500, then they will have killer product. Until then it is just too much compared to laptops.

[Wiglaf]

****ing Apple. They never change.

Did you even read the article. The whole thing is about Apple changing.

BTW, Wiggy, you can see why I don't accept your BS about how people shouldn't whine if things are only exposed in the private APIs. They're explicitly forbidden.

I don't understand how anyone can be upset about Apple's move here. They are killing the competition at no cost to their users.

[Asher]

By the way, the lack of true multitasking is essentially the excuse Apple is using for banning cross-compiled binaries: http://www.appleinsider.com/articles...titasking.html

It's the little **** like this which is why I took great pains to point out iPhoneOS 4 will not implement true multitasking. The lack of true multitasking means apps without very iPhoneOS 4-specific code will not work. This is a huge blow to many companies which use middleware companies like Appcelerator (I am wearing one of their free t-shirts right now incidentally ) which are widely used to create apps for Android and iPhone off one codebase -- it saves companies tons of money.

If the iPhone had true multitasking, this wouldn't matter at all.

The AppleInsider article is garbage, for what it's worth. It's not just the lack of true multitasking that the new restrictions are there, and we all know it.

[Asher]

And since I've been infuriated by the bias of the AppleInsider article, I feel I must counter-troll with absolute truths:

Apple's new Game Center is 100% a ripoff of Xbox Live, and their multitasking solution is 100% identical to the one detailed by Microsoft for Windows Phone 7 a while ago. Stealing ideas, all they do.

[Zevico]

And since I've been infuriated by the bias of the AppleInsider article, I feel I must counter-troll with absolute truths:

Apple's new Game Center is 100% a ripoff of Xbox Live, and their multitasking solution is 100% identical to the one detailed by Microsoft for Windows Phone 7 a while ago. Stealing ideas, all they do.

Is there something wrong with stealing ideas? I mean, are you accusing them of copyright or patent infringement, or are you just irritated?

[Hauldren Collider]

I think he's irritated at the fact that AppleInsider is acting like this is like software straight from Jesus Christ's Own Programming Company.