yeah, Steve Jobs didn't mention anything about his $50 AV cable for the iPhone being the ONLY one that works - thanks to his software updates, my $7 cable no longer does, as the software now looks for a CHIP in apples cable before sending video out.
The hardest most costly solution is always better? No pain no gain? Why do you think an app is automatically crappy because it may have been written via compiler? I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler. Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers ? maybe throw in a feature or two and call it an upgrade). If they choose not to update their apps, again, so what. The user has the use of the original app until it's broken by an OS change. On average they paid all of a few bucks, vs never having the opportunity to use the app at all because it was excluded in the first place. If the app is on the expensive side, again, more incentive for the developer to update their product if it is selling well. If not enough people are buying it to make it worth keeping it running, again, so what if it dies. Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Frankly, I think you're letting yourself be suckered into buying Jobs' BS on this one. I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple. It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I completely agree and think this is a shot across the bow of Android.
Apple would like developers to choose one or the other. At this point in time they believe most will choose iPhone.
Yes, it's unknown, but Unity thinks they're in compliance AND you haven't seen Apple publicly attacking Unity. That's not definitive, but it is certainly suggestive.
Unity clearly does not think that. They have state that, at best, they are uncertain.
Quote:
Dear Unity developers,
I wanted to take a moment today to follow up on my blog post last Friday regarding the recent controversial changes in the the iPhone OS 4.0 beta ToS. The news about this change from Apple has drawn a lot of attention and stirred up very strong emotions in many developer communities, including ours. There’s also been a great deal of commentary about how these changes will be interpreted and applied by Apple and still more discussion about Apple’s intent with these changes. Unity learned of these changes with the rest of you just last Thursday and today, there remains a great deal of uncertainty about these changes being final and what we may need to do to comply.
We’re meeting with Apple next week to discuss the matter, and our engineers have been discussing possible technical solutions as well. Of course, we’ll provide you with immediate updates as soon as we have any new information.
Just in case the ToS changes do end up being a problem, we’re already working hard to find and implement solutions to maintain uninterrupted compliance with Apple’s ToS.
Though any uncertainly about Unity’s future on this platform is unpleasant, our feeling is that we’ll be okay. We remain firmly committed to providing you with the very best game engine for the iPhone, iPad, and iPod Touch. Thank you all so much for your patience and support. It means everything to us.
-David Helgason, CEO Unity, April 14, 2010,
Keyword being 'uncertainty'.
To be clear, you are probably correct in your belief that unity will be allowed, even if it means a exception to the rules. Just that if you are going to argue one way or the other, make sure that what you are stating is actually true.
Quote:
Originally Posted by jragosta
That is not correct. You've been able to use hardware acceleration on the Mac for many years - as long as you use the correct APIs (CoreVideo, OpenCL, OpenGL, etc). Other companies did just fine using Apple's proper APIs.
Adobe refused to do so because they would have had to hire some real Mac programmers, and demanded that Apple give them direct access to the hardware - which is ALWAYS a bad idea, particularly for a product like Flash which is so full of security holes, anyway.
Furthermore, hardware acceleration affects only video playback. If that was the only area where Flash sucked, you might have a point. But Flash sucks CPU cycles and battery life and crashes and opens security holes even on sites that don't play back video, so Flash's problems go far deeper than this.
Again, you are generally correct. Adobe has had access to APIs, as others have, that should have allowed them to build a better Flash. But what Adobe was specifically talking about in this case was access to hardware acceleration for h.264. This is not asking for direct access to the hardware, but for access to an Apple API for hardware acceleration through the NVIDIA GPU for H.264. This was not available for Mac developers until recently, except for apps that were simply Quicktime wrappers.
However, Adobe is being intentionally misleading here, as they make it sound like access to this would magically make Flash better all around. It would not. It would definitely make H.264 playback perform better, but that is part of what Flash offers. Even if access to this API made their H.264 playback as good as possible, it doesn't make the rest of Flash any better. It won't make it less buggy, it won't make Flash crash my browser less and it won't help any video type other than H.264. They are also being disingenuous in overstating the scope of how access to this API will improve the Flash experience for Mac users in general. It will only benefit those Macs with the newer NVIDIA cards, so the majority of Mac users will see absolutely no benefit.
But they were being honest when they claimed that did not have access to this specific API. Now they do and it is up to them to show everyone that can actually make a useable Flash. They won't.
Well, fair enough. My apologies. This is one of those things that happen on message boards sometimes. You see, from my perspective, that post is NOT how it started. But now I can more easily see where you are coming from, since that's where you jumped in.
If you want more context, go back and look what I was responding to at that point. "SpotOn" had just offered the HP Slate as PRESENT TENSE evidence that Flash is not a problem. You came in just in time for my facetious response, and I (mistakenly) took your information as a continuation of the earlier debate. I honestly thought you were holding up the HP Slate as a valid example of a mobile device that suffered no performance degradation from Flash. I couldn't fathom that conclusion from the evidence you offered, but there it was (or so I thought).
Note: FWIW, I still have my doubts about the HP Slate hitting the market any time soon, if ever, and I also question how good its battery life REALLY will be under the load of Windows and Flash. HP has to realize that if the battery life is only 5 hours and the OS is too "filesystem like", that it will get laughed out of the contest just like earlier tablets have been.
And, note to self: don't be facetious in print. It doesn't come through.
Thompson
No worries man. I figured there was some sort of mixup
Show us this proof that using more power doesn't require power. We'll all be waiting right here in reality for you to return.
You can test this yourself so lying isn't going to win any favour. Unplug a laptop, any laptop, then open up Chrome or Safari. Play a YouTube video using HTML5. Check the battery time remaining. Then play that same YouTube video using Flash. Check the battery time remaining. Repeatable, empirical evidence.
OK, then maybe you can explain to me how Adobe managed to break the laws of physics.
When I run Safari and stay away from Flash sites or use clicktoflash, my computer never gets hot and CPU usage for Safari is 10-20% max. As soon as I go to a Flash site, the CPU usage shoots over 100% and the bottom of the computer gets very hot.
Now, if the computer is getting hot and the CPU is doing much more work, where is that coming from if not from the battery? I'm really interested in the mechanism they're using to create heat and power CPU cycles that doesn't use the battery.
Physics? Really? Guy, you're grabbing at straws. iPhone wouldn't run Flash Lite, it would run Flash 10-10.1 and those are proven to outperform HTML5 implementations and 10.1 is optimized for mobile use.
And yet, Adobe keeps slipping the go-live date. Repeatedly. As long as it's a prototype, it's a prototype. Call me when we can run some benchmarks on performance and battery life.
The thing is, I doubt anyone from the Android team at Google will have the stones to tell Adobe that performance sucks and it's not ready. So I'm sure it will eventually ship, but I'm unconvinced that it will be worth a sh!t when it does.
10 is GPU optimized. 10.1 is even more so. 10 has a 97.0% adoption rate. HTML5 has a 0% adoption rate. If you want to talk betas, consider that HTML5 is just a draft spec. Don't talk about what you don't know.
Physics? Really? Guy, you're grabbing at straws. iPhone wouldn't run Flash Lite, it would run Flash 10-10.1 and those are proven to outperform HTML5 implementations and 10.1 is optimized for mobile use.
Yes, physics. Get yourself an education and maybe you'll understand it.
It's very simple. My laptop doesn't get hot when I'm not running Flash. As soon as I run Flash, the computer gets very hot and the fans come on. Ergo, Flash is generating much more heat than the non-Flash activities.
Physics says that the heat can't appear from nowhere. There must be energy used somewhere. The only energy source is the battery. Proof positive that Flash has excess battery consumption.
None of your Adobe shill web sites refute that simple fact. In fact, none of them address battery life at all. So please stop with the lies. Until you can find a way to break the laws of physics, you're wrong.
I'm also curious why it is that you can't even read Adobe's specs? Flash 10.0 is completely incapable of running on iPhone-like devices. Flash 10.1 (even if it ever comes out) requires an 800 MHz A8 - which doesn't exist on any current iPhone. So where do you get that the iPhone would run Flash 10.1?
(Not to mention, of course, that early reports are that 10.1 isn't all that good even on a 1 GHz Snapdragon).
You Adobe shills aren't very good at what they're doing.
He's just trolling. Each post filled with more and more lies. He stated that "HTML5 has a 0% adoption rate" when it's the basis of WebOS and in Android and iPhone OS' browser for years now. He also claims that the Cortex-A8 @ 800MHz system that is needed to run Flash 10.1 is more efficient than the ARM11 @ 400MHz system that can stream video just fine. He's obviously invested somehow or paid by Adobe to troll here. I've reported him to the mods.
The only people who are this rabid about supporting Flash are the deluded script kiddies who only know how to do connect-the-dots "development" and insist on calling themselves "programmers".
I think you underestimate the turmoil this will create but time will tell.
Fair enough, too.
Well, I do believe that it's going to create some turmoil in "developer land", that much is certain. I have no idea how much. I haven't even tried to estimate it, so your statement that I "underestimate" is basically true by default. I guess we'll find out just how many developers and/or SDK creators pitch a fit like that Adobe employee did. That may be our only measure going forward. The two tools that you mentioned (i.e. MonoTouch and Unity) seem to be OK with it... as far as we know at this point. So perhaps it's much ado about nothing.
With regard to the end user in this case, it seems that the "turmoil" is limited since the precedent of control has been set in the early stages. (Of course, other colorful words have been proposed to describe the closed ecosystem, but "turmoil" is not one of the main ones. The other adjectives are best left to another thread!) And likewise this control will minimize "turmoil" to Apple when they need to move the platform forward. Minimizing turmoil to Apple and the end user seems like something that Apple is historically interested in. As for the developer...
What I have been talking about here, and what Steve means too, is something I learned from experience: starting fresh with a useful third-party API to create an application can be very fruitful. Kind of like a marriage in the beginning. And then the honeymoon ends and the maintenance soon begins. (Back talking only about code, lest I piss someone off...) It's the maintenance that becomes a nightmare, and not just for the developer. I'm talking about the end user, the developer, and Apple too (if enough applications used the third-party SDK). When a whole slew of applications either break or get left behind when platform transitions occur, the end user gets mad. And they blame the developer or Apple. The SDK creator gets a free pass, at least in the public eye. The developer can rant and rave all she wants (begging for an updated SDK) but she is at the mercy of the SDK creator. And if she has millions of lines of source built around that SDK, there is lock-in, and there's not much she can do about it but wait, and wait, and wait some more. Meanwhile, the customers are waiting, many of them angry at everyone except the creator of the SDK (whom they know virtually nothing about... nor do they care). It's a bloody nightmare, and if you've never lived it, then I can see why YOU might underestimate or not even appreciate that.
Also, whereas it may seem like I'm talking about something that *might* occur, it's not like that. As a rule, with any application that depends on a third-party SDK, this maintenance issue will happen eventually. That is especially true now that we are in the middle of a technology shift. Who knows what processor the next iPhone will have? Perhaps it will have a different byte-order, and some of these SDKs will break. (This is only an example. There is always something that trips up an SDK if the underlying change is non-trivial.) With XCode, you will only have to flip a switch to compile for the new processor. If you also use something else, you may have to wait a year. Literally. With pissed customers. And if there is another significant change in the meantime... ugh! ... the configuration management becomes very sticky (for everybody, including the end user who doesn't understand why there are so many complicated versions)!
I agree that Apple is interested in maintaining App market space advantage, by forcing developers to choose. But lest you think that is the only, or even the primary, reason, you should know that they made a similar move to control the development tools for Mac OS X when they introduced XCode and froze out Metrowerks. And this was done as an underdog, where it was decidedly NOT in their interest to wall themselves off if all they desired was business dominance. By the way, in case you go there, in order to accomplish this control all they had to do was stop helping Metrowerks and others. (The Mac OS system APIs are far more rich than the iPhone OS at this point in time.) So they didn't have to introduce this language in the developer's agreements. But I figure they would have if it were necessary to accomplish the goal. We all switched over to XCode in fairly short order, and the transition to Intel went much more smoothly than it otherwise would have. (Sure, the emulator helped, but I'm talking about the development of Universal code.)
My conclusion: yes, Apple is interested in maintaining their App Store advantage. But my experience and evidence is enough to convince me that they would have made this move even if it would not have been immediately beneficial to their market share position. (As with Mac OS X in the past.) Two birds with one stone, here.
The hardest most costly solution is always better? No pain no gain? Why do you think an app is automatically crappy because it may have been written via compiler?
Well, you put a hell of a lot of words in my mouth right there. I didn't say any of that. Using a third-party API can be very useful at first, and the applications can be great. Then the maintenance starts, and it is always an issue, not just sometimes and not just for Apple or the developer. Please look at my response to backtomac just above.
Then you say some things that are true, and I agree with...
Quote:
Originally Posted by GMHut
I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler.
Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers — maybe throw in a feature or two and call it an upgrade).
... exactly, and that's where the trouble comes in. What if there is great demand for an updated application, and the developer absolutely wants to sell an update, but the SDK developer in the middle is slow to update the tools that the developer is now reliant upon? Screwed. What if the SDK is finally updated, but in order to maintain continuity across multiple platforms, some of the new capabilities of one particular platform are not exposed to the developer? Then your app starts to become stale and crappy relative to your competition. You might think that these issues give the tool maker sufficient incentive to update their tools, so they can charge the developer again, but that doesn't mean they will be able to do so in a timely fashion. There would essentially be an uncontrollable mechanism smack dab in the middle of the development chain, and in a dynamic environment that is absolutely a serious issue. Show me someone who says otherwise and I'll show you someone that hasn't been there, done that.
Quote:
Originally Posted by GMHut
Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Well the difference is a matter of scale. The seemingly arbitrary pulling of apps is bound to be maddening to an affected user. In my mind, there is a valid debate that could be had regarding that.
The difference here is that instead of a relatively small fraction of apps going bye-bye (presumably for a reason, which is debatable on a case-by-case basis) we have potential for a significant number of apps going bye-bye for no good reason at all other than the complicated development chain.
Quote:
Originally Posted by GMHut
Frankly, I think you're letting yourself be suckered into buying Jobs' BS on this one.
It's clear to me that you haven't lived the development nightmare that I've described above. It's also fairly common behavior that if someone hasn't experienced something firsthand, then they tend to question the value of the lessons learned. Add this to a fairly common opinion of Steve Jobs as a manipulative prick, and *POOF* of course you aren't going to believe him. That's your prerogative.
But that doesn't give you the right to assume ANYTHING about me, least of all that I am a sucker. I don't suck up to Steve Jobs. I'm going by my experience, and it just so happens to match his explanation in this case.
Quote:
Originally Posted by GMHut
I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple.
And I believe that BOTH reasons are true. For my reasoning, see my response to "backtomac" above. In particular, I believe that Apple would have made this same move even if they DIDN'T have the market share advantage right now. They've displayed similar behavior before, when they were the underdogs.
Quote:
Originally Posted by GMHut
It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I disagree. Given the tectonic shifts that are about to hit, developers and users will be much better off if the development system is streamlined. It looks like there are still going to be useful 3rd party tools out there (backtomac pointed me to MonoTouch).
I had a hunch that was going to happen after HP bought Palm and provided their reasoning. It just didn't make sense to me that HP would try to march down two different tablet roads at once. And while a HP/Palm tablet has an uphill battle because it will arrive late to the Apple and Google tablet party, success with Windows 7 in the near term is even more unlikely. So that's the one I figured would get punted.
Comments
That's a big F-YOU to 3rd party support.
The hardest most costly solution is always better? No pain no gain? Why do you think an app is automatically crappy because it may have been written via compiler? I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler. Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers ? maybe throw in a feature or two and call it an upgrade). If they choose not to update their apps, again, so what. The user has the use of the original app until it's broken by an OS change. On average they paid all of a few bucks, vs never having the opportunity to use the app at all because it was excluded in the first place. If the app is on the expensive side, again, more incentive for the developer to update their product if it is selling well. If not enough people are buying it to make it worth keeping it running, again, so what if it dies. Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Frankly, I think you're letting yourself be suckered into buying Jobs' BS on this one. I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple. It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I completely agree and think this is a shot across the bow of Android.
Apple would like developers to choose one or the other. At this point in time they believe most will choose iPhone.
Yes, it's unknown, but Unity thinks they're in compliance AND you haven't seen Apple publicly attacking Unity. That's not definitive, but it is certainly suggestive.
Unity clearly does not think that. They have state that, at best, they are uncertain.
Dear Unity developers,
I wanted to take a moment today to follow up on my blog post last Friday regarding the recent controversial changes in the the iPhone OS 4.0 beta ToS. The news about this change from Apple has drawn a lot of attention and stirred up very strong emotions in many developer communities, including ours. There’s also been a great deal of commentary about how these changes will be interpreted and applied by Apple and still more discussion about Apple’s intent with these changes. Unity learned of these changes with the rest of you just last Thursday and today, there remains a great deal of uncertainty about these changes being final and what we may need to do to comply.
We’re meeting with Apple next week to discuss the matter, and our engineers have been discussing possible technical solutions as well. Of course, we’ll provide you with immediate updates as soon as we have any new information.
Just in case the ToS changes do end up being a problem, we’re already working hard to find and implement solutions to maintain uninterrupted compliance with Apple’s ToS.
Though any uncertainly about Unity’s future on this platform is unpleasant, our feeling is that we’ll be okay. We remain firmly committed to providing you with the very best game engine for the iPhone, iPad, and iPod Touch. Thank you all so much for your patience and support. It means everything to us.
-David Helgason, CEO Unity, April 14, 2010,
Keyword being 'uncertainty'.
To be clear, you are probably correct in your belief that unity will be allowed, even if it means a exception to the rules. Just that if you are going to argue one way or the other, make sure that what you are stating is actually true.
That is not correct. You've been able to use hardware acceleration on the Mac for many years - as long as you use the correct APIs (CoreVideo, OpenCL, OpenGL, etc). Other companies did just fine using Apple's proper APIs.
Adobe refused to do so because they would have had to hire some real Mac programmers, and demanded that Apple give them direct access to the hardware - which is ALWAYS a bad idea, particularly for a product like Flash which is so full of security holes, anyway.
Furthermore, hardware acceleration affects only video playback. If that was the only area where Flash sucked, you might have a point. But Flash sucks CPU cycles and battery life and crashes and opens security holes even on sites that don't play back video, so Flash's problems go far deeper than this.
Again, you are generally correct. Adobe has had access to APIs, as others have, that should have allowed them to build a better Flash. But what Adobe was specifically talking about in this case was access to hardware acceleration for h.264. This is not asking for direct access to the hardware, but for access to an Apple API for hardware acceleration through the NVIDIA GPU for H.264. This was not available for Mac developers until recently, except for apps that were simply Quicktime wrappers.
However, Adobe is being intentionally misleading here, as they make it sound like access to this would magically make Flash better all around. It would not. It would definitely make H.264 playback perform better, but that is part of what Flash offers. Even if access to this API made their H.264 playback as good as possible, it doesn't make the rest of Flash any better. It won't make it less buggy, it won't make Flash crash my browser less and it won't help any video type other than H.264. They are also being disingenuous in overstating the scope of how access to this API will improve the Flash experience for Mac users in general. It will only benefit those Macs with the newer NVIDIA cards, so the majority of Mac users will see absolutely no benefit.
But they were being honest when they claimed that did not have access to this specific API. Now they do and it is up to them to show everyone that can actually make a useable Flash. They won't.
Well, fair enough. My apologies. This is one of those things that happen on message boards sometimes. You see, from my perspective, that post is NOT how it started. But now I can more easily see where you are coming from, since that's where you jumped in.
If you want more context, go back and look what I was responding to at that point. "SpotOn" had just offered the HP Slate as PRESENT TENSE evidence that Flash is not a problem. You came in just in time for my facetious response, and I (mistakenly) took your information as a continuation of the earlier debate. I honestly thought you were holding up the HP Slate as a valid example of a mobile device that suffered no performance degradation from Flash. I couldn't fathom that conclusion from the evidence you offered, but there it was (or so I thought).
Note: FWIW, I still have my doubts about the HP Slate hitting the market any time soon, if ever, and I also question how good its battery life REALLY will be under the load of Windows and Flash. HP has to realize that if the battery life is only 5 hours and the OS is too "filesystem like", that it will get laughed out of the contest just like earlier tablets have been.
And, note to self: don't be facetious in print. It doesn't come through.
Thompson
No worries man. I figured there was some sort of mixup
AMusingly enough, look what we see this morning regarding the Slate: http://www.dailytech.com/article.aspx?newsid=18269
Show us this proof that using more power doesn't require power. We'll all be waiting right here in reality for you to return.
You can test this yourself so lying isn't going to win any favour. Unplug a laptop, any laptop, then open up Chrome or Safari. Play a YouTube video using HTML5. Check the battery time remaining. Then play that same YouTube video using Flash. Check the battery time remaining. Repeatable, empirical evidence.
Click the links in my signature.
It would be twice as bad with Flash... assuming that your main use case is web surfing.
Thompson
Click the links in my signature.
Mr Gilbert's mind is made up, don't distract him with the facts.
You're buying a lie. Try doing research.
Take them shoes off your teeth and stop runnin your mouth -- Lil Wayne
OK, then maybe you can explain to me how Adobe managed to break the laws of physics.
When I run Safari and stay away from Flash sites or use clicktoflash, my computer never gets hot and CPU usage for Safari is 10-20% max. As soon as I go to a Flash site, the CPU usage shoots over 100% and the bottom of the computer gets very hot.
Now, if the computer is getting hot and the CPU is doing much more work, where is that coming from if not from the battery? I'm really interested in the mechanism they're using to create heat and power CPU cycles that doesn't use the battery.
Physics? Really? Guy, you're grabbing at straws. iPhone wouldn't run Flash Lite, it would run Flash 10-10.1 and those are proven to outperform HTML5 implementations and 10.1 is optimized for mobile use.
And yet, Adobe keeps slipping the go-live date. Repeatedly. As long as it's a prototype, it's a prototype. Call me when we can run some benchmarks on performance and battery life.
The thing is, I doubt anyone from the Android team at Google will have the stones to tell Adobe that performance sucks and it's not ready. So I'm sure it will eventually ship, but I'm unconvinced that it will be worth a sh!t when it does.
10 is GPU optimized. 10.1 is even more so. 10 has a 97.0% adoption rate. HTML5 has a 0% adoption rate. If you want to talk betas, consider that HTML5 is just a draft spec. Don't talk about what you don't know.
Physics? Really? Guy, you're grabbing at straws. iPhone wouldn't run Flash Lite, it would run Flash 10-10.1 and those are proven to outperform HTML5 implementations and 10.1 is optimized for mobile use.
Yes, physics. Get yourself an education and maybe you'll understand it.
It's very simple. My laptop doesn't get hot when I'm not running Flash. As soon as I run Flash, the computer gets very hot and the fans come on. Ergo, Flash is generating much more heat than the non-Flash activities.
Physics says that the heat can't appear from nowhere. There must be energy used somewhere. The only energy source is the battery. Proof positive that Flash has excess battery consumption.
None of your Adobe shill web sites refute that simple fact. In fact, none of them address battery life at all. So please stop with the lies. Until you can find a way to break the laws of physics, you're wrong.
I'm also curious why it is that you can't even read Adobe's specs? Flash 10.0 is completely incapable of running on iPhone-like devices. Flash 10.1 (even if it ever comes out) requires an 800 MHz A8 - which doesn't exist on any current iPhone. So where do you get that the iPhone would run Flash 10.1?
(Not to mention, of course, that early reports are that 10.1 isn't all that good even on a 1 GHz Snapdragon).
You Adobe shills aren't very good at what they're doing.
He's just trolling. Each post filled with more and more lies. He stated that "HTML5 has a 0% adoption rate" when it's the basis of WebOS and in Android and iPhone OS' browser for years now. He also claims that the Cortex-A8 @ 800MHz system that is needed to run Flash 10.1 is more efficient than the ARM11 @ 400MHz system that can stream video just fine. He's obviously invested somehow or paid by Adobe to troll here. I've reported him to the mods.
Click the links in my signature.
The only people who are this rabid about supporting Flash are the deluded script kiddies who only know how to do connect-the-dots "development" and insist on calling themselves "programmers".
I think you underestimate the turmoil this will create but time will tell.
Fair enough, too.
Well, I do believe that it's going to create some turmoil in "developer land", that much is certain. I have no idea how much. I haven't even tried to estimate it, so your statement that I "underestimate" is basically true by default. I guess we'll find out just how many developers and/or SDK creators pitch a fit like that Adobe employee did. That may be our only measure going forward. The two tools that you mentioned (i.e. MonoTouch and Unity) seem to be OK with it... as far as we know at this point. So perhaps it's much ado about nothing.
With regard to the end user in this case, it seems that the "turmoil" is limited since the precedent of control has been set in the early stages. (Of course, other colorful words have been proposed to describe the closed ecosystem, but "turmoil" is not one of the main ones. The other adjectives are best left to another thread!) And likewise this control will minimize "turmoil" to Apple when they need to move the platform forward. Minimizing turmoil to Apple and the end user seems like something that Apple is historically interested in. As for the developer...
What I have been talking about here, and what Steve means too, is something I learned from experience: starting fresh with a useful third-party API to create an application can be very fruitful. Kind of like a marriage in the beginning. And then the honeymoon ends and the maintenance soon begins. (Back talking only about code, lest I piss someone off...) It's the maintenance that becomes a nightmare, and not just for the developer. I'm talking about the end user, the developer, and Apple too (if enough applications used the third-party SDK). When a whole slew of applications either break or get left behind when platform transitions occur, the end user gets mad. And they blame the developer or Apple. The SDK creator gets a free pass, at least in the public eye. The developer can rant and rave all she wants (begging for an updated SDK) but she is at the mercy of the SDK creator. And if she has millions of lines of source built around that SDK, there is lock-in, and there's not much she can do about it but wait, and wait, and wait some more. Meanwhile, the customers are waiting, many of them angry at everyone except the creator of the SDK (whom they know virtually nothing about... nor do they care). It's a bloody nightmare, and if you've never lived it, then I can see why YOU might underestimate or not even appreciate that.
Also, whereas it may seem like I'm talking about something that *might* occur, it's not like that. As a rule, with any application that depends on a third-party SDK, this maintenance issue will happen eventually. That is especially true now that we are in the middle of a technology shift. Who knows what processor the next iPhone will have? Perhaps it will have a different byte-order, and some of these SDKs will break. (This is only an example. There is always something that trips up an SDK if the underlying change is non-trivial.) With XCode, you will only have to flip a switch to compile for the new processor. If you also use something else, you may have to wait a year. Literally. With pissed customers. And if there is another significant change in the meantime... ugh! ... the configuration management becomes very sticky (for everybody, including the end user who doesn't understand why there are so many complicated versions)!
I agree that Apple is interested in maintaining App market space advantage, by forcing developers to choose. But lest you think that is the only, or even the primary, reason, you should know that they made a similar move to control the development tools for Mac OS X when they introduced XCode and froze out Metrowerks. And this was done as an underdog, where it was decidedly NOT in their interest to wall themselves off if all they desired was business dominance. By the way, in case you go there, in order to accomplish this control all they had to do was stop helping Metrowerks and others. (The Mac OS system APIs are far more rich than the iPhone OS at this point in time.) So they didn't have to introduce this language in the developer's agreements. But I figure they would have if it were necessary to accomplish the goal. We all switched over to XCode in fairly short order, and the transition to Intel went much more smoothly than it otherwise would have. (Sure, the emulator helped, but I'm talking about the development of Universal code.)
My conclusion: yes, Apple is interested in maintaining their App Store advantage. But my experience and evidence is enough to convince me that they would have made this move even if it would not have been immediately beneficial to their market share position. (As with Mac OS X in the past.) Two birds with one stone, here.
Thompson
The hardest most costly solution is always better? No pain no gain? Why do you think an app is automatically crappy because it may have been written via compiler?
Well, you put a hell of a lot of words in my mouth right there. I didn't say any of that. Using a third-party API can be very useful at first, and the applications can be great. Then the maintenance starts, and it is always an issue, not just sometimes and not just for Apple or the developer. Please look at my response to backtomac just above.
Then you say some things that are true, and I agree with...
I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler.
Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers — maybe throw in a feature or two and call it an upgrade).
... exactly, and that's where the trouble comes in. What if there is great demand for an updated application, and the developer absolutely wants to sell an update, but the SDK developer in the middle is slow to update the tools that the developer is now reliant upon? Screwed. What if the SDK is finally updated, but in order to maintain continuity across multiple platforms, some of the new capabilities of one particular platform are not exposed to the developer? Then your app starts to become stale and crappy relative to your competition. You might think that these issues give the tool maker sufficient incentive to update their tools, so they can charge the developer again, but that doesn't mean they will be able to do so in a timely fashion. There would essentially be an uncontrollable mechanism smack dab in the middle of the development chain, and in a dynamic environment that is absolutely a serious issue. Show me someone who says otherwise and I'll show you someone that hasn't been there, done that.
Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Well the difference is a matter of scale. The seemingly arbitrary pulling of apps is bound to be maddening to an affected user. In my mind, there is a valid debate that could be had regarding that.
The difference here is that instead of a relatively small fraction of apps going bye-bye (presumably for a reason, which is debatable on a case-by-case basis) we have potential for a significant number of apps going bye-bye for no good reason at all other than the complicated development chain.
Frankly, I think you're letting yourself be suckered into buying Jobs' BS on this one.
It's clear to me that you haven't lived the development nightmare that I've described above. It's also fairly common behavior that if someone hasn't experienced something firsthand, then they tend to question the value of the lessons learned. Add this to a fairly common opinion of Steve Jobs as a manipulative prick, and *POOF* of course you aren't going to believe him. That's your prerogative.
But that doesn't give you the right to assume ANYTHING about me, least of all that I am a sucker. I don't suck up to Steve Jobs. I'm going by my experience, and it just so happens to match his explanation in this case.
I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple.
And I believe that BOTH reasons are true. For my reasoning, see my response to "backtomac" above. In particular, I believe that Apple would have made this same move even if they DIDN'T have the market share advantage right now. They've displayed similar behavior before, when they were the underdogs.
It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I disagree. Given the tectonic shifts that are about to hit, developers and users will be much better off if the development system is streamlined. It looks like there are still going to be useful 3rd party tools out there (backtomac pointed me to MonoTouch).
Thompson
No worries man. I figured there was some sort of mixup
AMusingly enough, look what we see this morning regarding the Slate: http://www.dailytech.com/article.aspx?newsid=18269
I had a hunch that was going to happen after HP bought Palm and provided their reasoning. It just didn't make sense to me that HP would try to march down two different tablet roads at once. And while a HP/Palm tablet has an uphill battle because it will arrive late to the Apple and Google tablet party, success with Windows 7 in the near term is even more unlikely. So that's the one I figured would get punted.
Thompson
Fair enough, too.
...
Thompson
Good post(s).
Ah. I see we've entered the tl;dnr portion of our program.
Probably my fault.
BTW what does tl;dnr mean?
Probably my fault.
BTW what does tl;dnr mean?
Too long; did not read. IIRC