5 ms·

People like to glorify Apple in every way possible and tout whatever advantages they have but the mistake they make is they don't care enough to understand Andr

People like to glorify Apple in every way possible and tout whatever advantages they have but the mistake they make is they don't care enough to understand Android as a platform and its Architecture. Because if they did they will understand that from an developer standpoint Android is absolute delight to develop on. Think about this - when Android goes to tablets with Honeycomb, the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate. Now think how Apple did this with iPad. Think about inter-app communication. Intents are another one of the great platform facilities. Your app can get things done at runtime without worrying about if there is an app installed to handle that intent - if there isn't one it will launch the Market app and suggest you to download the necessary app to handle that activity. The cloud Backup APIs and C2DM stuff is way ahead than what Apple has to offer today. Then there are obviously the notifications. Ever heard any one complain about Apple's horrid notification system? Nope - they are all busy looking at UI animations :) Not having to deal with memory management is added bonus. There are a lot of things Android gets right. If they don't have as many rich animations as iOS it doesn't make a whole lot of difference to end users - having crappy notifications on other hand does affect end users negatively. So all put together I think there are lot many pleasant things to say about Android as a development platform. Purely from an "emotional" or "UI" angle it may not be terrific but from an getting work done fast standpoint it surely is a great platform that also happens to look decent enough not to make you puke ;)

chrisbolt 16y ago
Think about this - when Android goes to tablets with Honeycomb, the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate. Now think how Apple did this with iPad. That may be wonderful for developers, but that will probably make for a horrible user experience.
- blinkingled 16y ago
  No it won't make a bad experience for anyone. See the AllthingsD video interview with Andy Rubin for a demo. GMail app on the tablet is displayed taking full advantage of extra screen real estate by placing its views side by side. Same app goes on a phone and places its view once screen at a time, new view (view mail for e.g.) activated by click for example. This is exactly what iPad apps do, only that in case of Android one binary will do the right thing on tablet and phones.
  - chrisbolt 16y ago
    There are universal iPad/iPhone/iPod touch apps as well. One binary for all three.
    - blinkingled 16y ago
      That's different though. http://devimages.apple.com/iphone/resources/introductiontouniversalapps.pdf http://devimages.apple.com/iphone/resources/introductiontoun... says - "A Universal app is optimized to run on all iPhone OS devices—itʼs essentially an iPhone app and an iPad app built as a single binary." It also lays the responsibility of conditional coding to the apps - to load right resources, show split view by following different code paths etc. There are no two apps in case of Android, only one App with no conditional coding required to support a tablet and a phone. The underlying framework will do the right thing automatically based on where it is running.
