6 ms·

This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other

This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other excuses" Well, the design is broken then. Clearly, it is possible to achieve a smooth UI as demonstrated by iOS and have a solid and stable system. This post is actually worse than saying "we can't fix it" -- it's denying a problem exists in the first place, because "hey, we do it just like iOS." Except it doesn't work like iOS. I recently went back to iPhone because I got so frustrated with Android's jerky UI on my 1-year-old phone (Galaxy S). I went back to a iPhone 3GS that runs iOS 5 faster than the Android ran Froyo (which, btw, I had to jump through 30 different hoops just to upgrade from 2.1). The takeaway is this: Android lost a customer because of slow, laggy UI, and I'm sure I'm not the only one.

inoop 15y ago
Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). The whole 'designed to be open' argument is nonsense. Let's face it, Android was hacked together by a small team on a deadline. It doesn't seem like a lot of thought went into the design and architecture of the system. The code is buggy, there are no tests, and half the tree doesn't even have comments. Bug reports are ignored, and there are about 22k open issues that are not even being triaged. Case in point: http://code.google.com/p/android/issues/detail?id=19078 http://code.google.com/p/android/issues/detail?id=19078 (not fixed in ICS) Android is a rush-job, and the team's obvious lack of experience in handling large software projects is biting them in the ass. Rather than making excuses for their botched together software maybe they should just get their shit together.
- comex 15y ago
  > Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). Well, except that Android allows apps to run arbitrary native code using the NDK.
  - inoop 15y ago
    > Well, except that Android allows apps to run arbitrary native code using the NDK. I was under the assumption that they can support native code because of the way they designed Android, not the other way around. I highly doubt that supporting native code was the design rationale here. I think they just designed Dalvik to use Linux threads and assume it to run inside its own process. That certainly makes things much simpler for the VM. The fact that you can safely load native code follows naturally. Still, supporting native code does not have to dictate how you ensure memory protection, or whether each app has to run inside its own process. You can always run a native library (i.e. a video codec) inside a separate process and use memory-safe communication with the process that runs the Java app. You can also go the NACL route. There's absolutely no reason why supporting native code would result in a choppy UI on Android.
  - daniel_solano 15y ago
    Yes, you can run arbitrary code using the NDK, but you're still sand-boxed into your application's process. Android relies on the Linux security model where each app runs in its own process as its own user. As such, just like with a Linux application, you'd have to find some sort of privilege escalation exploit before you can start mucking around at will.
- babebridou 15y ago
  Your mileage may vary on the quality of the team's job. From where I stand Android is one of those big corporate projects that lets people watch its source code. The ugly parts are on display for all to see, point and rage at, like you just did. On the other side of the fence, even tickets (open or closed) for iOs aren't publicly available. http://stackoverflow.com/questions/6355397/list-of-known-xcode-bugs-gotchas http://stackoverflow.com/questions/6355397/list-of-known-xco...
  - mirkules 15y ago
    The point is that openness is irrelevant in this discussion. I really don't understand why the auhor of the post attempts to wage the open-vs-closed war, except to distract from the real issue: Android's UI is laggy.
- guelo 15y ago
  Wow your comment is misinformed AND insulting, impressive!
  - inoop 15y ago
    To be fair, my claim that there are no tests is a bit overdrawn.
gardarh 15y ago
Funny, what I read was: "This is how Android graphics work, criticize it or praise it, but don't go off explaining it in your own words using wrong facts or incorrect assumptions and telling people you are an expert on the subject"
- scotty79 15y ago
  And how did you read the lat bit about iOS?
- mirkules 15y ago
  That was just one part of the statement, and I agree with that general sentiment. However: "There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave... ...This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all." Really, who cares if they allow third party apps or not? I don't have a jailbroken iPhone, but I've seen jailbroken apps run smooth as butter, so this mystical "Apple quality stamp of approval" argument goes out the window. The post continues: "In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time." Translation: we designed the system to behave in a way which didn't utilize system resources the best way possible. I hope that this is fixed now, but I have my doubts. "I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists... I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS." Nobody said iOS is perfect; yes they have their own flaws (e.g. Safari crashesevery on every once in a while, 3GS sometimes runs out of memory in iOS5, etc), and finding a (edge?) case in which the UI is not smooth on a competing platform seems petty.
  - 15y ago
