No, thy are saying that with worse network the gap will be greater.
Not due to differences in "browsers", simply due to network issues. That whole point they tried to make was completely stupid. And, the gap will only be wider under controlled conditions. In the wild, which is what they are talking about, where you can't control conditions, the gap could become smaller or reverse. They're idiots.
Am I wrong in seeing a double standard here? Granted, it is Apple's devices, and they can do what they want, but still...
Of course there is a double-standard. That's the advantage of being the builder of the device and the OS. You get to install your apps on the shipping device. You get access to private APIs for your applications that nobody else is allowed to use. It's not right or wrong, it just "is". It's Apple's embeded browser API they are using. They could always build their own browser right into the application. They used the one Apple provided, and regardless of the reasons, Apple decided to not provide that browser the same enhancments Safari got.
Quote:
Originally Posted by TenoBell
The title of the test is about whose browser is faster. They assumed that the embedded browser and native browser were exactly the same. Security concerns are the reason Apple has not opened Nitro to its embedded browser. They would need to sandbox the process so that it becomes a trusted chain of executable code.
Quote:
Originally Posted by anonymouse
It's totally fair. They claimed they were testing browser against browser but didn't test any browsers. They deserve every bit of criticism they get, but mostly since they were deceptive about it.
But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
Now that they know, should they try to repleat the test using Safari? Sure. But as even AI stated, that could be very difficult to execute.
lol this is an easy argument to solve and its why we continue to see these trumpeted stories of superiority from android supporters.
Solution:
An android user and, iphone user walk into a room of 20 people round a large table. Sit, take out your device and place it on the table... now flip it over so the back is showing. As i've tested this, 13 out of 20 ask if thats the iPhone and how do you like it? Out of the remaining 7; 5 Already own an iPhone, . 1 owns a blackberry (haha) and the lone Android user comes to the realization that he doesn't have the cool device.
... But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
For one thing, their headline is completely dishonest. Secondly, they made a bunch of assumptions that were stupid to make, so that's no defense for their dishonest lead.
They hadn't claimed that they measured Safari and Chrome, they claimed that they measured iOS and Android browsers
"The measurement itself was done using the custom apps, which use the platform?s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone. Manual verification showed that page load performance of the embedded browsers, when properly configured, is effectively identical to the stand-alone browsers. The load times are calculated using the ?Document Complete? callback from the browser, which is a standard way of measuring a web page?s load time. As mentioned above, the agents are now a part of a free service available at http://blaze.io/mobile/, and we encourage you to try it out."
And yes, they used the browsers and until iOS 4.3 the performance of embedded browser and Safari browser was the same as it is with android embedded and Chrome browsers.
However, how so? Please explain. If you explain it well enough, I'll change my opinion.
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
Normally I find AI's writting exemplary, but the biased tone in the first half of this posting is really bothersome.
Suggesting that this is solely Blaze's fault that Apple's new JS engine wasn't used is unfair. Apple should have made the engine available to Apps and WebApps... I'd even argue Blaze was right to assume they had, although I'd expect Blaze to issue a clarification upon learning that WebApp and Apps using the web framework don't get to utilize the new JS engine that their tests are only valid for comparing apps to other apps, not browser to browser...
I disagree. Blaze did not make it clear enough that they weren't using the browser directly which means people using their iPhone are not experiencing the same thing.
It is up to the people doing the test to make sure their equipment is correctly calibrated to give an objective result which obviously was not the case here.
Based on their defective test there is nothing anyone can deduce except that their app is not able to max out on iOS.
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
And what is the difference of running Facebook JS code in Safari and in UIwebview? Or any other web app, for that matter?
If it's insecure on uiwebview it's also insecure on Safari
iPhone vs. Android ? 45,000 Tests Prove Whose Browser is Faster
iPhone's browser is Safari, and that's what people are going to assume the title is talking about, not some "embedded browser". At the very least, the headline is imprecise and misleading.
They used the embedded browsers in both platforms.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
That is what happens when you make an assumption without doing your due diligence to check. The onus is on the tester to make sure they understand all of the variables of their test. Before they release the results as fact.
Quote:
Originally Posted by Wiggin
But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
For one thing, their headline is completely dishonest. Secondly, they made a bunch of assumptions that were stupid to make, so that's no defense for their dishonest lead.
"Dishonest" and "deceptive" means that they knew and were intentionally misleading in their report. Everytime anyone says anything non-positive, and even sometimes when they say something positive but use a word like "overkill", you instantly assume that they are out to get Apple, that they are Apple haters and have a chip on their shoulder. It's a very paranoid world you live in.
Did they make a mistake? Yes. Did they admit that their test didn't test Safari? Yes. And they were open about it by putting the disclaimer on their orignal story. Let's see AI be as forthcoming about the deceptive writing by DED (deceptive or delusional, take your pick). As of the time I'm writing this, DED still has not acknowledged that Blaze discovered the error in their testing and has added a disclaimer on their story. And he probably never will. He doesn't even included a link to Blaze's orignial article. Why? Oh right, because then people would also see the disclaimer.
So just who is being deceptive and dishonest here?
They used the embedded browsers in both platforms.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
No, if you want to compare embedded apps against each other, that's fine. Perhaps even of interest.
But they are clearly (let's all say the word together) LYING when they say that their study analyzes BROWSER speed. That would be Safari against whatever browser is built into Android.
They used the embedded browsers in both platforms.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
You do realize this "real world of computer performance testing" is different than the "real world," right?
Statistics and the benchmarks generated by performance testing are meaningless without correct analysis and interpretation.
As stated, the article said "iPhone v. Android: 45000 tests prove which browser is faster."
Not which "embedded" browser is faster. And they certainly didn't put it in real world terms, eg, this affects third party browsers, not the safari browser (which is the browser used by the vast majority of users).
Their poor interpretation and presentation did a disservice to the real and useful statistics that they produced.
That is what happens when you make an assumption without doing your due diligence to check. The onus is on the tester to make sure they understand all of the variables of their test. Before they release the results as fact.
True, but with a company like Apple, that's a pretty hard thing to verify. It wasn't until people started noticing the poor performance that Apple finally came out and said what was going on. So until people started doing tests and confronted Apple with the results, how would anyone know? And they likely started their testing, possibly even concluded their testing, and were writing up their report by the time Apple revealed the differences between Safari and the embedded browser API.
Short of reverse engineering the OS, is there any reasonable why they could have known prior to Apple's statements?
Comments
No, thy are saying that with worse network the gap will be greater.
Not due to differences in "browsers", simply due to network issues. That whole point they tried to make was completely stupid. And, the gap will only be wider under controlled conditions. In the wild, which is what they are talking about, where you can't control conditions, the gap could become smaller or reverse. They're idiots.
Am I wrong in seeing a double standard here? Granted, it is Apple's devices, and they can do what they want, but still...
Of course there is a double-standard. That's the advantage of being the builder of the device and the OS. You get to install your apps on the shipping device. You get access to private APIs for your applications that nobody else is allowed to use. It's not right or wrong, it just "is". It's Apple's embeded browser API they are using. They could always build their own browser right into the application. They used the one Apple provided, and regardless of the reasons, Apple decided to not provide that browser the same enhancments Safari got.
The title of the test is about whose browser is faster. They assumed that the embedded browser and native browser were exactly the same. Security concerns are the reason Apple has not opened Nitro to its embedded browser. They would need to sandbox the process so that it becomes a trusted chain of executable code.
It's totally fair. They claimed they were testing browser against browser but didn't test any browsers. They deserve every bit of criticism they get, but mostly since they were deceptive about it.
But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
Now that they know, should they try to repleat the test using Safari? Sure. But as even AI stated, that could be very difficult to execute.
No, they didn't claim that, in their report there is the metodology and how they made the tests.
And despite the metodology, the tests are stupid, it's irelevant that a page load a second faster or slower
This is their headline:
iPhone vs. Android ? 45,000 Tests Prove Whose Browser is Faster
What part of that didn't they claim?
Solution:
An android user and, iphone user walk into a room of 20 people round a large table. Sit, take out your device and place it on the table... now flip it over so the back is showing. As i've tested this, 13 out of 20 ask if thats the iPhone and how do you like it? Out of the remaining 7; 5 Already own an iPhone, . 1 owns a blackberry (haha) and the lone Android user comes to the realization that he doesn't have the cool device.
... But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
For one thing, their headline is completely dishonest. Secondly, they made a bunch of assumptions that were stupid to make, so that's no defense for their dishonest lead.
This is their headline:
What part of that didn't they claim?
They hadn't claimed that they measured Safari and Chrome, they claimed that they measured iOS and Android browsers
"The measurement itself was done using the custom apps, which use the platform?s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone. Manual verification showed that page load performance of the embedded browsers, when properly configured, is effectively identical to the stand-alone browsers. The load times are calculated using the ?Document Complete? callback from the browser, which is a standard way of measuring a web page?s load time. As mentioned above, the agents are now a part of a free service available at http://blaze.io/mobile/, and we encourage you to try it out."
And yes, they used the browsers and until iOS 4.3 the performance of embedded browser and Safari browser was the same as it is with android embedded and Chrome browsers.
I enjoy the short and sweet.
However, how so? Please explain. If you explain it well enough, I'll change my opinion.
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
Normally I find AI's writting exemplary, but the biased tone in the first half of this posting is really bothersome.
Suggesting that this is solely Blaze's fault that Apple's new JS engine wasn't used is unfair. Apple should have made the engine available to Apps and WebApps... I'd even argue Blaze was right to assume they had, although I'd expect Blaze to issue a clarification upon learning that WebApp and Apps using the web framework don't get to utilize the new JS engine that their tests are only valid for comparing apps to other apps, not browser to browser...
..and no link to the source, bad AI... bad....
For those that actually care about facts: http://www.blaze.io/uncategorized/mo...ser-is-faster/
I disagree. Blaze did not make it clear enough that they weren't using the browser directly which means people using their iPhone are not experiencing the same thing.
It is up to the people doing the test to make sure their equipment is correctly calibrated to give an objective result which obviously was not the case here.
Based on their defective test there is nothing anyone can deduce except that their app is not able to max out on iOS.
They hadn't claimed that they measured Safari and Chrome, they claimed that they measured iOS and Android browsers ...
Take your sophistry elsewhere. Safari and Chrome are the iOS and Android browsers.
(I mean, really, that was just the most pathetic defense of the indefensible I've ever seen on these forums.)
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
Gotcha, thanks!
There's no double standard at all. Apple only allows code it has direct control over to run interpreted/downloaded code. It's well known that this is done for security reasons; allowing all apps to run interpreted or other downloaded code makes it impossible to screen them for malicious intent. So, it's not a double standard, it's the only way that they can provide any level of security, and it's a single well understood standard based on well understood reasons.
And what is the difference of running Facebook JS code in Safari and in UIwebview? Or any other web app, for that matter?
If it's insecure on uiwebview it's also insecure on Safari
No, they didn't claim that
They sure did, right in the headline.
iPhone vs. Android ? 45,000 Tests Prove Whose Browser is Faster
iPhone's browser is Safari, and that's what people are going to assume the title is talking about, not some "embedded browser". At the very least, the headline is imprecise and misleading.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
But until the story was reported after 4.3 was released, how many people had the reasonable expectation that the embedded browser used the same engine as Safari? That's the way it's been since the beginning of Safari on both the Mac and iOS, right? Other applications used the same WebKit code that Safari used. Apple didn't tell anyone that in iOS 4.3 it was any different. So how was Blaze supposed to know? They've even put a disclaimer at the very top of their original story. So please, explain to me where the "deception" is.
Take your sophistry elsewhere. Safari and Chrome are the iOS and Android browsers.
(I mean, really, that was just the most pathetic defense of the indefensible I've ever seen on these forums.)
Sophistry and pathetic? Which was the difference 2 weeks ago between Safari and uiwebview?
Talk about an organization trying to establish itself as a reliable source of testing, Blaze has sure shot itself in the foot.
They're particularly getting hammered in their own comments section under the article for a clearly flawed and misleading 'study'.
For more...
http://daringfireball.net/2011/03/nitro_ios_43
For one thing, their headline is completely dishonest. Secondly, they made a bunch of assumptions that were stupid to make, so that's no defense for their dishonest lead.
"Dishonest" and "deceptive" means that they knew and were intentionally misleading in their report. Everytime anyone says anything non-positive, and even sometimes when they say something positive but use a word like "overkill", you instantly assume that they are out to get Apple, that they are Apple haters and have a chip on their shoulder. It's a very paranoid world you live in.
Did they make a mistake? Yes. Did they admit that their test didn't test Safari? Yes. And they were open about it by putting the disclaimer on their orignal story. Let's see AI be as forthcoming about the deceptive writing by DED (deceptive or delusional, take your pick). As of the time I'm writing this, DED still has not acknowledged that Blaze discovered the error in their testing and has added a disclaimer on their story. And he probably never will. He doesn't even included a link to Blaze's orignial article. Why? Oh right, because then people would also see the disclaimer.
So just who is being deceptive and dishonest here?
They used the embedded browsers in both platforms.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
No, if you want to compare embedded apps against each other, that's fine. Perhaps even of interest.
But they are clearly (let's all say the word together) LYING when they say that their study analyzes BROWSER speed. That would be Safari against whatever browser is built into Android.
Words have meaning.
They used the embedded browsers in both platforms.
Blaze's conclusion was that the embedded browser in Android was faster than the embedded browser in iOS. That conclusion holds up to scrutiny.
Perhaps it escapes AppleInsider, but in the real world of computer performance testing, a fair set of benchmarks compares platforms as equally across the table as possible. It might make AI happy to see a set of unequal comparisons, but that would hardly be considered fair outside the confines of fanboidom.
You do realize this "real world of computer performance testing" is different than the "real world," right?
Statistics and the benchmarks generated by performance testing are meaningless without correct analysis and interpretation.
As stated, the article said "iPhone v. Android: 45000 tests prove which browser is faster."
Not which "embedded" browser is faster. And they certainly didn't put it in real world terms, eg, this affects third party browsers, not the safari browser (which is the browser used by the vast majority of users).
Their poor interpretation and presentation did a disservice to the real and useful statistics that they produced.
That is what happens when you make an assumption without doing your due diligence to check. The onus is on the tester to make sure they understand all of the variables of their test. Before they release the results as fact.
True, but with a company like Apple, that's a pretty hard thing to verify. It wasn't until people started noticing the poor performance that Apple finally came out and said what was going on. So until people started doing tests and confronted Apple with the results, how would anyone know? And they likely started their testing, possibly even concluded their testing, and were writing up their report by the time Apple revealed the differences between Safari and the embedded browser API.
Short of reverse engineering the OS, is there any reasonable why they could have known prior to Apple's statements?