wtallis 16y ago
The rather extraordinary claim that a future version of android will be able to "automagically" adjust the UI to suit screen size needs some serious evidence to back it up. Obviously, the operating system is not going to be able to produce the same design decisions that would be made in light of actual experimentation with real users - it will be based on heuristics that will produce sub-optimal results for just about any combination of screen size and resolution other than the original. So I'll assume that you merely meant to assert that the scaling will produce results that are "good enough" in that normal users won't notice that the UI doesn't fit their tablet. Even the claim that it will be "good enough" seems outlandish. Consider the kinds of scalable GUIs that exist on desktops: the important elements of the GUI (like toolbars, menus, and standard buttons) don't get re-sized. At best, they get wrapped or scrolled, either of which is instantly recognizable as a bad design. Most of the sizing flexibility on desktop apps is in the areas that show relatively static content that the user only interacts with passively, like in a web browser or video player, or in the case of many types of games, areas that you only interact with in small bits at a time. (Word processors alternate between the presentation of static content and the interaction (ie. editing) of one spot at a time.) On a multitouch display with direct manipulation of the GUI, you will typically have far fewer opportunities for the easy scalability that web browsers and word processors enjoy. You have to know which UI elements need to maintain the same physical size, which ones need to maintain the same pixel dimensions, and what the limits are on the scalability of the other elements. Take as an example the iPad email app. In landscape mode, you have a list of messages on the left (showing subjects, the first line of the body, and a few other pieces of info), and the body of the currently selected message shown on the right. The right pane takes up about 2/3 of the screen width. If you were to scale this app from the 4:3 iPad display to a 16:9 tablet, how would the left/right split ratio have to change? It's complicated: the entries in the left-side list will have to maintain roughly the same physical height, because they are essentially buttons. You probably want the left pane to remain at least as many characters wide as in the original, so the physical width won't change by much, but you have some flexibility in font sizes. That means that the right pane showing the body of the email will probably be slightly wider and shorter on a 10" 16:9 tablet, but on a significantly smaller tablet, the left/right split might be 50/50. All that is merely a first approximation of how that one app would have to scale. Could a computer derive that? How will the operating system know what the driving constraints are? The OS certainly can't know whether it is better on average to use the extra width of the 16:9 tablet to show more of the subject lines on the left or more of the body on the right. It seems that the only way to make a scalable touch UI work is for the designer to bake in the constraint information, which will require testing at different sizes. This obviously doesn't save any work if you are only targeting two sizes. How many different sizes do you need to target before the rule-based scaling has a significant advantage over manually tuning the different sizes? Whatever that number, Android will exceed it and Apple probably won't. However, this completely ignores the need for more drastic design changes when the difference in sizes is very big, such as between the iPhone and the iPad. And such discontinuities in the scaling hardly require that big a disparity: according to AnandTech's review of the Samsung Galaxy Tab (http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-anandtech-review/3 http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-an...) which is a 7" 16:9 tablet, the best way to type on it is in portrait orientation using your thumbs, whereas on the iPad (9.7" 4:3) you are better off using both hands in landscape. On a 10" 16:9 tablet, you have even more width in landscape mode to accommodate typing with both hands, but how is the OS supposed to know that in portrait mode it is still too wide for two-thumb typing? The only really good scalable UI engine I know of is LaTeX, which outputs completely static content, but can handle a wide range of paper sizes without the author needing to worry about margins, and all the font sizes can be scaled with a single change to the header of the source file. Even so, it doesn't know when the paper size is large enough that you should switch to a two-column format.
Xuzz 16y ago
> If they don't have as many rich animations as iOS it doesn't make a whole lot of difference to end users. Actually, that makes much, much more of a difference to end users than notifications systems or "intents" (both of which, I freely admit, are very awesome). Try a demo for five minutes with an Android phone and an iPhone. Even if the Android phone was more productive in the long run -- and I'm not sure it will be, but let's say that it is -- the pretty UI will win every time. > the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate Is that a good thing? I'm inclined to say that it's not. With a click of a button in the IDE, you can convert your iPhone app to an iPad app, having the OS scale up the UI for you -- it's just a horrible experience. It's not a tablet application. It's an application designed for phone usage patterns, with text columns too wide to read, and reasonably unusable. The iPad Human Interface Guidelines say that "The differences between Mail on iPhone and Mail on iPad reflect the different user experiences of each device." You can use one binary for both interface idioms, but trying to use the same interface, or a slightly changed one, just ends up in a horrible app. I don't want to use a tablet with auto-scaled phone applications, and if that's what Honeycomb makes developer think is somehow a good thing, then shame on it for ruining the Android tablet experience. > Ever heard any one complain about Apple's horrid notification system? I hear complaints all the time. It is awful beyond belief. There is no way to deny that. So was the lack of multitasking about this time last year. That was fixed. > Not having to deal with memory management is added bonus. I develop for the iPhone, and I don't "deal" with memory management. I follow two rules: release what you own, don't release what you don't. (I actually like dislike garbage construction because it causes issues with destructors and non-memory resource management, but that's a different point.) > So all put together I think there are lot many pleasant things to say about Android as a development platform. I agree. There are. But I don't think it's inherently better than iOS, although the Java roots might make it much more familiar to a large section of the programming population (that, however, might also use some experience in a new type of dynamic language).
- blinkingled 16y ago
  Fair points except that the prettiest UI doesn't always win - more productive, more flexible UIs that look decent enough do. And I don't think Android in itself has any limitation that prevents a developer from creating pretty looking apps. Also GC mostly is huge benefit when it is available - like everything it has its downside as you rightly pointed out, but I prefer that over having to remember to release memory in different code paths. Gives me more time to think about program logic. Plus you can always write native code in NDK when you want more control over object deallocation for performance critical code.

