Considering it sports a 1GHz dual core CPU and still can't compete with the single core iPad (not iPad 2), yes it should be a shocker.
It is telling about the Android platform more than anything. The GPU is very important for smooth animations, more so than the CPU. The trouble is that Android doesn't utilize the GPU much, instead almost all UI is software composited on the CPU.
Amazon could get a smooth running device if they dropped Android and started from scratch but would then lose the available app ecosystem.
Yes, there could be a high correlation as you describe or there may not. That's why I think it would be interesting to ferret out the numbers and see if anything interesting can be deduced from them.
Would be interesting what languages the high scoring members answer most of their questions. Wildly interpreting it as what languages the competent programmers are using.
TFA is being charitable when assuming the demographic is children. It's the same demographic playing FarmVille - adults. Adults with too much time and money on their hands. Both of which they are being helpfully relieved.
The subtle point I was slyly making is that the quest to optimize boot time is a distraction from the root causes of the excessive booting. If you need to boot so often because it makes your machine "extra snappy" your OS has a bigger problem that boot time optimization doesn't resolve.
Slicker lube may reduce the pain a bit but you are still being buggered. Though from the tone of your post, you apparently enjoy it.
"Stolen" implies that a bunch of masked bandits from Google raided Apple's Cupertino HQ and pilfered the vault of all the valuable iPhone widgets and touch screens.
No, not masked bandits. They walked in through the front door, invited. I'd bet Jobs was pissed because he believed Google engaged in corporate espionage. Schmidt was on Apple's board and probably saw early incarnations of the iPhone while staying mum about his screaming conflict of interests.
Likewise, Apple & Google collaborated on the iPhone's YouTube and Maps apps which possibly provided Google even more early access to the iPhone.
Google breached Jobs' wall of secrecy and that probably pissed him off more than anything.
Ideally, a modern desktop OS should be booted once. The rest of the time it should be slipping in and out of sleep.
In practice it seems that a few months between reboots (for OS updates) is easily attainable on some platforms. When a reboot occurs once every few months, boot time is not terribly important.
I can't help but think that people who marvel at improved boot times are rebooting their machines too much.
So you've described another form of "stick it in a global" which you admit is still susceptible to the app kill\restart problem. In practice, this is not really a problem because your app can just unwind itself and start afresh and the user will be fine with that.
For reliable persistence you need to continually serialize your data which based on your detailed description you don't do either. I'll wager you don't do it because it is a cumbersome mess and are willing to pay the price of the app ocassionally not coming back in exactly the same state.
Given that you don't do it and apparently most other devs don't do it there is something wrong with the design.
Ironically, android activities were designed to allow this perfect restartability (by forcing the dev. to work like every activity is in a different memory space) and as a result are so ridiculously cumbersome to use. So cumbersome that everyone hacks around them and discards their design goals.
There is nothing wrong with MVC.
There is a huge problem with Android's architecture.
If the quality of your reply is an indication of the general quality of the developers in your office I'm not surprised they don't understand how Android is meant to be developed in. It's too complex for your average drone to figure out.
There is a glimmer of hope for you yet. You have not been completely brain damaged by Android development.
First of all, who cares?
You said it was possible. I pointed out you were wrong.
Second of all, by definition, this can't be true as the xml files are translated into java by the device.
No. Use your terminology correctly. It interprets the XML. It does not translate anything. Its not generating new Java and it is not generating bytecodes. Huge difference.
And here is our glimmer of hope for you. You would expect that proper design would create a situation where "by definition" anything expressed in XML would be an expression of an underlying Java interface. But it is not designed correctly. The XML interpreter does not use the public APIs available to the developer. It does its own thing and so you end up with two code paths for the same thing- bad design.
Don't believe me? Go look at the code.
No shit, Shirlock. Android running on the phone translates them into the relevant Java code.
Nope it doesn't. For someone who doesn't understand the basic difference between an interpreter and a code generator calling me clueless is a bit rich.
Er, if you don't want to use XML files to do your UI, you don't have to. You can use pure Java all day long.
Umm. No you can't. There are many widget aspects that are only configurable through XML. There is no Java API for them.
Besides, the XML files are exploded into Java on the device anyway.
Nope the XML files get bundled in your apk as is. Android might interpret them later in java but so what? It's gotta do it somehow.
You use the XML to quickly design the static elements of your UI and use Java code to do the interactive stuff. What is there to bitch about?
Oh, I don't know. That your UI code is now spread across some a few unverifiable XML files and Java instead of being in one place where it would be easy to maintain.
You are not silly. You are just in denial. Google can't produce the same high quality apps on Android like it does on iOS. You also fail to appreciate the massive vendor interest and effort in creating Android apps.
Read the FAQ question and answer. Intents are not for "complex objects". The official answer is stick your non-trivial object in a global hash map and pass the key in the intent. Epic fail. Truly epic when you keep in mind that the app could get blown away in the interim and the intent used to restart the activity with a key that is no longer meaningful. No, the one true way according to Google is to write hundreds of lines of code to marshal and unmarshal data between intents, SQLite and content providers. Amazingly, nobody does that. Nobody does it because it is an unmaintainable mess.
Activities and intents are an over engineered mistake. They sacrifice everything (developer ease of use, functionality, performance, flexibility, maintainability, etc.) for the vague notion of being "restartable" and invocable across apps which in the end contribute nothing to your app.
The beauty of these things is that you just never know. Sometimes, just the knowledge gained from attempting these exercises has unexpected benefits. Just because it may not have an immediate benefit does not mean it will never have a benefit. It's his time and effort and he wants to do it. Good for him.
Scrolling the screen pops new content up from "within" the device. That makes absolutely no sense. It's eye candy that detracts from usability. Not to be a fanboi, but the various animations in iOS serve to provide visual cues to the user on what is happening and how to use the UI. Apple is very up front in their UI guidelines about how animations should serve to inform the user on what is happening. This Android animation completely fails at that.
Yet you'd expect a HW company to have a use for vetted HW engineers. One of the hardest elements of building a productive SW or HW team is the hiring. HP is taking a built organization and blowing it when they could probably put all these engineers to work elsewhere in the company.
Part of the reason Facebook and Google can "self heal" is because failures are mostly not noticeable by end users. If a Facebook or Google machine fails, unless you are getting a 404 or a service failure message there is little to no way for you to know that the web page you have been served up is wrong, partial or out of date. This failure ambiguity provides a lot of leeway on the methods and speed required to fix a failure.
For most other services where there is a definite correct and incorrect output - like file systems or financial services - a broken service has immediate impact and fixing it is much harder.
So you admit it didn't backup your SMS but then conclude that it didn't fail the test? Amazing self deception.
You also neglect to take into account any non-Google service data that is sitting on your phone either in internal memory or on the SD card. All your non-Google data gets blown away too and it is either lost or you'll have to reconfigure apps on the new phone.
No, not really. The simple test that Android fails miserably is this: Backup your phone with a single click, smash it with a hammer and restore your backup to a new phone with another click. With iOS the HW is completely interchangeable and your configuration comes out unscathed with zero effort on your part. With Android? With Android you'll fiddle for a few days as you piece your phone back together from your partial backup and tweaking the remaining items to where you think you remember it was.
Slashdot Mirror
Considering it sports a 1GHz dual core CPU and still can't compete with the single core iPad (not iPad 2), yes it should be a shocker.
It is telling about the Android platform more than anything. The GPU is very important for smooth animations, more so than the CPU. The trouble is that Android doesn't utilize the GPU much, instead almost all UI is software composited on the CPU.
Amazon could get a smooth running device if they dropped Android and started from scratch but would then lose the available app ecosystem.
Yes, there could be a high correlation as you describe or there may not. That's why I think it would be interesting to ferret out the numbers and see if anything interesting can be deduced from them.
Would be interesting what languages the high scoring members answer most of their questions. Wildly interpreting it as what languages the competent programmers are using.
TFA does.
TFA is being charitable when assuming the demographic is children. It's the same demographic playing FarmVille - adults. Adults with too much time and money on their hands. Both of which they are being helpfully relieved.
You read angry.
The subtle point I was slyly making is that the quest to optimize boot time is a distraction from the root causes of the excessive booting. If you need to boot so often because it makes your machine "extra snappy" your OS has a bigger problem that boot time optimization doesn't resolve.
Slicker lube may reduce the pain a bit but you are still being buggered. Though from the tone of your post, you apparently enjoy it.
Somehow, given that you have a UPS, you don't sound like a typical user.
Even when multiplied by millions the final impact is negligible. The amount of CO2 produced per unit of time is about 1/40th the amount you exhale.
"Stolen" implies that a bunch of masked bandits from Google raided Apple's Cupertino HQ and pilfered the vault of all the valuable iPhone widgets and touch screens.
No, not masked bandits. They walked in through the front door, invited. I'd bet Jobs was pissed because he believed Google engaged in corporate espionage. Schmidt was on Apple's board and probably saw early incarnations of the iPhone while staying mum about his screaming conflict of interests.
Likewise, Apple & Google collaborated on the iPhone's YouTube and Maps apps which possibly provided Google even more early access to the iPhone.
Google breached Jobs' wall of secrecy and that probably pissed him off more than anything.
A decent PC will use about 2 watts in sleep mode. You'll be lucky if you save enough in a year for a single pint of beer.
Ideally, a modern desktop OS should be booted once. The rest of the time it should be slipping in and out of sleep.
In practice it seems that a few months between reboots (for OS updates) is easily attainable on some platforms.
When a reboot occurs once every few months, boot time is not terribly important.
I can't help but think that people who marvel at improved boot times are rebooting their machines too much.
All relevant to computer scientists and nobody else.
So you've described another form of "stick it in a global" which you admit is still susceptible to the app kill\restart problem. In practice, this is not really a problem because your app can just unwind itself and start afresh and the user will be fine with that.
For reliable persistence you need to continually serialize your data which based on your detailed description you don't do either. I'll wager you don't do it because it is a cumbersome mess and are willing to pay the price of the app ocassionally not coming back in exactly the same state.
Given that you don't do it and apparently most other devs don't do it there is something wrong with the design.
Ironically, android activities were designed to allow this perfect restartability (by forcing the dev. to work like every activity is in a different memory space) and as a result are so ridiculously cumbersome to use. So cumbersome that everyone hacks around them and discards their design goals.
There is nothing wrong with MVC.
There is a huge problem with Android's architecture.
If the quality of your reply is an indication of the general quality of the developers in your office I'm not surprised they don't understand how Android is meant to be developed in. It's too complex for your average drone to figure out.
There is a glimmer of hope for you yet. You have not been completely brain damaged by Android development.
First of all, who cares?
You said it was possible. I pointed out you were wrong.
Second of all, by definition, this can't be true as the xml files are translated into java by the device.
No. Use your terminology correctly. It interprets the XML. It does not translate anything. Its not generating new Java and it is not generating bytecodes. Huge difference.
And here is our glimmer of hope for you. You would expect that proper design would create a situation where "by definition" anything expressed in XML would be an expression of an underlying Java interface.
But it is not designed correctly. The XML interpreter does not use the public APIs available to the developer. It does its own thing and so you end up with two code paths for the same thing- bad design.
Don't believe me? Go look at the code.
No shit, Shirlock. Android running on the phone translates them into the relevant Java code.
Nope it doesn't. For someone who doesn't understand the basic difference between an interpreter and a code generator calling me clueless is a bit rich.
Er, if you don't want to use XML files to do your UI, you don't have to. You can use pure Java all day long.
Umm. No you can't. There are many widget aspects that are only configurable through XML. There is no Java API for them.
Besides, the XML files are exploded into Java on the device anyway.
Nope the XML files get bundled in your apk as is. Android might interpret them later in java but so what? It's gotta do it somehow.
You use the XML to quickly design the static elements of your UI and use Java code to do the interactive stuff. What is there to bitch about?
Oh, I don't know. That your UI code is now spread across some a few unverifiable XML files and Java instead of being in one place where it would be easy to maintain.
You are not silly. You are just in denial. Google can't produce the same high quality apps on Android like it does on iOS. You also fail to appreciate the massive vendor interest and effort in creating Android apps.
Read the FAQ question and answer. Intents are not for "complex objects". The official answer is stick your non-trivial object in a global hash map and pass the key in the intent. Epic fail. Truly epic when you keep in mind that the app could get blown away in the interim and the intent used to restart the activity with a key that is no longer meaningful.
No, the one true way according to Google is to write hundreds of lines of code to marshal and unmarshal data between intents, SQLite and content providers. Amazingly, nobody does that. Nobody does it because it is an unmaintainable mess.
Activities and intents are an over engineered mistake. They sacrifice everything (developer ease of use, functionality, performance, flexibility, maintainability, etc.) for the vague notion of being "restartable" and invocable across apps which in the end contribute nothing to your app.
The beauty of these things is that you just never know. Sometimes, just the knowledge gained from attempting these exercises has unexpected benefits.
Just because it may not have an immediate benefit does not mean it will never have a benefit. It's his time and effort and he wants to do it. Good for him.
Scrolling the screen pops new content up from "within" the device. That makes absolutely no sense. It's eye candy that detracts from usability.
Not to be a fanboi, but the various animations in iOS serve to provide visual cues to the user on what is happening and how to use the UI. Apple is very up front in their UI guidelines about how animations should serve to inform the user on what is happening. This Android animation completely fails at that.
The guy started his career writing in VBA and moved to OCaml via Java. Is it any wonder he finds OCaml so great?
Yet you'd expect a HW company to have a use for vetted HW engineers. One of the hardest elements of building a productive SW or HW team is the hiring. HP is taking a built organization and blowing it when they could probably put all these engineers to work elsewhere in the company.
Part of the reason Facebook and Google can "self heal" is because failures are mostly not noticeable by end users. If a Facebook or Google machine fails, unless you are getting a 404 or a service failure message there is little to no way for you to know that the web page you have been served up is wrong, partial or out of date. This failure ambiguity provides a lot of leeway on the methods and speed required to fix a failure.
For most other services where there is a definite correct and incorrect output - like file systems or financial services - a broken service has immediate impact and fixing it is much harder.
And yet she was CAUGHT. Profiling does work.
So you admit it didn't backup your SMS but then conclude that it didn't fail the test? Amazing self deception.
You also neglect to take into account any non-Google service data that is sitting on your phone either in internal memory or on the SD card. All your non-Google data gets blown away too and it is either lost or you'll have to reconfigure apps on the new phone.
No, not really. The simple test that Android fails miserably is this: Backup your phone with a single click, smash it with a hammer and restore your backup to a new phone with another click.
With iOS the HW is completely interchangeable and your configuration comes out unscathed with zero effort on your part.
With Android? With Android you'll fiddle for a few days as you piece your phone back together from your partial backup and tweaking the remaining items to where you think you remember it was.