wslh 15y ago
> This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other excuses" Like: Firefox doesn't have memory leaks.
podperson 15y ago
As someone who prefers iOS to Android I found this article very enlightening (moreso than the earlier article) and I appreciate the design tradeoffs more. I don't think the problem is that Android has jerky animations, it's that it had certain design tradeoffs from the beginning that were all about its security model and allowing third party apps but not about the kinds of UX stuff Apple obsesses over. That's fine -- I don't actually think that all the animated UX crap adds that much value. I like it, but I could live without it. I know there's this cult of "delightful" UX design with animated window transitions and so forth, but every time an app stalls or stutters while trying to animate a transition gratuitously it pisses me off. (Make no mistake, some apps use transitions very skillfully to help the user retain context, but these are usually very simple apps. There's plenty of things I'd fix in Photoshop's UI but adding transitions is not one of them.) I know plenty of Mac OS X users who love Apple to death but switch off every UI animation they can. Let's put it another way -- I love Dropbox and don't think adding "UX" crap to it would improve it in any way. The problem is that having made these tradeoffs in Android, either Google or the Carriers then tried to layer a bunch of half-assed UX crap on top of it, and surprise it doesn't work so well. I'd love a mobile or desktop OS that was all about functionality (which means good, attractive UI design but doesn't require UX frippery). But what we get instead is something caught between two worlds.
- mirkules 15y ago
  "As someone who prefers iOS to Android" I initially fell in love with the freedom of Android, all the potential that came along with it, and the apps I could never have on iOS. Here's my post some 500 days ago: https://news.ycombinator.com/item?id=1586373 https://news.ycombinator.com/item?id=1586373 The funny thing is, I still love the idea of Swype, and using the phone as a USB stick. I just fell out of love with Android because, frankly, the UI lag just made it unusable for me. For example, I want to SoundHound or Shazam a song, click the icon, then wait _at least_ 30 seconds for the UI to come up (by which time the song could be over), click the "listen" button, and have the UI freeze for another 10 seconds without any indication what's going on (did I hit the button? should I tap it again? Is that going to cancel my request if the UI is just slow? I have no idea! Even spinning activity indicators would freeze). 2.2 update broke Swype so I couldn't delete a word from the dictionary. For example, I would type "don't" and it would spit out "Duong" (some person's last name I typed in once), delete it, only to have the same problem next time (tried things to fix it, but no luck). Anyway, I don't expect a fancy UI with animations and transitions, but I do expect a responsive UI -- this is why I went back to 3GS: it works. By the way, I'm one of those people that turns off most of the UI animations (they slow me down).

inoop 15y ago

Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). The whole 'designed to be open' argument is nonsense. Let's face it, Android was hacked together by a small team on a deadline. It doesn't seem like a lot of thought went into the design and architecture of the system. The code is buggy, there are no tests, and half the tree doesn't even have comments. Bug reports are ignored, and there are about 22k open issues that are not even being triaged. Case in point: http://code.google.com/p/android/issues/detail?id=19078 http://code.google.com/p/android/issues/detail?id=19078 (not fixed in ICS) Android is a rush-job, and the team's obvious lack of experience in handling large software projects is biting them in the ass. Rather than making excuses for their botched together software maybe they should just get their shit together.

comex 15y ago
> Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). Well, except that Android allows apps to run arbitrary native code using the NDK.
- inoop 15y ago
  > Well, except that Android allows apps to run arbitrary native code using the NDK. I was under the assumption that they can support native code because of the way they designed Android, not the other way around. I highly doubt that supporting native code was the design rationale here. I think they just designed Dalvik to use Linux threads and assume it to run inside its own process. That certainly makes things much simpler for the VM. The fact that you can safely load native code follows naturally. Still, supporting native code does not have to dictate how you ensure memory protection, or whether each app has to run inside its own process. You can always run a native library (i.e. a video codec) inside a separate process and use memory-safe communication with the process that runs the Java app. You can also go the NACL route. There's absolutely no reason why supporting native code would result in a choppy UI on Android.
- daniel_solano 15y ago
  Yes, you can run arbitrary code using the NDK, but you're still sand-boxed into your application's process. Android relies on the Linux security model where each app runs in its own process as its own user. As such, just like with a Linux application, you'd have to find some sort of privilege escalation exploit before you can start mucking around at will.