chrisbolt 16y ago

Think about this - when Android goes to tablets with Honeycomb, the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate. Now think how Apple did this with iPad. That may be wonderful for developers, but that will probably make for a horrible user experience.

blinkingled 16y ago
No it won't make a bad experience for anyone. See the AllthingsD video interview with Andy Rubin for a demo. GMail app on the tablet is displayed taking full advantage of extra screen real estate by placing its views side by side. Same app goes on a phone and places its view once screen at a time, new view (view mail for e.g.) activated by click for example. This is exactly what iPad apps do, only that in case of Android one binary will do the right thing on tablet and phones.
- chrisbolt 16y ago
  There are universal iPad/iPhone/iPod touch apps as well. One binary for all three.
  - blinkingled 16y ago
    That's different though. http://devimages.apple.com/iphone/resources/introductiontouniversalapps.pdf http://devimages.apple.com/iphone/resources/introductiontoun... says - "A Universal app is optimized to run on all iPhone OS devices—itʼs essentially an iPhone app and an iPad app built as a single binary." It also lays the responsibility of conditional coding to the apps - to load right resources, show split view by following different code paths etc. There are no two apps in case of Android, only one App with no conditional coding required to support a tablet and a phone. The underlying framework will do the right thing automatically based on where it is running.

wtallis 16y ago

