8 ms·

One important point is how much misinformation there is out there over fragmentation - a lot of it written by people who don't know (and usually don't care to k

One important point is how much misinformation there is out there over fragmentation - a lot of it written by people who don't know (and usually don't care to know) much about the actual issues. One common meme is the Multiple Resolutions Problem - you know, the onerous problem a developer faces when he has to support both HVGA, QVGA and WVGA resolutions. Except, if you actually do write an app that works well across all those, you find out that managing multiple resources for multiple resolutions is trivial, and that correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios. That is not to say there aren't actual issues - one pain point comes up if you wish to target 1.5 so you can get the widest distribution possible, but are forced to use 1.6 as your target during development. But just to illustrate my point, try a google search for the fictitious resolution "fragmentation" problem, then try one for the real 1.5 vs 1.6 problem.

Groxx 16y ago
correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios. Slightly different sizes, yeah. But the problem for some people / designs, and ultimately for end-users, is that it makes super-designed apps like you see on the iPhone more difficult to make. Not that that should prevent people from programming for / using Android. I personally plan to code a bit for it. But high degrees of polish are significantly more difficult than for a single screen size, and the iPhone has pretty much demonstrated that it does in fact matter to the average user.
- martythemaniak 16y ago
  Maybe it's my web-dev background, but Android reminds me a lot of that. When designing a web-app, styling it using CSS is such a fundamental part of it, that it shouldn't be considered a different activity. No one would seriously put up a webapp that relied on the browser's native rendering of lists, input boxes etc. With the iPhone you do get a lot of that polish for free, whereas with Android the basics won't get you as far. How much more difficult is it? Depends, it's somewhere between an iPhone and a webapp. IIRC, I probably dedicated about 1 week on my last project to this kind of work, which was around 10 weeks. Another thing to consider is how much of that polish is simply due to timing - many iPhone apps have been out there much longer and until it's recent stellar rise, Android was seen as a second-rate platform with far fewer resources devoted to it (for example, the Facebook apps).
  - Groxx 16y ago
    I see a ridiculous amount of fixed-width webpages, which would imply that using even fairly simple, standard components in a fluid way is far more difficult than many developers are interested in doing. Many, not all by any means. Ask an average phone user if they think of the UI as a webpage. Given that nearly all are menu / button based, not links-in-content based, I'd imagine nearly all will say "no". The expectations differ, so their perceptions of the same app differ. Ultimately, which do you want: ubiquitous Android, or geek-only Android? And guess which the average users (and thus hardware makers) want. The push will be to make it ubiquitous, thus successful apps must compete with the iPhone directly in usability and "feel", or people will always feel they've got a second-rate device / application, which is degrading to the whole ecosystem. (for clarification: different devices on the hardware don't bother me for programming - use them or don't, it's your app. The many screen sizes however imply fluid layouts, or huge amounts of fixed + minor fluidity... and clearly nobody wants to make those if they've got careful design (see: webpages). In time with a good library or ten, this could definitely change, as would more focus on design for Android apps. But until that happens, it's fairly damaging to highly-polished apps, which tend to make money more effectively.)
    - chaosmachine 16y ago
      Widescreen monitors killed the fluid layout. It's extremely difficult for a website to look good at both 800px wide (typical netbook) and 2560px wide (27" imac).
      - Groxx 16y ago
        Very true, though not restricting me to 800px wide would be nice sometimes. Say, cap it between 800 and 1024 or a bit higher. Too wide is too hard to read anyway. Given the amount of reading I tend to do, and the infinite-scrollability of webpages, I'm often a portrait-mode fan. It just sucks when you need a bunch of applications open for comparison / parallel development. edit: hm. widescreen / horizontal Android devices exist (ODROID). So we're back to the same issue...
    - theBobMcCormick 16y ago
dieterrams 16y ago
Re: the Multiple Resolutions Problem, it's probably less of an issue if you're writing a utility app. But for games, which frequently make use of resolution-dependent assets, it is far from trivial or fictitious. A larger developer might be able to eat the cost of maintaining multiple sets of assets, but smaller developers frequently can't. Nor can they typically afford to own a comprehensive set of devices to test on, which is necessary if you're trying to figure out things like how many sprites or particles you can display at a given resolution and framerate.
- martythemaniak 16y ago
  The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets. As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
  - dieterrams 16y ago
    The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. This technique doesn't work for pixel art, which can only be scaled up by whole number values. In certain cases where a display's resolution isn't a whole number multiple of the base resolution, you can get away with slightly shrinking or extending the viewable area. But 480x320 to 800x480 is a particularly inconvenient shift, as assets cannot be scaled up without incurring a large loss in viewable area, and they cannot be kept the same without requiring a large increase in viewable area. Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets. Not true at all. It would only look fuzzy if the screen size were significantly larger. But in fact the screen size is roughly the same, only with a much higher PPI. Because the new resolution is a whole number multiple of the old, all apps can be trivially scaled with 2X nearest-neighbor scaling and look exactly the same as they would on a 480x320 screen. As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it. I actually do have a first-gen iPhone. In my experience, it hasn't been that slow for the majority of apps I want to use. But that's sort of irrelevant. As far as a developer is concerned, they only need to own two devices (three after the new iPhone is released) to capture the significant variations in hardware: a first-gen or 3G iPhone, and a 3GS. (Alternatively, and more cheaply, a first-gen and third-gen iPod touch, if you have no need for camera, GPS, etc.) And it's true that you can never get away from dealing with different hardware, but the whole point is how much different hardware you have to deal with. Apple has been very careful about keeping that to a minimum while satisfying demand for better hardware.
FooBarWidget 16y ago
What is the 1.5 vs 1.6 problem? I thought in the Android SDK you can select your target. What's forcing you to use 1.6 during development?
- blasdel 16y ago
  It's very common for newer releases of SDK toolchains to drop support for targeting older SDKs. Apple has done the same thing with OS X several times.

Groxx 16y ago

correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios. Slightly different sizes, yeah. But the problem for some people / designs, and ultimately for end-users, is that it makes super-designed apps like you see on the iPhone more difficult to make. Not that that should prevent people from programming for / using Android. I personally plan to code a bit for it. But high degrees of polish are significantly more difficult than for a single screen size, and the iPhone has pretty much demonstrated that it does in fact matter to the average user.

martythemaniak 16y ago
Maybe it's my web-dev background, but Android reminds me a lot of that. When designing a web-app, styling it using CSS is such a fundamental part of it, that it shouldn't be considered a different activity. No one would seriously put up a webapp that relied on the browser's native rendering of lists, input boxes etc. With the iPhone you do get a lot of that polish for free, whereas with Android the basics won't get you as far. How much more difficult is it? Depends, it's somewhere between an iPhone and a webapp. IIRC, I probably dedicated about 1 week on my last project to this kind of work, which was around 10 weeks. Another thing to consider is how much of that polish is simply due to timing - many iPhone apps have been out there much longer and until it's recent stellar rise, Android was seen as a second-rate platform with far fewer resources devoted to it (for example, the Facebook apps).
- Groxx 16y ago
  I see a ridiculous amount of fixed-width webpages, which would imply that using even fairly simple, standard components in a fluid way is far more difficult than many developers are interested in doing. Many, not all by any means. Ask an average phone user if they think of the UI as a webpage. Given that nearly all are menu / button based, not links-in-content based, I'd imagine nearly all will say "no". The expectations differ, so their perceptions of the same app differ. Ultimately, which do you want: ubiquitous Android, or geek-only Android? And guess which the average users (and thus hardware makers) want. The push will be to make it ubiquitous, thus successful apps must compete with the iPhone directly in usability and "feel", or people will always feel they've got a second-rate device / application, which is degrading to the whole ecosystem. (for clarification: different devices on the hardware don't bother me for programming - use them or don't, it's your app. The many screen sizes however imply fluid layouts, or huge amounts of fixed + minor fluidity... and clearly nobody wants to make those if they've got careful design (see: webpages). In time with a good library or ten, this could definitely change, as would more focus on design for Android apps. But until that happens, it's fairly damaging to highly-polished apps, which tend to make money more effectively.)
  - chaosmachine 16y ago
    Widescreen monitors killed the fluid layout. It's extremely difficult for a website to look good at both 800px wide (typical netbook) and 2560px wide (27" imac).
    - Groxx 16y ago
      Very true, though not restricting me to 800px wide would be nice sometimes. Say, cap it between 800 and 1024 or a bit higher. Too wide is too hard to read anyway. Given the amount of reading I tend to do, and the infinite-scrollability of webpages, I'm often a portrait-mode fan. It just sucks when you need a bunch of applications open for comparison / parallel development. edit: hm. widescreen / horizontal Android devices exist (ODROID). So we're back to the same issue...
  - theBobMcCormick 16y ago

dieterrams 16y ago

Re: the Multiple Resolutions Problem, it's probably less of an issue if you're writing a utility app. But for games, which frequently make use of resolution-dependent assets, it is far from trivial or fictitious. A larger developer might be able to eat the cost of maintaining multiple sets of assets, but smaller developers frequently can't. Nor can they typically afford to own a comprehensive set of devices to test on, which is necessary if you're trying to figure out things like how many sprites or particles you can display at a given resolution and framerate.

martythemaniak 16y ago
The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets. As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
- dieterrams 16y ago
  The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. This technique doesn't work for pixel art, which can only be scaled up by whole number values. In certain cases where a display's resolution isn't a whole number multiple of the base resolution, you can get away with slightly shrinking or extending the viewable area. But 480x320 to 800x480 is a particularly inconvenient shift, as assets cannot be scaled up without incurring a large loss in viewable area, and they cannot be kept the same without requiring a large increase in viewable area. Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets. Not true at all. It would only look fuzzy if the screen size were significantly larger. But in fact the screen size is roughly the same, only with a much higher PPI. Because the new resolution is a whole number multiple of the old, all apps can be trivially scaled with 2X nearest-neighbor scaling and look exactly the same as they would on a 480x320 screen. As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it. I actually do have a first-gen iPhone. In my experience, it hasn't been that slow for the majority of apps I want to use. But that's sort of irrelevant. As far as a developer is concerned, they only need to own two devices (three after the new iPhone is released) to capture the significant variations in hardware: a first-gen or 3G iPhone, and a 3GS. (Alternatively, and more cheaply, a first-gen and third-gen iPod touch, if you have no need for camera, GPS, etc.) And it's true that you can never get away from dealing with different hardware, but the whole point is how much different hardware you have to deal with. Apple has been very careful about keeping that to a minimum while satisfying demand for better hardware.

FooBarWidget 16y ago

What is the 1.5 vs 1.6 problem? I thought in the Android SDK you can select your target. What's forcing you to use 1.6 during development?

blasdel 16y ago
It's very common for newer releases of SDK toolchains to drop support for targeting older SDKs. Apple has done the same thing with OS X several times.