babebridou 15y ago
Your mileage may vary on the quality of the team's job. From where I stand Android is one of those big corporate projects that lets people watch its source code. The ugly parts are on display for all to see, point and rage at, like you just did. On the other side of the fence, even tickets (open or closed) for iOs aren't publicly available. http://stackoverflow.com/questions/6355397/list-of-known-xcode-bugs-gotchas http://stackoverflow.com/questions/6355397/list-of-known-xco...
- mirkules 15y ago
  The point is that openness is irrelevant in this discussion. I really don't understand why the auhor of the post attempts to wage the open-vs-closed war, except to distract from the real issue: Android's UI is laggy.
guelo 15y ago
Wow your comment is misinformed AND insulting, impressive!
- inoop 15y ago
  To be fair, my claim that there are no tests is a bit overdrawn.

gardarh 15y ago

Funny, what I read was: "This is how Android graphics work, criticize it or praise it, but don't go off explaining it in your own words using wrong facts or incorrect assumptions and telling people you are an expert on the subject"

scotty79 15y ago
And how did you read the lat bit about iOS?
mirkules 15y ago
That was just one part of the statement, and I agree with that general sentiment. However: "There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave... ...This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all." Really, who cares if they allow third party apps or not? I don't have a jailbroken iPhone, but I've seen jailbroken apps run smooth as butter, so this mystical "Apple quality stamp of approval" argument goes out the window. The post continues: "In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time." Translation: we designed the system to behave in a way which didn't utilize system resources the best way possible. I hope that this is fixed now, but I have my doubts. "I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists... I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS." Nobody said iOS is perfect; yes they have their own flaws (e.g. Safari crashesevery on every once in a while, 3GS sometimes runs out of memory in iOS5, etc), and finding a (edge?) case in which the UI is not smooth on a competing platform seems petty.
- 15y ago

wslh 15y ago

> This post basically amounts to: "There is no problem with graphics on android, it was designed to work this way because of the open nature of android, and other excuses" Like: Firefox doesn't have memory leaks.

podperson 15y ago

As someone who prefers iOS to Android I found this article very enlightening (moreso than the earlier article) and I appreciate the design tradeoffs more. I don't think the problem is that Android has jerky animations, it's that it had certain design tradeoffs from the beginning that were all about its security model and allowing third party apps but not about the kinds of UX stuff Apple obsesses over. That's fine -- I don't actually think that all the animated UX crap adds that much value. I like it, but I could live without it. I know there's this cult of "delightful" UX design with animated window transitions and so forth, but every time an app stalls or stutters while trying to animate a transition gratuitously it pisses me off. (Make no mistake, some apps use transitions very skillfully to help the user retain context, but these are usually very simple apps. There's plenty of things I'd fix in Photoshop's UI but adding transitions is not one of them.) I know plenty of Mac OS X users who love Apple to death but switch off every UI animation they can. Let's put it another way -- I love Dropbox and don't think adding "UX" crap to it would improve it in any way. The problem is that having made these tradeoffs in Android, either Google or the Carriers then tried to layer a bunch of half-assed UX crap on top of it, and surprise it doesn't work so well. I'd love a mobile or desktop OS that was all about functionality (which means good, attractive UI design but doesn't require UX frippery). But what we get instead is something caught between two worlds.

mirkules 15y ago
"As someone who prefers iOS to Android" I initially fell in love with the freedom of Android, all the potential that came along with it, and the apps I could never have on iOS. Here's my post some 500 days ago: https://news.ycombinator.com/item?id=1586373 https://news.ycombinator.com/item?id=1586373 The funny thing is, I still love the idea of Swype, and using the phone as a USB stick. I just fell out of love with Android because, frankly, the UI lag just made it unusable for me. For example, I want to SoundHound or Shazam a song, click the icon, then wait _at least_ 30 seconds for the UI to come up (by which time the song could be over), click the "listen" button, and have the UI freeze for another 10 seconds without any indication what's going on (did I hit the button? should I tap it again? Is that going to cancel my request if the UI is just slow? I have no idea! Even spinning activity indicators would freeze). 2.2 update broke Swype so I couldn't delete a word from the dictionary. For example, I would type "don't" and it would spit out "Duong" (some person's last name I typed in once), delete it, only to have the same problem next time (tried things to fix it, but no luck). Anyway, I don't expect a fancy UI with animations and transitions, but I do expect a responsive UI -- this is why I went back to 3GS: it works. By the way, I'm one of those people that turns off most of the UI animations (they slow me down).