It STILL takes time, resources, etc. to create the meticulously arranged bits that get copied.
Yes, but it takes exactly the same amount of time to arrange those bits, no matter how many copies are eventually made.
Arranging bits is, of course, a valuable service, and the people who do it should get paid. But they should get paid for their labor, just like everyone else who provides a valuable service, and the way to do that is to find customers who are willing to pay them for the act of arranging those bits. And once they've been paid and the bits have been arranged, it doesn't matter how many copies anyone else makes.
I have no sympathy for someone who spends his own time performing a service that no one asked him to perform, just because he thinks he might be able to convince people to pay for it afterward, then finds out later that he can't. The time to arrange payment is before you do the work, not after.
Depends on what you want to use it for, I guess. It reportedly plays Homestar Runner, MySpace Music, and at least some of the games on Newgrounds. Like I said, it's not as good as the full Flash Player, but it's definitely better than nothing.
They are proposed parts of the HTML5 standard, but W3C forces new extensions to be tagged with the name of the only browser they're implemented in until a second party implements them.
In other words, they're non-standard features that Apple wishes other browser makers would implement so they'd become standard, kinda like Internet Explorer's old <marquee> tag. Got it.
Apple's reward for creating something of public value by donating these proposed capabilities to everyone, both through contribution to the standards process and an open source implementation in WebKit? A bunch of fuckhead slashtards like you seizing on the flimsiest of excuses to cry about how EEEEEVIL and HYPOCRITICAL they are.
No, please try to keep up. That's not their reward for creating something of public value; it's their reward for restricting their supposed "standards showcase" to users of their own browser.
The fact that you claim the developer link doesn't require UA spoofing, even though any attempt to actually view the demo through that page brings up the very same "You’ll need to download Safari to view this demo" message, shows how absolutely blinded you are by your need to defend Apple. Slashdot isn't the evil one here.
If you'd be even an ounce investigative or knowledgeable in HTML, CSS and JS, you would've checked the source code of these demos and quickly noticed that no vendor-specific CSS magic or alike is used in any of these demos - every piece of them use "web standard" parts as per the current HTML5 draft from the W3C.
If you had been even an ounce investigative or knowledgeable, you would've checked the source code of these demos -- or even the text on the page -- and quickly noticed vendor-specific CSS extensions like "-webkit-transform" and "-webkit-gradient". And then you could have avoided embarrassing yourself with your angry, inaccurate post.
The iPad is significantly more portable than a notebook (even a thin 13" notebook, like a MacBook Pro).
No, it isn't. You're confusing weight with portability. The iPad is lighter, but it isn't actually any more convenient to lug around: just like a notebook, you can either carry it in your hands or you can put it in a bag.
A smartphone, on the other hand, really is more portable: you can carry it in situations where you couldn't carry a notebook.
The difference between an iPhone and an iPad is comparable in magnitude to the difference between an iPad and a small (13") notebook.
No, not at all. A smartphone offers a huge portability advantage over a notebook: it fits in your pocket, eliminating the need for a bag. A tablet just makes your bag a few ounces lighter.
And neither of those are cases "where Flash is technologically better than both of those".
Sorry, I won't play your pointless semantic games. Flash is more portable than Apple's proprietary Cocoa Touch, and it's more powerful than HTML5. As a result, there are plenty of cases where it's the best choice out of all three for a given project; whether or not it's the best in all respects simultaneously is irrelevant.
As a solution for iPhone, iPod touch, and iPad, the combination of Cocoa Touch and HTML5 thoroughly outclasses Flash.
Sure, if you ignore the issue of portability -- which is exactly what Apple wants you to do.
And no, it's not clear at all that it's better than nothing. No Flash means no Flash. Flash Lite means some Flash works and some doesn't.
Yes, and some is better than none. Which part of that don't you understand?
And that doesn't even address the issue of most Flash being entirely unsuitable for multitouch.
That's because it's a red herring. The only "issue" with Flash on a touch screen is hover effects, which are certainly not vital to "most Flash". And HTML has hover effects too, so your logic would also have us abandon HTML in favor of some other proprietary Apple technology.
Also, those that say things like "Apple should allow Flash" seem to be ignorant of the fact that Flash is not on a single handheld device, except as a very recent beta for Android.
Not true. Flash Lite is already shipping on some phones, including the HTC Hero and Evo. It's not Flash Player 10.1, which is the beta you mentioned (and that beta is available for Android 2.2 users to try for themselves), but it's enough for many popular sites.
Cocoa Touch on the iPhone OS. As well as HTML5. There are zero cases where Flash is technologically better than both of those.
Flash is more portable than Cocoa Touch. It's more powerful than HTML5 and also has better development/design tools.
It's also far from clear that supporting Flash would be to Apple's benefit, and a watered-down version would be even worse.
Apple's benefit? Of course, they'd rather have you use their proprietary APIs. But isn't their customers' benefit what really matters?
As for the watered-down version: again, you're ignoring Flash Lite, which is certainly better than no Flash at all.
I think we can all agree that the liability caps were a stupid, stupid idea by now and if we retroactively enforce them, we essentially give the government to take down whatever business they don't really like. [...] it is simply unfair to change the rules of a game in progress.
If Congress can retroactively extend the length of copyrights that were granted half a century ago, then apparently changing the rules of a game in progress is A-OK.
Apple "leaving behind" some old phones that are too slow for multitasking doesn't seem that bad.
Ha! Too slow for multitasking? Is that you, Steve?
The iPhone 3G is faster than some Android devices, and those manage to multitask just fine while running interpreted code. The only way the iPhone 3G could be too slow to multitask native code would be if Apple's OS programmers were dangerously incompetent.
Compare that to Android, where people are still stuck on 1.6 while 2.3(?) is being sold. And those people on 1.6 are stuck with empty promises that "eventually" they'll get upgraded.
2.2 is available on a single device. Most of the people who were on 1.6 have already been upgraded -- the Hero and Moment just got 2.1 a few weeks ago -- and anyone who hasn't and is tired of waiting can root the device and install a third-party build of 2.x. Unlike Apple, Google doesn't claim that rooting is illegal.
To date I believe every iPhoneOS device can run the latest version of the OS.
That won't be true for long. iPhone 4.x's pseudo-multitasking feature is only going to be available on the 3GS, not the 3G.
Any loser can develop apps for android. That does two things in my mind. 1) floods the market with garbage 2) opens the door for malware, which we have already seen.
We've seen malware for the iPhone too. A lot of good Apple's policy has done there, huh?
if you read your own post - point 1 applies to android just the same. the version differences only impact a few niches of applications.
Same with the screen resolution issue. "If [the developer] followed the UI guidelines and used auto-resizing and system fonts", an Android app will fit whatever size screen it's running on.
An unresponsive piece of glass? Oh please. Troll harder...
Hmm? No trolling here. I've used an iPad, and I'm sorry if this offends you, but its keyboard is a joke. It's one thing to use a virtual keyboard with your thumbs, but using your whole hand to type on a piece of glass -- with no tactile feedback that your fingers are in the right place or that your keypress registered at all -- is uncomfortable and disorienting. I wouldn't want to type an SMS on that thing, let alone a series of emails or blog posts.
Remember those laser keyboards that hooked up to PDAs and projected a virtual keyboard on the table? Ever wonder why those didn't take off? Same reason.
Nice IRC client you maintain, I can see you are stuck in 90s, because computing has moved on. Even IRC clients [irssi.org] have... (avid IRC'er since 94)
Um... thanks?
Although I still have the link in my signature, ViRC has not been under active development since 2004. Three years ago I patched an exploit, but that was it. (Delphi was cool in its day, but I don't miss it at all now.)
I'm not sure what you mean with the irssi comparison - irssi and ViRC are very different programs.
Computing certainly has moved on since the 90s, but the iPad is a dead end. We will never "move on" from computers to tablets, any more than we'll "move on" from telephones to videophones: it's another one of those ideas that only really works in science fiction, where looking cool on film is more important than real-world concerns of portability, practicality, cost effectiveness, or comfort.
If it bothers you to type on an iPad, try using a Bluetooth Keyboard.
Are you supposed to carry that around the house with you (very inconvenient), or leave the keyboard on a desk somewhere (defeating the purpose of "not a device designed to be chained to a desk")? Or maybe spend $70 per room so there's always a keyboard in arm's reach?
I was AMAZED at how fun, yes fun, it was to use it with my Apple Wireless Keyboard (just wanted you to know I've drunk the kool aid).
Oh, don't worry, I could tell from your last post.
I seriously believe the iPad could be a great gaming device, if you prop the "screen" up somewhere, and use a bluetooth control. I would love it if Apple would let you use Playstation 3 etc controllers with it, or even if they sold their own.
...
Why on earth would you want to prop up a 10 inch screen to play games on it? You could get a real console for half the price, with better games and better graphics, and attach it to your home theater.
If you want a portable game system, the iPad might suffice, although there are better (and much more affordable) alternatives. But it's not suited at all for use as a fixed console.
I bet it's longer than they've put up with writing 160 character messages using 12 buttons.
I don't know about that. People are able to learn to type quickly on a phone keypad because the phone has real buttons - they can rely partially on their sense of touch to orient their fingers and detect when they've hit each key. The iPad doesn't have that; it feels like drumming on a desk.
"unresponsive piece of glass"? What have you been smoking? Have you even seen or used an iPad?
Yes, actually, I have.
One of the things that all reviewers of the iPad have agreed upon is its "snappiness". Its a VERY fast device to use! Webpages, apps, photos, movies, songs...they all POP up and "Just Work"(tm).
That's not the kind of responsiveness I was talking about. I mean there's no tactile feedback: it doesn't feel like you're pressing keys, it feels like you're drumming on your desk.
I agree, the iPad responds quickly to touch. That's great for scrolling, but it doesn't really help the typing situation.
If by videos, you mean Flash videos, the iPhone and iPad already support that.
Through a VNC-type application that exposes your browsing to an unknown third party, and comes with all the lag you'd expect from a remote desktop session running over the cellular network? That's no solution.
And they will support multitasking in the coming months.
No, they won't. What they'll support is a handful of predetermined background services that apps can ask the OS to perform for them. It covers a handful of popular applications of multitasking (like internet radio and background downloads), but it isn't true multitasking: while developers on other mobile OSes continue coming up with new things to do in the background, iPhone developers will be stuck hoping that Apple will add them in the next model.
Also, even that pseudo-multitasking is only coming to certain iPhone models.
But isn't the App Store a great invention, something that helps even small developers like me make a few bucks?
It's a decent idea. It was around long before Apple entered the phone market, of course: I was downloading apps from an online store onto my plain old cell phone many years ago. But even then, I wished there weren't a layer of bureaucracy and fees between writing an app and getting it on potential customers' phones. Apple lowered the barrier of entry a little bit, but not very much.
This is not a perfect world. It's a tragedy that evil people deliberately set out to ruin other peoples' computers in pursuit of a few bucks. But they do, and the iPhone software model stops them cold.
So does the Android software model -- and without iPhone-style censorship and restrictions.
Steve Jobs would like us to think that the locked-down, centrally controlled, "take it or leave it" approach is necessary to protect us from spyware and crashes, but it just isn't true. The existence of iPhone malware has shown that Apple's approach isn't even effective, let alone necessary, and Android has shown that you can design security into the OS and provide a convenient app repository without boxing users in.
Updating Facebook and jotting emails both require typing, though. How long do you think "most non-technicals" will put up with typing on an uncomfortable, unresponsive piece of glass? Five emails, maybe ten?
You are the one with the exceedingly odd position of saying that ANY CODE AT ALL will break under the new multitasking API.
Actually, no, that's not what I'm saying. I'm saying old code would have broken if Apple had restructured the API to allow for true multitasking. The need to support that old code, combined with their unwillingness to write a compatibility layer, may be why the iPhone is getting half-assed pseudo-multitasking instead.
The truth is, that the API could have been designed any way they like, because code doesn't know about the API until you program against it.
Programs are already written against an API, and the assumptions on which that API is founded would change.
So please inform us all just how code that never linked against a new API can possibly be broken by it.
No problem, although I suspect you're the only one who needs this explained to you.
Imagine a platform where programs interface with cars. A simple program might look like this: void main() {
CONNECTION conn = Connect();
InflateTire(conn, 0);
InflateTire(conn, 1);
InflateTire(conn, 2);
InflateTire(conn, 3);
Disconnect(conn); }
Now imagine that a year later, the platform is expanded to handle airplanes as well. The "new API" consists of a function CheckVehicleType() to distinguish between cars and planes, as well as a bunch of plane-specific functions.
Do you see how that would break the code above? It never linked against the new API, it doesn't know anything about the new API, and that's the problem. The old API had no facility for checking vehicle types, and old programs could assume that if they were running at all, then a car was connected. But that assumption is no longer true under the new API. The program will happily run even when a plane is connected, then crash when it tries to inflate a tire that isn't there.
The issues with breaking the monolithic-app assumption are a little more subtle, but not much. An app that only expected to run in certain situations would now find itself running in unexpected new situations.
That's totally wrong if you simply do a thought exercise. All applications written today assume they cannot run in the background, so the API is not limiting what they already do not do.
What a strange thing to say. By that logic, there's no such thing as a legacy compatibility issue, because old software was never designed to use features that didn't exist yet!
In reality, legacy issues exist precisely because of the thing you brought up: old code makes certain assumptions that were true at the time, and the old code breaks when new platform features cause those assumptions to become false.
The monolithic-app assumption under which legacy iPhone apps have been (and still are being) developed is not conducive to proper lifecycle management in a mobile environment.
Whether legacy apps were capable of multitasking is actually beside the point, in a way. Desktop applications use the same monolithic-app assumption even though they multitask, because they run in a very different environment: desktop OSes don't need to kill unused programs to save memory or CPU time. That's one reason why those OSes are unsuitable for smartphones.
In a smartphone environment, to enable multitasking while still allowing the OS to manage app lifecycle to conserve memory and battery, applications have to be built differently.
It's funny that I'm arguing that Apple was forced into this position by their legacy apps and you're arguing that they weren't. Because if they weren't, that means they deliberately chose a half-assed implementation when they could have done better. Is that really what you want to believe?
The iPhone already does this today (the memory part) with notifications, and view unloading.
I don't think so. Notifications are a way for the OS to reload a stopped application in response to an event; they don't change the fundamental structure of the app.
You seem to assume that more than, say, 2% of the population cares about multitasking
Not at all. Developers care about it, but users care about what they can do with their phone.
It's true that the iPhone OS update will enable many of the applications for which multitasking has been used so far -- but not all of them, and none of the applications that Apple hasn't anticipated. So when a hot new Android app comes out that uses multitasking for something that can't be faked by one of Apple's hand-picked background operations, iPhone users will be left to hope that iPhone 4.1 will add it.
Thus, even though users may not care about "multitasking" per se, the savvier users will be able to think ahead about what multitasking means for them. Kind of like selling a truck with 4 wheel drive: no one really cares how many wheels their truck uses to drive, they care about whether it'll get stuck in mud and snow. But savvy customers realize that trucks with 4 wheel drive are less likely to get stuck, so 4 wheel drive is a selling point in itself.
Slashdot Mirror
It STILL takes time, resources, etc. to create the meticulously arranged bits that get copied.
Yes, but it takes exactly the same amount of time to arrange those bits, no matter how many copies are eventually made.
Arranging bits is, of course, a valuable service, and the people who do it should get paid. But they should get paid for their labor, just like everyone else who provides a valuable service, and the way to do that is to find customers who are willing to pay them for the act of arranging those bits. And once they've been paid and the bits have been arranged, it doesn't matter how many copies anyone else makes.
I have no sympathy for someone who spends his own time performing a service that no one asked him to perform, just because he thinks he might be able to convince people to pay for it afterward, then finds out later that he can't. The time to arrange payment is before you do the work, not after.
Depends on what you want to use it for, I guess. It reportedly plays Homestar Runner, MySpace Music, and at least some of the games on Newgrounds. Like I said, it's not as good as the full Flash Player, but it's definitely better than nothing.
They are proposed parts of the HTML5 standard, but W3C forces new extensions to be tagged with the name of the only browser they're implemented in until a second party implements them.
In other words, they're non-standard features that Apple wishes other browser makers would implement so they'd become standard, kinda like Internet Explorer's old <marquee> tag. Got it.
Apple's reward for creating something of public value by donating these proposed capabilities to everyone, both through contribution to the standards process and an open source implementation in WebKit? A bunch of fuckhead slashtards like you seizing on the flimsiest of excuses to cry about how EEEEEVIL and HYPOCRITICAL they are.
No, please try to keep up. That's not their reward for creating something of public value; it's their reward for restricting their supposed "standards showcase" to users of their own browser.
The fact that you claim the developer link doesn't require UA spoofing, even though any attempt to actually view the demo through that page brings up the very same "You’ll need to download Safari to view this demo" message, shows how absolutely blinded you are by your need to defend Apple. Slashdot isn't the evil one here.
If you'd be even an ounce investigative or knowledgeable in HTML, CSS and JS, you would've checked the source code of these demos and quickly noticed that no vendor-specific CSS magic or alike is used in any of these demos - every piece of them use "web standard" parts as per the current HTML5 draft from the W3C.
If you had been even an ounce investigative or knowledgeable, you would've checked the source code of these demos -- or even the text on the page -- and quickly noticed vendor-specific CSS extensions like "-webkit-transform" and "-webkit-gradient". And then you could have avoided embarrassing yourself with your angry, inaccurate post.
The iPad is significantly more portable than a notebook (even a thin 13" notebook, like a MacBook Pro).
No, it isn't. You're confusing weight with portability. The iPad is lighter, but it isn't actually any more convenient to lug around: just like a notebook, you can either carry it in your hands or you can put it in a bag.
A smartphone, on the other hand, really is more portable: you can carry it in situations where you couldn't carry a notebook.
The difference between an iPhone and an iPad is comparable in magnitude to the difference between an iPad and a small (13") notebook.
No, not at all. A smartphone offers a huge portability advantage over a notebook: it fits in your pocket, eliminating the need for a bag. A tablet just makes your bag a few ounces lighter.
And neither of those are cases "where Flash is technologically better than both of those".
Sorry, I won't play your pointless semantic games. Flash is more portable than Apple's proprietary Cocoa Touch, and it's more powerful than HTML5. As a result, there are plenty of cases where it's the best choice out of all three for a given project; whether or not it's the best in all respects simultaneously is irrelevant.
As a solution for iPhone, iPod touch, and iPad, the combination of Cocoa Touch and HTML5 thoroughly outclasses Flash.
Sure, if you ignore the issue of portability -- which is exactly what Apple wants you to do.
And no, it's not clear at all that it's better than nothing. No Flash means no Flash. Flash Lite means some Flash works and some doesn't.
Yes, and some is better than none. Which part of that don't you understand?
And that doesn't even address the issue of most Flash being entirely unsuitable for multitouch.
That's because it's a red herring. The only "issue" with Flash on a touch screen is hover effects, which are certainly not vital to "most Flash". And HTML has hover effects too, so your logic would also have us abandon HTML in favor of some other proprietary Apple technology.
As soon as HTC brings out a proper iPhone competitor
Nexus One? Droid Incredible? Evo?
Microsoft Win 7 Mobile is really looking iffy to appear at all.
Uh, what?
Also, those that say things like "Apple should allow Flash" seem to be ignorant of the fact that Flash is not on a single handheld device, except as a very recent beta for Android.
Not true. Flash Lite is already shipping on some phones, including the HTC Hero and Evo. It's not Flash Player 10.1, which is the beta you mentioned (and that beta is available for Android 2.2 users to try for themselves), but it's enough for many popular sites.
Cocoa Touch on the iPhone OS. As well as HTML5. There are zero cases where Flash is technologically better than both of those.
Flash is more portable than Cocoa Touch. It's more powerful than HTML5 and also has better development/design tools.
It's also far from clear that supporting Flash would be to Apple's benefit, and a watered-down version would be even worse.
Apple's benefit? Of course, they'd rather have you use their proprietary APIs. But isn't their customers' benefit what really matters?
As for the watered-down version: again, you're ignoring Flash Lite, which is certainly better than no Flash at all.
I think we can all agree that the liability caps were a stupid, stupid idea by now and if we retroactively enforce them, we essentially give the government to take down whatever business they don't really like. [...] it is simply unfair to change the rules of a game in progress.
If Congress can retroactively extend the length of copyrights that were granted half a century ago, then apparently changing the rules of a game in progress is A-OK.
Apple "leaving behind" some old phones that are too slow for multitasking doesn't seem that bad.
Ha! Too slow for multitasking? Is that you, Steve?
The iPhone 3G is faster than some Android devices, and those manage to multitask just fine while running interpreted code. The only way the iPhone 3G could be too slow to multitask native code would be if Apple's OS programmers were dangerously incompetent.
Compare that to Android, where people are still stuck on 1.6 while 2.3(?) is being sold. And those people on 1.6 are stuck with empty promises that "eventually" they'll get upgraded.
2.2 is available on a single device. Most of the people who were on 1.6 have already been upgraded -- the Hero and Moment just got 2.1 a few weeks ago -- and anyone who hasn't and is tired of waiting can root the device and install a third-party build of 2.x. Unlike Apple, Google doesn't claim that rooting is illegal.
To date I believe every iPhoneOS device can run the latest version of the OS.
That won't be true for long. iPhone 4.x's pseudo-multitasking feature is only going to be available on the 3GS, not the 3G.
Any loser can develop apps for android. That does two things in my mind. 1) floods the market with garbage 2) opens the door for malware, which we have already seen.
We've seen malware for the iPhone too. A lot of good Apple's policy has done there, huh?
if you read your own post - point 1 applies to android just the same. the version differences only impact a few niches of applications.
Same with the screen resolution issue. "If [the developer] followed the UI guidelines and used auto-resizing and system fonts", an Android app will fit whatever size screen it's running on.
Check again. Taking something away from its rightful owner is stealing.
No one took the movie away from the studio. Quite the opposite, actually: the studio is now trying to take it away from them.
An unresponsive piece of glass? Oh please. Troll harder...
Hmm? No trolling here. I've used an iPad, and I'm sorry if this offends you, but its keyboard is a joke. It's one thing to use a virtual keyboard with your thumbs, but using your whole hand to type on a piece of glass -- with no tactile feedback that your fingers are in the right place or that your keypress registered at all -- is uncomfortable and disorienting. I wouldn't want to type an SMS on that thing, let alone a series of emails or blog posts.
Remember those laser keyboards that hooked up to PDAs and projected a virtual keyboard on the table? Ever wonder why those didn't take off? Same reason.
Nice IRC client you maintain, I can see you are stuck in 90s, because computing has moved on. Even IRC clients [irssi.org] have... (avid IRC'er since 94)
Um... thanks?
Although I still have the link in my signature, ViRC has not been under active development since 2004. Three years ago I patched an exploit, but that was it. (Delphi was cool in its day, but I don't miss it at all now.)
I'm not sure what you mean with the irssi comparison - irssi and ViRC are very different programs.
Computing certainly has moved on since the 90s, but the iPad is a dead end. We will never "move on" from computers to tablets, any more than we'll "move on" from telephones to videophones: it's another one of those ideas that only really works in science fiction, where looking cool on film is more important than real-world concerns of portability, practicality, cost effectiveness, or comfort.
If it bothers you to type on an iPad, try using a Bluetooth Keyboard.
Are you supposed to carry that around the house with you (very inconvenient), or leave the keyboard on a desk somewhere (defeating the purpose of "not a device designed to be chained to a desk")? Or maybe spend $70 per room so there's always a keyboard in arm's reach?
I was AMAZED at how fun, yes fun, it was to use it with my Apple Wireless Keyboard (just wanted you to know I've drunk the kool aid).
Oh, don't worry, I could tell from your last post.
I seriously believe the iPad could be a great gaming device, if you prop the "screen" up somewhere, and use a bluetooth control. I would love it if Apple would let you use Playstation 3 etc controllers with it, or even if they sold their own.
...
Why on earth would you want to prop up a 10 inch screen to play games on it? You could get a real console for half the price, with better games and better graphics, and attach it to your home theater.
If you want a portable game system, the iPad might suffice, although there are better (and much more affordable) alternatives. But it's not suited at all for use as a fixed console.
I bet it's longer than they've put up with writing 160 character messages using 12 buttons.
I don't know about that. People are able to learn to type quickly on a phone keypad because the phone has real buttons - they can rely partially on their sense of touch to orient their fingers and detect when they've hit each key. The iPad doesn't have that; it feels like drumming on a desk.
"unresponsive piece of glass"? What have you been smoking? Have you even seen or used an iPad?
Yes, actually, I have.
One of the things that all reviewers of the iPad have agreed upon is its "snappiness". Its a VERY fast device to use! Webpages, apps, photos, movies, songs...they all POP up and "Just Work"(tm).
That's not the kind of responsiveness I was talking about. I mean there's no tactile feedback: it doesn't feel like you're pressing keys, it feels like you're drumming on your desk.
I agree, the iPad responds quickly to touch. That's great for scrolling, but it doesn't really help the typing situation.
If by videos, you mean Flash videos, the iPhone and iPad already support that.
Through a VNC-type application that exposes your browsing to an unknown third party, and comes with all the lag you'd expect from a remote desktop session running over the cellular network? That's no solution.
And they will support multitasking in the coming months.
No, they won't. What they'll support is a handful of predetermined background services that apps can ask the OS to perform for them. It covers a handful of popular applications of multitasking (like internet radio and background downloads), but it isn't true multitasking: while developers on other mobile OSes continue coming up with new things to do in the background, iPhone developers will be stuck hoping that Apple will add them in the next model.
Also, even that pseudo-multitasking is only coming to certain iPhone models.
But isn't the App Store a great invention, something that helps even small developers like me make a few bucks?
It's a decent idea. It was around long before Apple entered the phone market, of course: I was downloading apps from an online store onto my plain old cell phone many years ago. But even then, I wished there weren't a layer of bureaucracy and fees between writing an app and getting it on potential customers' phones. Apple lowered the barrier of entry a little bit, but not very much.
This is not a perfect world. It's a tragedy that evil people deliberately set out to ruin other peoples' computers in pursuit of a few bucks. But they do, and the iPhone software model stops them cold.
So does the Android software model -- and without iPhone-style censorship and restrictions.
Steve Jobs would like us to think that the locked-down, centrally controlled, "take it or leave it" approach is necessary to protect us from spyware and crashes, but it just isn't true. The existence of iPhone malware has shown that Apple's approach isn't even effective, let alone necessary, and Android has shown that you can design security into the OS and provide a convenient app repository without boxing users in.
Updating Facebook and jotting emails both require typing, though. How long do you think "most non-technicals" will put up with typing on an uncomfortable, unresponsive piece of glass? Five emails, maybe ten?
You are the one with the exceedingly odd position of saying that ANY CODE AT ALL will break under the new multitasking API.
Actually, no, that's not what I'm saying. I'm saying old code would have broken if Apple had restructured the API to allow for true multitasking. The need to support that old code, combined with their unwillingness to write a compatibility layer, may be why the iPhone is getting half-assed pseudo-multitasking instead.
The truth is, that the API could have been designed any way they like, because code doesn't know about the API until you program against it.
Programs are already written against an API, and the assumptions on which that API is founded would change.
So please inform us all just how code that never linked against a new API can possibly be broken by it.
No problem, although I suspect you're the only one who needs this explained to you.
Imagine a platform where programs interface with cars. A simple program might look like this:
void main()
{
CONNECTION conn = Connect();
InflateTire(conn, 0);
InflateTire(conn, 1);
InflateTire(conn, 2);
InflateTire(conn, 3);
Disconnect(conn);
}
Now imagine that a year later, the platform is expanded to handle airplanes as well. The "new API" consists of a function CheckVehicleType() to distinguish between cars and planes, as well as a bunch of plane-specific functions.
Do you see how that would break the code above? It never linked against the new API, it doesn't know anything about the new API, and that's the problem. The old API had no facility for checking vehicle types, and old programs could assume that if they were running at all, then a car was connected. But that assumption is no longer true under the new API. The program will happily run even when a plane is connected, then crash when it tries to inflate a tire that isn't there.
The issues with breaking the monolithic-app assumption are a little more subtle, but not much. An app that only expected to run in certain situations would now find itself running in unexpected new situations.
That's totally wrong if you simply do a thought exercise. All applications written today assume they cannot run in the background, so the API is not limiting what they already do not do.
What a strange thing to say. By that logic, there's no such thing as a legacy compatibility issue, because old software was never designed to use features that didn't exist yet!
In reality, legacy issues exist precisely because of the thing you brought up: old code makes certain assumptions that were true at the time, and the old code breaks when new platform features cause those assumptions to become false.
The monolithic-app assumption under which legacy iPhone apps have been (and still are being) developed is not conducive to proper lifecycle management in a mobile environment.
Whether legacy apps were capable of multitasking is actually beside the point, in a way. Desktop applications use the same monolithic-app assumption even though they multitask, because they run in a very different environment: desktop OSes don't need to kill unused programs to save memory or CPU time. That's one reason why those OSes are unsuitable for smartphones.
In a smartphone environment, to enable multitasking while still allowing the OS to manage app lifecycle to conserve memory and battery, applications have to be built differently.
It's funny that I'm arguing that Apple was forced into this position by their legacy apps and you're arguing that they weren't. Because if they weren't, that means they deliberately chose a half-assed implementation when they could have done better. Is that really what you want to believe?
The iPhone already does this today (the memory part) with notifications, and view unloading.
I don't think so. Notifications are a way for the OS to reload a stopped application in response to an event; they don't change the fundamental structure of the app.
You seem to assume that more than, say, 2% of the population cares about multitasking
Not at all. Developers care about it, but users care about what they can do with their phone.
It's true that the iPhone OS update will enable many of the applications for which multitasking has been used so far -- but not all of them, and none of the applications that Apple hasn't anticipated. So when a hot new Android app comes out that uses multitasking for something that can't be faked by one of Apple's hand-picked background operations, iPhone users will be left to hope that iPhone 4.1 will add it.
Thus, even though users may not care about "multitasking" per se, the savvier users will be able to think ahead about what multitasking means for them. Kind of like selling a truck with 4 wheel drive: no one really cares how many wheels their truck uses to drive, they care about whether it'll get stuck in mud and snow. But savvy customers realize that trucks with 4 wheel drive are less likely to get stuck, so 4 wheel drive is a selling point in itself.