The integrated approach to computers/phones/tablets have always been the best. But it have not been successful longtime because that people like diversity.
The integrated approach is Apple's main strength. IMO, it is catching on very well lately because it is so well developed lately. The iColud initiative is currently the ultimate in Apple interoperability.
It is a double edged sword for a consumer, however. They must trade convenience for lock-in. But since about 1945 or so, convenience has won every time.
In most cases, it's your complete disrespect for anyone who chooses to use products that you yourself don't choose to use (namely Android products) that shows ignorance. It's not necessarily ignorance of the product, though I don't think you've extensively used the products you so frequently malign, but rather your ignorance of the basics of human nature. It's ignorance of the fact that different people have different needs. It's ignorance of the fact that different people value different things. And most of all it's ignorance of the fact that your unprovoked malice makes you a less credible individual.
As far as ignorance of the product goes, you demonstrated that in the portion of your post that I quoted the first time. Here you claim that Android devices respond "seconds after you press something." Ignorance. "...realtime music apps is something else that doesn't exist on Android, because of the terrible latency." Ignorance.
Just so you know, I think it is perfectly reasonable that someone could claim to have experienced a device exhibiting a consistent, seconds-long delay at some point, but the possibility for that having happened doesn't even remotely imply that it has happened, nor does it mean that one isolated case would be representative of the platform as a whole. Your unbridled hatred of all Android users and Android devices tells me that you likely have no evidence of such a device or such an experience, having merely created a scenario to project your own feelings on the world.
Sometimes it's difficult to tread around here even with a neutral stance. The reality distortion field is strong with some -- just keep this in mind at all times.
I'm very interested in what sort of a solution Google can come up with that allows operations to continue in the background while improving the stuttering that can occur, rather than simply wacking all operations for the input thread.
Multi-core processors? Isn't that a good reason to use them?
From a business standpoint Apple is off-and-on the biggest company in the world, and they took the time to do it right the first time.
Yeah it is not like modern (resistive or capacitive) touchscreen technology but the intended use is the same albeit issues with dirty sensors and poor resolution. My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.
Multi-core processors? Isn't that a good reason to use them?
Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.
But yeah, that'd be one solution. I'm curious what they'll opt with.
I think that Googles own "motorola" phones will be the ones that gets all these feautures. Here Google can choose the best SoC (something with PowerVR6) and really spank Apple.
...
Android phones do not need more processor and GPU power, they have plenty. (Though tablets will probably need as much as they can get for the time being.) It's all about fixing the software.
Quote:
Will they lock up Android more? Maybe do the MSTF way where anybody can manufacture the hardware, but MSFT tells them what hardware they have to use + have a locked App store.
There's no reason to. Android phones' problems aren't with the hardware. Immaturity of the OS explains a lot, manufacturer- and operator-specific tinkering explains the rest. If anything, Google should aggressively test phones to ensure they adhere to the Android API. For example, call recorder apps apparently work on few phones because many manufacturers do not correctly hand the call soundstream to an app as required by the API; this is exactly the kind of problem Google could easily force the manufacturers to fix.
In the long run, the biggest move I'd like to see from Google is streamlining the update pipeline and eventually cutting operators and HW manufacturers out of it. No reason why HTC, Samsung etc couldn't still offer their own tuned Android, but the user should at any time have an option to go completely vanilla. So for instance: you have a HTC with Sense UI. Android 5.0 hits. You choose to update directly to it from Google. HTC, your operator etc. have no way of preventing this. Three months later HTC has prepared their own 5.0 distribution, and you choose to update to that. This would result in the userbase staying roughly up to date, allay the fears of not getting more updates, and set a very concrete standard of quality for the manufacturers: unless the custom OS beats stock OS, the user bails.
It would be a retarded move for Google to prevent app sideloading. User freedom is the single biggest thing Android offers compared to iOS and Windows Phone.
Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.
But yeah, that'd be one solution. I'm curious what they'll opt with.
So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?
Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?
Or the lag on an iPhone 4 running iOS5. My iP4 is stupidly laggy since the update, it's almost like going back to my old iPhone 3G.
Once you kill the background apps, mainly games, your phone lags is gone. I had the same issue with my 3gs iOS5, now my 3GS is running great by deleting background apps.
So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?
Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?
Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.
Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.
I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.
That's just ridiculous. Apple only 'invented' the iOS touchscreen UI. Touchscreens had been around (with UIs underneath them) since the 80's. The HP-150 is likely one of the first personal computers incorporating a touchscreen interface.
Also, despite what many people would like to think, if Google is so desperately trying to steal the iOS UI than why is it so "crappy and laggy"? The UI philosophy is so drastically different it's difficult to understand why people still try to preach that Google has stolen anything at all. Android UI is flexible, customizable and dynamic (themes, widgets, custom launchers, etc). iOS UI is completely rigid and static (no themes, no widgets, one size fits all). The performance problems in Android are in some part related to this fact, as the overhead created in the Android environment is significant.
Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?
Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?
Technically microsoft made a windows for pen computing back in 1991. Tablet pc in 2002 was thrown together.
Microsoft suffers from the has to be everything for everybody problem .Since apple controls the hardware they can do what they want.
And that is one of the main reasons why every Android device has sucked so far. Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.
On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.
There's also another big thing that Android can not do well, it doesn't handle audio properly, and realtime music apps is something else that doesn't exist on Android, because of the terrible latency.
That is fascinating. I have experienced the same problems with my iPod Touch. The OS will lag swiping between app pages, presses don't register, the OS will just hang for no apparent reason.
As for the audio, still prefer the Zune HD audio. Its just a better sound. I don't even bother playing music on the Touch.
First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.
The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.
If software was designed to run on a blackberry type device and then they had to slap on a touch GUI at the last minute after seeing what Apple was putting out, it doesn't take a rocket scientists to see why this would result in unoptimized graphics.
iOS was designed from the ground up for touch. Andrioid was designed by keyboard/trackball and had a touch GUI slapped on top of it.
"The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get ?lost? in an iPad, but I cringe when a Xoom stutters between home screens," he said.
The jig is up. They've figured out the secret magic ingredient of iOS. I don't think Google doesn't care. The challenge for them will be the fact that they don't own the entire technology "stack": from chips to UI. I don't think that will change. Same case with Microsoft when it comes to Windows. Windows 7 has an "experience rating" which is a number that's supposed to quantify how well your hardware is supposed to work desktop applications. That number varies. With iOS or Mac OS X, the OS is developed more closely with the hardware in mind. The result is that the OS does not fail to utilize the underlying hardware to its full potential.
Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.
Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.
I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.
Good stuff. Thanks.
WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?
Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.
Odd that when Microsoft dominated user experience, nobody was particularly sensitive about "smooth animation" and responsive UIs.
Not exactly true. One thing that Microsoft were always good at (eg XP and earlier) was a responsive UI. The processor may not have been fast, but the UI always was, and it was always very difficult explaining to people that a Mac running System 8/9 was actually faster, when the UI did drag. And badly.
So for instance, you could press on an icon and the Windows machine would be much quicker, however, when it came to rendering something in Photoshop, the Mac would blow the Windows machine away.
It was only when MS allowed woefully inadequate memory on Vista machines did they screw that responsiveness up, and we all know that that allowed the Mac back in.
My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.
But who is saying Apple invented touch screen user interfaces "in general"? I think you are misreading people who are crediting Apple for implementing and popularizing one of the best touch screen user interfaces yet applied to mobile computing devices. It does contain a number of original (and patentable) ideas. But touch screens have been around in GPS nav systems and automated teller machines for years.
WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?
Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.
Yep, you're right. That's the catch.
You can make the UI smooth as glass if you dedicate all of your hardware to the UI first and foremost, which is what iOS does. Android takes a different approach and says, "Let's try to keep this as responsive as possible, but also perform work in the background so other things keep happening."
Both are interesting solutions. Android (generally) has more going on in the background, and can "keep working" while input is being handled--and as hardware improves, that only gets better. The problem is that this system is still subject to periodic stutters, even if minor, which are visually annoying.
For example, on my Evo 4G, the phone performs great. However, when I'm scrolling through a massive post on Google+, it will "stutter" every few seconds, as the UI thread is shared with the background processes. That stutter breaks the "immersion" that iOS users have.
It's an interesting problem, because if Android operated like iOS, then regardless of hardware available, everything else stops for the UI. 5x 4.0Ghz quad-core CPUs and 32 GB of RAM would all stop for the UI in iOS; Android would try to leverage everything as best it could, but at the sacrifice of ultimate smoothness and immersion.
I'm mixed on how I feel.. which is why I'm interested in what Google comes up with. Android J____ is going to be interesting.
But who is saying Apple invented touch screen user interfaces "in general"?
The poster I quoted earlier "Apple invented the touchscreen UI, Google is just trying to steal it" Also, there are plenty of Apple evangelists out there (particularly those defending all these ridiculous IP cases) who claim Apple invented all of the i-device technology that has become overwhelmingly popular in the past 4-5 years. Don't get me wrong, Apple has definitely made strides in applying the tech that is available.
Comments
...
+1.
Educated discussions are much better than blinded passion.
The integrated approach to computers/phones/tablets have always been the best. But it have not been successful longtime because that people like diversity.
The integrated approach is Apple's main strength. IMO, it is catching on very well lately because it is so well developed lately. The iColud initiative is currently the ultimate in Apple interoperability.
It is a double edged sword for a consumer, however. They must trade convenience for lock-in. But since about 1945 or so, convenience has won every time.
In most cases, it's your complete disrespect for anyone who chooses to use products that you yourself don't choose to use (namely Android products) that shows ignorance. It's not necessarily ignorance of the product, though I don't think you've extensively used the products you so frequently malign, but rather your ignorance of the basics of human nature. It's ignorance of the fact that different people have different needs. It's ignorance of the fact that different people value different things. And most of all it's ignorance of the fact that your unprovoked malice makes you a less credible individual.
As far as ignorance of the product goes, you demonstrated that in the portion of your post that I quoted the first time. Here you claim that Android devices respond "seconds after you press something." Ignorance. "...realtime music apps is something else that doesn't exist on Android, because of the terrible latency." Ignorance.
Just so you know, I think it is perfectly reasonable that someone could claim to have experienced a device exhibiting a consistent, seconds-long delay at some point, but the possibility for that having happened doesn't even remotely imply that it has happened, nor does it mean that one isolated case would be representative of the platform as a whole. Your unbridled hatred of all Android users and Android devices tells me that you likely have no evidence of such a device or such an experience, having merely created a scenario to project your own feelings on the world.
Sometimes it's difficult to tread around here even with a neutral stance. The reality distortion field is strong with some -- just keep this in mind at all times.
I'm very interested in what sort of a solution Google can come up with that allows operations to continue in the background while improving the stuttering that can occur, rather than simply wacking all operations for the input thread.
Multi-core processors? Isn't that a good reason to use them?
From a business standpoint Apple is off-and-on the biggest company in the world, and they took the time to do it right the first time.
Yeah it is not like modern (resistive or capacitive) touchscreen technology but the intended use is the same albeit issues with dirty sensors and poor resolution. My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.
Multi-core processors? Isn't that a good reason to use them?
Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.
But yeah, that'd be one solution.
I think that Googles own "motorola" phones will be the ones that gets all these feautures. Here Google can choose the best SoC (something with PowerVR6) and really spank Apple.
...
Android phones do not need more processor and GPU power, they have plenty. (Though tablets will probably need as much as they can get for the time being.) It's all about fixing the software.
Will they lock up Android more? Maybe do the MSTF way where anybody can manufacture the hardware, but MSFT tells them what hardware they have to use + have a locked App store.
There's no reason to. Android phones' problems aren't with the hardware. Immaturity of the OS explains a lot, manufacturer- and operator-specific tinkering explains the rest. If anything, Google should aggressively test phones to ensure they adhere to the Android API. For example, call recorder apps apparently work on few phones because many manufacturers do not correctly hand the call soundstream to an app as required by the API; this is exactly the kind of problem Google could easily force the manufacturers to fix.
In the long run, the biggest move I'd like to see from Google is streamlining the update pipeline and eventually cutting operators and HW manufacturers out of it. No reason why HTC, Samsung etc couldn't still offer their own tuned Android, but the user should at any time have an option to go completely vanilla. So for instance: you have a HTC with Sense UI. Android 5.0 hits. You choose to update directly to it from Google. HTC, your operator etc. have no way of preventing this. Three months later HTC has prepared their own 5.0 distribution, and you choose to update to that. This would result in the userbase staying roughly up to date, allay the fears of not getting more updates, and set a very concrete standard of quality for the manufacturers: unless the custom OS beats stock OS, the user bails.
It would be a retarded move for Google to prevent app sideloading. User freedom is the single biggest thing Android offers compared to iOS and Windows Phone.
Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.
But yeah, that'd be one solution.
So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?
Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?
Or the lag on an iPhone 4 running iOS5. My iP4 is stupidly laggy since the update, it's almost like going back to my old iPhone 3G.
Once you kill the background apps, mainly games, your phone lags is gone. I had the same issue with my 3gs iOS5, now my 3GS is running great by deleting background apps.
So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?
Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?
Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.
Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.
I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.
That's just ridiculous. Apple only 'invented' the iOS touchscreen UI. Touchscreens had been around (with UIs underneath them) since the 80's. The HP-150 is likely one of the first personal computers incorporating a touchscreen interface.
Also, despite what many people would like to think, if Google is so desperately trying to steal the iOS UI than why is it so "crappy and laggy"? The UI philosophy is so drastically different it's difficult to understand why people still try to preach that Google has stolen anything at all. Android UI is flexible, customizable and dynamic (themes, widgets, custom launchers, etc). iOS UI is completely rigid and static (no themes, no widgets, one size fits all). The performance problems in Android are in some part related to this fact, as the overhead created in the Android environment is significant.
Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?
Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?
Technically microsoft made a windows for pen computing back in 1991. Tablet pc in 2002 was thrown together.
Microsoft suffers from the has to be everything for everybody problem .Since apple controls the hardware they can do what they want.
And that is one of the main reasons why every Android device has sucked so far. Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.
On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.
There's also another big thing that Android can not do well, it doesn't handle audio properly, and realtime music apps is something else that doesn't exist on Android, because of the terrible latency.
That is fascinating. I have experienced the same problems with my iPod Touch. The OS will lag swiping between app pages, presses don't register, the OS will just hang for no apparent reason.
As for the audio, still prefer the Zune HD audio. Its just a better sound. I don't even bother playing music on the Touch.
Silly comment.
First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.
The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.
If software was designed to run on a blackberry type device and then they had to slap on a touch GUI at the last minute after seeing what Apple was putting out, it doesn't take a rocket scientists to see why this would result in unoptimized graphics.
iOS was designed from the ground up for touch. Andrioid was designed by keyboard/trackball and had a touch GUI slapped on top of it.
"The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get ?lost? in an iPad, but I cringe when a Xoom stutters between home screens," he said.
The jig is up. They've figured out the secret magic ingredient of iOS. I don't think Google doesn't care. The challenge for them will be the fact that they don't own the entire technology "stack": from chips to UI. I don't think that will change. Same case with Microsoft when it comes to Windows. Windows 7 has an "experience rating" which is a number that's supposed to quantify how well your hardware is supposed to work desktop applications. That number varies. With iOS or Mac OS X, the OS is developed more closely with the hardware in mind. The result is that the OS does not fail to utilize the underlying hardware to its full potential.
Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.
Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.
I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.
Good stuff. Thanks.
WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?
Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.
Odd that when Microsoft dominated user experience, nobody was particularly sensitive about "smooth animation" and responsive UIs.
Not exactly true. One thing that Microsoft were always good at (eg XP and earlier) was a responsive UI. The processor may not have been fast, but the UI always was, and it was always very difficult explaining to people that a Mac running System 8/9 was actually faster, when the UI did drag. And badly.
So for instance, you could press on an icon and the Windows machine would be much quicker, however, when it came to rendering something in Photoshop, the Mac would blow the Windows machine away.
It was only when MS allowed woefully inadequate memory on Vista machines did they screw that responsiveness up, and we all know that that allowed the Mac back in.
My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.
But who is saying Apple invented touch screen user interfaces "in general"? I think you are misreading people who are crediting Apple for implementing and popularizing one of the best touch screen user interfaces yet applied to mobile computing devices. It does contain a number of original (and patentable) ideas. But touch screens have been around in GPS nav systems and automated teller machines for years.
Good stuff. Thanks.
WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?
Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.
Yep, you're right. That's the catch.
You can make the UI smooth as glass if you dedicate all of your hardware to the UI first and foremost, which is what iOS does. Android takes a different approach and says, "Let's try to keep this as responsive as possible, but also perform work in the background so other things keep happening."
Both are interesting solutions. Android (generally) has more going on in the background, and can "keep working" while input is being handled--and as hardware improves, that only gets better. The problem is that this system is still subject to periodic stutters, even if minor, which are visually annoying.
For example, on my Evo 4G, the phone performs great. However, when I'm scrolling through a massive post on Google+, it will "stutter" every few seconds, as the UI thread is shared with the background processes. That stutter breaks the "immersion" that iOS users have.
It's an interesting problem, because if Android operated like iOS, then regardless of hardware available, everything else stops for the UI. 5x 4.0Ghz quad-core CPUs and 32 GB of RAM would all stop for the UI in iOS; Android would try to leverage everything as best it could, but at the sacrifice of ultimate smoothness and immersion.
I'm mixed on how I feel.. which is why I'm interested in what Google comes up with. Android J____ is going to be interesting.
But who is saying Apple invented touch screen user interfaces "in general"?
The poster I quoted earlier "Apple invented the touchscreen UI, Google is just trying to steal it" Also, there are plenty of Apple evangelists out there (particularly those defending all these ridiculous IP cases) who claim Apple invented all of the i-device technology that has become overwhelmingly popular in the past 4-5 years. Don't get me wrong, Apple has definitely made strides in applying the tech that is available.