The rather extraordinary claim that a future version of android will be able to "automagically" adjust the UI to suit screen size needs some serious evidence to back it up. Obviously, the operating system is not going to be able to produce the same design decisions that would be made in light of actual experimentation with real users - it will be based on heuristics that will produce sub-optimal results for just about any combination of screen size and resolution other than the original. So I'll assume that you merely meant to assert that the scaling will produce results that are "good enough" in that normal users won't notice that the UI doesn't fit their tablet. Even the claim that it will be "good enough" seems outlandish. Consider the kinds of scalable GUIs that exist on desktops: the important elements of the GUI (like toolbars, menus, and standard buttons) don't get re-sized. At best, they get wrapped or scrolled, either of which is instantly recognizable as a bad design. Most of the sizing flexibility on desktop apps is in the areas that show relatively static content that the user only interacts with passively, like in a web browser or video player, or in the case of many types of games, areas that you only interact with in small bits at a time. (Word processors alternate between the presentation of static content and the interaction (ie. editing) of one spot at a time.) On a multitouch display with direct manipulation of the GUI, you will typically have far fewer opportunities for the easy scalability that web browsers and word processors enjoy. You have to know which UI elements need to maintain the same physical size, which ones need to maintain the same pixel dimensions, and what the limits are on the scalability of the other elements. Take as an example the iPad email app. In landscape mode, you have a list of messages on the left (showing subjects, the first line of the body, and a few other pieces of info), and the body of the currently selected message shown on the right. The right pane takes up about 2/3 of the screen width. If you were to scale this app from the 4:3 iPad display to a 16:9 tablet, how would the left/right split ratio have to change? It's complicated: the entries in the left-side list will have to maintain roughly the same physical height, because they are essentially buttons. You probably want the left pane to remain at least as many characters wide as in the original, so the physical width won't change by much, but you have some flexibility in font sizes. That means that the right pane showing the body of the email will probably be slightly wider and shorter on a 10" 16:9 tablet, but on a significantly smaller tablet, the left/right split might be 50/50. All that is merely a first approximation of how that one app would have to scale. Could a computer derive that? How will the operating system know what the driving constraints are? The OS certainly can't know whether it is better on average to use the extra width of the 16:9 tablet to show more of the subject lines on the left or more of the body on the right. It seems that the only way to make a scalable touch UI work is for the designer to bake in the constraint information, which will require testing at different sizes. This obviously doesn't save any work if you are only targeting two sizes. How many different sizes do you need to target before the rule-based scaling has a significant advantage over manually tuning the different sizes? Whatever that number, Android will exceed it and Apple probably won't. However, this completely ignores the need for more drastic design changes when the difference in sizes is very big, such as between the iPhone and the iPad. And such discontinuities in the scaling hardly require that big a disparity: according to AnandTech's review of the Samsung Galaxy Tab (http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-anandtech-review/3 http://www.anandtech.com/show/4062/samsung-galaxy-tab-the-an...) which is a 7" 16:9 tablet, the best way to type on it is in portrait orientation using your thumbs, whereas on the iPad (9.7" 4:3) you are better off using both hands in landscape. On a 10" 16:9 tablet, you have even more width in landscape mode to accommodate typing with both hands, but how is the OS supposed to know that in portrait mode it is still too wide for two-thumb typing? The only really good scalable UI engine I know of is LaTeX, which outputs completely static content, but can handle a wide range of paper sizes without the author needing to worry about margins, and all the font sizes can be scaled with a single change to the header of the source file. Even so, it doesn't know when the paper size is large enough that you should switch to a two-column format.

Xuzz 16y ago

> If they don't have as many rich animations as iOS it doesn't make a whole lot of difference to end users. Actually, that makes much, much more of a difference to end users than notifications systems or "intents" (both of which, I freely admit, are very awesome). Try a demo for five minutes with an Android phone and an iPhone. Even if the Android phone was more productive in the long run -- and I'm not sure it will be, but let's say that it is -- the pretty UI will win every time. > the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate Is that a good thing? I'm inclined to say that it's not. With a click of a button in the IDE, you can convert your iPhone app to an iPad app, having the OS scale up the UI for you -- it's just a horrible experience. It's not a tablet application. It's an application designed for phone usage patterns, with text columns too wide to read, and reasonably unusable. The iPad Human Interface Guidelines say that "The differences between Mail on iPhone and Mail on iPad reflect the different user experiences of each device." You can use one binary for both interface idioms, but trying to use the same interface, or a slightly changed one, just ends up in a horrible app. I don't want to use a tablet with auto-scaled phone applications, and if that's what Honeycomb makes developer think is somehow a good thing, then shame on it for ruining the Android tablet experience. > Ever heard any one complain about Apple's horrid notification system? I hear complaints all the time. It is awful beyond belief. There is no way to deny that. So was the lack of multitasking about this time last year. That was fixed. > Not having to deal with memory management is added bonus. I develop for the iPhone, and I don't "deal" with memory management. I follow two rules: release what you own, don't release what you don't. (I actually like dislike garbage construction because it causes issues with destructors and non-memory resource management, but that's a different point.) > So all put together I think there are lot many pleasant things to say about Android as a development platform. I agree. There are. But I don't think it's inherently better than iOS, although the Java roots might make it much more familiar to a large section of the programming population (that, however, might also use some experience in a new type of dynamic language).

blinkingled 16y ago
Fair points except that the prettiest UI doesn't always win - more productive, more flexible UIs that look decent enough do. And I don't think Android in itself has any limitation that prevents a developer from creating pretty looking apps. Also GC mostly is huge benefit when it is available - like everything it has its downside as you rightly pointed out, but I prefer that over having to remember to release memory in different code paths. Gives me more time to think about program logic. Plus you can always write native code in NDK when you want more control over object deallocation for performance critical code.