Slashdot Mirror
Android Compatibility and Fragmentation
tbray writes "Here are the details on the Android Compatibility Program — which combines the source, a formal compatibility spec, an open-source test suite, and access to the Android Market as reward for good behavior (program page). People like to rant about the subject of fragmentation, so here's TFM that they should be R'ing first."
Fragmentation is mostly FUD, there are only a few screen sizes and the OS changes are pretty minimal.
* Bugs - devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.
* Missing components - devices might omit hardware (such as a camera) that apps expect, and attempt to "fake" or stub out the corresponding API.
* Added or altered APIs - devices might add or alter APIs that aren't part of standard Android. Done correctly this is innovation; done poorly and it's "embrace and extend".
Each of these is an example of something that can make an app not run properly on a device. They might run, but they won't run properly. These are the things that I spend my time preventing.
The only thing I might add is that devices of different resolutions can be annoying, especially if your app has static images or custom widgets.
Qxe4
Are the screen sizes a big deal? Application and web developers have dealt with this problem for decades now.
There's no -1 for "I don't get it."
"The thing is, nobody ever defined “fragmentation”"
Let me try: You have several different versions of Android 'in the wild' on different phones, different carriers, etc. There are different stances on whether these version of Android can be updated (based on manufacturer) etc. yadda yadda
Now, looking at that situation, I would say 'fragmentation' is more along the lines of 'Is it going to remain easy for to target Android phones in general considering how many versions currently exist [/not obsolete] concurrently?'
So yes, it is mainly about compatibility. But it also means (much like any other platform) if the version leaping continues (and so many versions exist concurrently all the time) playing to the 'lowest common denominator' of supported features will be required
this should have been made perfectly clear from google's side from day one. Yet everyone kept talking about android marketplace as if it was a part of the android source until the first android based devices without marketplace showed up, and none could figure out why.
i only ran into it after ranting about google's mismanagement of marketplace access on some forum, and got a link handed to me.
another issue is that 1.6 required that a compatible device could function as a phone. So any device thats been in development since 1.6 was first released, wont have marketplace unless its a phone or stalls its release until they can get 2.1 or newer working and approved by google. And even then the max resolution of the screen is 800x600, and i think the screen size is in the 5-7" range.
basically, google is lagging badly behind where third parties want to go with android. And its not helping that marketplace is only really usable in select nations so far (and when a sim is inserted into the device).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
the impression i have gotten on the default android keyboard at least is that it works independent of the ui of the app in use at the time. It will fade out the entire app, and display what your typing in a area above the keyboard rather then attempt to stuff it inside the ui of the app.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
The hardware vs onscreen keyboard does not require two apps.
The iphone is not one platform, there are 3 different phones and there is about to be a forth.
You will have either fragmentation, or stagnation as the device gets older. Even something totally controlled like the iPhone. As time goes on, one of three things will happen:
1) Apple will introduce new iPhones with features the old ones do not, and cannot, have such as higher rez screens, faster CPUs, etc. Software for these new phones will not run properly, if at all on the old ones. The phones will fragment along the lines of new and old.
2) Apple will refuse to introduce any features that would break compatibility with older phones. They maintain total compatibility through keeping various things at one spec. This leads to stagnation of increasing proportions as time goes on, such that new iPhones are literally years behind competing products.
3) Apple discontinues all support for older iPhones. They have the service providers remotely kill the hardware so you are required to purchase new hardware.
There's just no way around it. If you want new devices to have new capabilities, well it will lead to fragmentation. There are plenty of things you can do to help, particularly in making sure newer devices can seamlessly run older software, but you can't have all sorts of new stuff and have everything work just like it did before.
So fragmentation will ALWAYS be an android issue until they say "here is our reference hardware platform(s) -- you must use of these three sets of features when building hardware."
To an extent that's already happening. Phone goliath Nokia among others are setting up an alternative to appstore:
Twenty-four mobile network operators have formed the Wholesale Applications Community to avoid fragmenting the apps market and to give developers one point of entry to all the members, the GSM Association announced on Monday.
The operators will now start working on uniting their existing developer communities, so developers will be able to go to one place to get their applications distributed instead of having to go through multiple application approval processes.
The community will also start working on a common development standard that should be ready within the next 12 months. The standard will be independent of phone type and operating system, according to the members.
That will allow them to better compete against Apple's App Store or Google's Android Market, which have independent and competing approvals processes tied to their phone or operating system.
"Developers are going to have a lot more access to a lot more customers," said Alex Sinclair, chief technology and strategy officer of the GSMA, at a news conference at the Mobile World Congress in Barcelona.
The Wholesale Applications Community members include: AT&T, China Mobile, Deutsche Telekom, NTT DoCoMo, Orange, Telefónica, Telenor Group, Sprint, Verizon Wireless and Vodafone. Together the operators in the group have about 3 billion subscribers, the GSMA said.
The group has the full backing of the GSMA and the list of supporters will grow in the coming days. "There are several people who are annoyed they couldn't get their name on the list in time," said Sinclair.
Apple is not among those clamoring to be added to the list, but if the company wants to join the group, "it will be welcome," he said.
Just like many phone manufacturers, operators have seen the success of Apple's App Store and want a piece of the pie. Some, including Orange, Verizon and Vodafone, have already launched their own application stores.
Mobile phone manufacturers LG Electronics, Samsung and Sony Ericsson have also voiced their support for the apps community.
The Wholesale Applications Community faces a number of obstacles, according to analysts at CCS Insight.
"Operators are trying to regain control of apps, but have a poor track record with this type of industry consortium," they said in a research note.
"Big challenges remain overcoming inconsistency between standards bodies like JIL and Bondi," the analysts continued, referring to the Joint Innovation Lab created by a group of mobile operators including Vodafone, China Mobile, Softbank and Verizon Wireless, which also has the support of phone manufacturers LG Electronics, Research in Motion, Samsung Electronics and Sharp.
There is no competition between the Wholesale Applications Community and JIL, as all members of JIL are also members of the community, according to Sinclair.
"The last thing we wanted was a Jack versus JIL situation," he said. The groups hope to converge their various specifications within 12 months, he said.
These are some seriously big names, big enough to knock it out of the park if they wanted to.
What he can't kill, he has sex on. Trent.
Amen and well said. It amuses me to no end seeing the comments from people who have never developed for a mobile device saying fragmentation is BS and desktop has been dealing with it for years so it's no problem at all. What a joke. Try developing an app where: - there may or may not be a physical keyboard - the screen resolution may or may not differ - the screen aspect ration may or may not differ - the screen DPI may or may not differ - the camera may or may not work (or exist) - the RAM could vary wildly - the processor could vary wildly - there may or may not be multitouch - the screen may or may not be of decent enough quality to accurately and quickly detect touches The list goes on and on and on and it will only get longer over time. I just cant wait until there are tablets of every conceivable configuration and OS version on the market. Even then there will be my good buddies commenting on how "fragmentation is FUD".
"You have to design a version for on-screen keyboards (because it'll use part of the screen real estate) separately from a version that uses a hardware keyboard. They don't need to be separate apps, but you need to design (visually at least) for both scenarios, or you end up locking out a good portion of the people who use android devices."
Please, tell me what the name of any of your apps are, since they would be the FIRST I have seen that bother to code for different keyboards. The rest all just let the screen sit, and let the Android keyboard cover them up.
I've learned to deal with this, but on some web pages, the keyboard covers up the form no matter what I try, so Steel and the Browser fail here. The Craigslist app I use covers up option button on their form. Maps in search ditto, but nothing is lost.
This is a nonissue, unless you've coded to move your screen intelligently to keep required real estate visible despite the keyboard.
Actually, I meant to call you out. This is a BS issue for me. But hell, I'm just a user. I know nothing.
deleting the extra space after periods so i can stay relevant, yeah.
It amuses me to no end
Is that you, Lo Pan?
What he can't kill, he has sex on. Trent.
The amusing part is TFA doesn't say what they submitter thinks it does - they openly admit fragmentation exists. And their response to fragmentation? "Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don't have the features you listed".
And thus, magically, since no one can download an app that they cannot run - fragmentation is gone. (It should go without saying this is laughable.)
Google is making sure that your app will run one someones hardware/OS, but that's a far cry from making sure it runs on all hardware/OS combinations.
So what happens if Apple releases an iPhone with a blackberry like keyboard - something which a lot of enterprises have asked for? You need to write a condition check to see if the device has a keyboard, or if it doesn't and act accordingly.
You can write a filter for your application manifest to filter the app so it doesn't appear on Android phones without a keyboard.
Or you could write two versions like you say.
There's 3 solutions for you.
This problem seemed to be solved ages ago on Symbian ;).
Even now lots of web developers want to treat the browser view like a physical sheet of paper, demanding iron-fisted control over placement of everything on the page. This leads to all kinds of work to maintain the control. I keep wishing more web developers would get over this. Not only would I find it a lot easier to actually make use of their work on smaller screens (my Android phone, my netbook...), I think in the end it would be a lot easier for the developers, too.
It sounds like mobile application developers often have the same problem...
Hacker Public Radio is our Friend
1 - We hate apple beacuse they are closed ( but predicable )
2 - We hate android beacuse its not predictable ( but open )
Cant have it both ways...
Oh, and #3 - We hate windows phones, just beacuse..
---- Booth was a patriot ----
One of the disasters on Android is that handset makers are allowed to make their own custom UI. Does HTC better google in some ways? Absolutely. But users and developers both need a consistent UI to use and design for.
As a consumer I really wanted to support Google's carrier independent supply chain by purchasing a Nexus 1, but the screen was terrible. Hoping to grab a newer HTC, but they have their own custom UI. May end up with the new iPhone after all.
So fragmentation will ALWAYS be an android issue until they say "here is our reference hardware platform(s) -- you must use of these three sets of features when building hardware." Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
Microsoft does that for desktops too, and probably any device that runs a Windows OS for that matter. In order to get the little Windows badge, the computer has to have certain minimum specs. It doesn't seem like much, but if they didn't have any kind of certification program, things could be much, much worse in Windows land. Windows Media Center PCs all had to have TV tuners and DVD/CD burners for example, and I'm sure there were more requirements besides the obvious.
Google will probably have to do the same to stay ahead of Apple, or any combined HW/SW maker, or at least to stem fragmentation.
Another way to look at this, and something I think many are overlooking here is _future_ features. Android can't effectively lead in features if they have to wait for the phone manufacturers to one by one adopt the latest proven iPhone features. They'll have to do what Microsoft does and sweet talk the hardware manufacturers into somewhat simultaneously supporting a new feature and that's not even easy for Microsoft to do. Otherwise, Android phones might once in a while sport bleeding edge features, but not in a consistent way, and Google wouldn't be able to take advantage of them until the feature was widespread and supported by multiple manufacturers.
This same stuff plays out between OS X and Windows, Macs and PCs all the time. Apple can say "from now on, all devices will have X, build rich software around X", even "all new device wont have Y", wheres Microsoft and Google have to work harder to pull off projects like Microsoft's Media Center PCs or get rid of floppy drives, or 16-bit BIOS for example. A more recent example is HP's push into touch screen desktops. Apple could probably sit on its ass for few years at this rate, say "let there be touchscreen Macs" and leave the Windows touch screen PC (wherever they end up then) in the dust, playing catch up!
I would clarify that fragmentation affects iPhones, Android phones, PCs and Macs but the difference is Apple can control it.
Correction, not Nokia, but 3 billion customers is hard to argue with.
What he can't kill, he has sex on. Trent.
I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.
Some examples of bizarre stuff I have to do:
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don't even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?
Anyway, I'm constantly dealing with issues like this. It is really disappointing that Android team, the carriers, and the device manufacturers don't do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google's part to do it.
Meanwhile Google isn't even interested in solutions to these problems from what I've seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like .NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.
This isn't really surprising. If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it. Independent developers can't afford to ignore large sections of the marketplace like that. Google isn't in the app business, so the Googlers just go ahead and ignore the issue. You can see a graph of the versions of the devices on Android Market here:
http://developer.android.com/intl/fr/resources/dashboard/platform-versions.html
And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.
So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.
Now that 24" screens are cheap and plentiful a lot of bad web design is starting to show. For example "fixed width" layouts where all the content is in a narrow vertical strip bordered by eight inches of whitespace on both sides.
Then unmaximize your window. Fixed width designs are meant for putting two web pages side-by-side. Windows XP and Windows 7 both support a split screen: in XP, you click one taskbar button, Ctrl+right click, and choose Tile Vertically, and in Windows 7, you drag each window to the left or right side of the screen.
Yet strangely many people are successfully doing this.
Completely wrong. Where are you getting this from?
Over 100,000 Android devices activated per day.
No you don't. You have no idea what you're talking about. And you're at Score:4 right now, which is shameful.
Ugh. You shouldn't have posted because almost everything you have said is just completely wrong.
The Android developer platform is extraordinarily universal. There's a density independent pixel format (which is how an app looks almost the same on a 320x480 screen as it looks on a 480x800 screen), support for varying screen ratios, a single way to inter-operate with the camera and send emails and read the GPS signal and get orientation signals, or even do advance OpenGL graphics.
One app to rule them all.
There are of course differences and occasionally "quirks". If you make a rich graphics game it's going to run terribly on a G1. Flash is only available on some devices. And of course if you have to target a newer API, presumably because it has a feature that you can't live without, you limit your app to that version and above (just as if I use Transactional Filesystem calls my Windows app would be Vista or newer).
Most of the phones that run 1.5 right now are terribly underpowered -- OpenGL on a G1 is almost a sick joke.
If you're targeting OpenGL, you probably should cut your losses and cut them.
The Twitter application is an Android showpiece app, which is why it targets 2.1. They wanted to use animated wallpaper, quick contact bars, and so on, to highlight the best of the contemporary platform. Aside from the fact that about 50% of Android phones are running 2.1 right now, most other phones are going to see a 2.1 upgrade in the relatively short term. I suspect Google intentionally targets 2.1 to try to motivate the vendors to expedite their upgrades.
You will find the answer to this mystery in "The Cathedral and the Bazaar" by Eric S. Raymond [1992].
Basically, Microsoft and Apple are code cathedrals. Using the Cathedral system they can organize the labor of a great many people. In a Cathedral you can do anything that is permitted to be done in that Cathedral - which can be almost anything that brings the controlling powers profit really. But if you want to do something they don't want you to do, then you can't and there's nothing you can do about it but leave the cathedral or accept that you can't do that thing.
Android and the Linuxes are the Bazaar. It's noisy and chaotic. It can be harder to find things. Some of the things you find in a Bazaar are quite crude. But in the Bazaar you can do anything you want any way you want. The Bazaar is run by everybody in it, for each to his own benefit. Almost anything that can be found in the Cathedral can also be purchased in the Bazaar by a man with ready cash. Almost anything.
One thing that can be bought in the Cathedral but not in the Bazaar is the preventing of things you don't want others to do. If somebody wants to prevent the use of VP8 or Flash in the Cathedral, or the development of hardware platforms that don't run Windows, well, anything can be proscribed if the price is right. The Cathedral is run by the head priest, and not specifically for your benefit but primarily for the benefit of the Cathedral - because it's this self serving nature that makes Cathedrals persistent and powerful.
One is not necessarily better than the other. Each has merits, each has uses.
Help stamp out iliturcy.
there are too many variables in the android world to code an app once to run successfully across the ecosystem.
Fail. There already are thousands of apps that work across everything from the original G-1 to the latest, greatest device from HTC, Moto, Samsung or whoever.
You have to design a version for on-screen keyboards
I suppose you could do that, if you wanted to spend 90% of your money rewriting libraries that are part of the Android operating system. And your app would be huge. It's a lot easier to use Android's widgets and let the operating system help you out with things like keyboard input and the like. If you do it right, the user can pick from the 25 or so virtual input devices in the market and enter text in the format they like. These really aren't a big deal, and are in many ways the same issues we've dealt with for years with Windows and Macintosh applications running on different size monitors, with different resolutions and different pixel densities.
So fragmentation will ALWAYS be an android issue until they say "here is our reference hardware platform(s) -- you must use of these three sets of features when building hardware."
You have a very fundamental lack of understanding of how computers work. This is what operating systems, device drivers and APIs are for. I code to the GPS API. The API talks to the driver, the driver to the hardware, and the OS orchestrates everything. I don't have to know the details of the underlying hardware. This is also not a new concept in computers and is one of the reasons operating systems exist - to abstract hardware details. Most OSes have an open file command. That command makes all the software and hardware that goes into accessing something stored in a compressed, encrypted hard drive invisible to the programmer. Same goes with keyboard input. With Android, it goes a level deeper - Android apps, even when ran on an Android phone run inside of a virtual machine that insulates the application from raw hardware nearly completely.
Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it.
Microsoft has certainly not been doing a knock out job in the decision making department for several year, outside Xbox. They've lost the catbird's seat in mobile phones, and their CE/Mobile operating system hasn't evolved much in ten years. MS is now trying to replicate the iTunes model, and not trying to come out with a world beating platform. It's remarkable how far away this strategy is to how MS became the biggest game in the computer business. They allowed rapid evolution of hardware. They encouraged their customers like Compaq, HP, ALR, IBM, Dell and Gateway to push envelopes and bring better, faster computers on an almost weekly basis for 20 years.
-- $G
Or you could just use Android's libraries and widgets and let the OS pop up the onscreen keyboard when someone taps into a text field or accept keyboard input when a slider's keyboard is open. Ironically, those phones with keyboards actually use both the onscreen keyboard (when the phone is closed) and the hardware keyboard. The whole thing is largely invisible to the programmer.
Oh, and you have one app.
-- $G
... but - are we starting to see fanboyism in the Android realm?
Why, no, I haven't meta-moderated lately. Thanks for asking!
He suggested making the highest level of Android a distributable framework, like .NET
I thought Java was a distributable framework, like .NET. And I doubt every .NET runtime (including Mono etc) is completely bug-free either.
And Google have already said they planned to spin off components of the OS, where possible, to make updating those components much easier.
Look, you make a fair point about dealing with different hardware and different bugs, and I sympathise, but these sort of time/market tradeoffs are nothing new, especially on popular platforms (Windows and Linux PCs, Macs too, huge varieties of graphics hardware, memory, CPU speeds, screen resolutions, OS versions, driver versions, blah blah - I run into it too). The only way to avoid it is to buy into a single, locked-down platform (like e.g. a specific game console) - which risks stagnation, and limits your market.
Why would anyone engrave "Elbereth"?
The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
If they made an update, say 1.5.1, you would still want the old code path for the devices that hadn't upgraded - which leaves you in exactly the same position you are in now.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance.
I'm not sure what you want Google to do about this. Do you want Google to dictate a certain hardware spec to all the vendors? If you favor a consistent platform (more or less) from a well-known set of hardware on a single carrier, you should go with Apple.
This is simply software engineering - taking one set of trade-offs for others. If you want newer features, you target the later API, at the cost of a smaller audience. These are all very straight-forward cost/benefit decisions, that YOU get to make, not Google. This is the strength of the open platform.
Through the market you can reach an enormous diversity of devices, which translates to a huge audience. I agree - it would be an amazing world if you could write a app once that works flawlessly on all of them. But as a software developer myself, I don't think that expectation is reasonable. That being said, I think Android does work quite well, and good luck on another platform like WinMo7.
http://www.talknerdy.org
Indeed. There have been several occasions on which I was forced to upgrade the OS on my iPod Touch, just to use a new app. ("Forced" as in: The app would not bloody install on the software version I was running.)
And, of course: On the iPod Touch, OS upgrades sometimes cost actual money.
So. If we assume that fragmentation is a problem, then it is very plain that it is not an Android-specific problem.
Kid-proof tablet..
Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
It's a bit too convenient, because MS is just starting anew. What do you think will happen when those three platforms start getting obsolete?
Windows is totally fragmented. It's terrible. Why do people develop for it? Every machine has a different amount of memory, hard drive, resolution, aspect ratio, 3D capabilities. Some have mice, some have trackballs, some have joysticks. Plus, there's all these different versions: XP, Vista, Windows 7. For gamers it is worse: DirectX 9, DirectX 10, OpenGL. Even their flagship product has a mess of versions: .NET 1.0, 1.1, 2.0, 3.0, 3.5, and 4.0 are all found in the wild. Browser versions, service packs...
Why does anyone program for this OS? Because it is fragmented. Fragmentation is a **benefit** - because if it weren't fragmented, the alternative is that each of these computers would have a different operating system. I'd rather have one approximately-the-same, cohesive API across different hardware, than have each device run a different OS. What they are calling "fragmentation" in the Android OS is called choice and diversity on other OSs. This is a good thing, and be happy with it.
Everything you describe seems to apply to Windows, Linux, and just about every other operating system there is. If you look at most games, they have to do serious optimization to handle older video cards, including separate code paths. It sucks, but it isn't Android only. I am confused though as to why there are phones running these older versions. Why is that?
And of course if you have to target a newer API, presumably because it has a feature that you can't live without, you limit your app to that version and above (just as if I use Transactional Filesystem calls my Windows app would be Vista or newer).
Actually that's not completely true. You can target a newer API version and still define a previous version as your minimum API level in the manifest.
That's what the documentation proposes if you want to support different DPIs (introduced in 1.6) and still make your app available to devices running 1.5.
This will work well as long as you don't explicitly call any functions which are only available in the newer API. In fact, I haven't tried this, but I guess if you want to use a new API feature, you can do it as long as you block previous APIs from making that call with an IF clause. As I said, I haven't tried that, but my guess is it should work.
This is my thoughts exactly.
You're gaining a huge install base by having Android compatible with multiple handsets. People like choosing different feature sets, not everyone wants a keyboard for example, but some wouldn't live without one. Some people will pay extra for a phone with excellent gaming performance, others won't care.
This is akin to figuring out if a hypothetical game will run on User X's computer. Ship the game for a console if you don't want to deal with it.
To be fair, for the wide variety of devices Android supports, there are very very few compatibility glitches.
- Michael T. Babcock (Yes, I blog)
My G1 runs 2.1 and opengl apps run great... where have you been?
That's my point - you can check for conditions and act accordingly :).
The GPU of the G1 is horribly underpowered, the processor not supporting NEON, and the RAM on the device is barely capable of running the OS alone. The G1 is the reason gaming on the Android platform is still so immature.
Phones like the Nexus One, the Samsung Galaxy S, and the Moto Droid are magnitudes more powerful in the graphics department.
HTC doesn't offer a 2.1 upgrade for my HTC Tattoo. Period. It's supposed to "real soon now", it doesn't. Is Google at fault? Is Android? Is HTC? You know what, I don't care, it just doesn't work.
This is the strength of the open platform.
Having a limited audience and increased development costs is a strength? Awesome.
Reddit picked up on this thread here http://www.reddit.com/r/programming/comments/cal37/comment_on_slashdot_detailing_the_so_called/
But a lot of the time you don't need that much juice. Any 3D hardware has the power to run something with the complexity of the original GLQuake, for example. Most game developers aren't after staggering graphical performance. They just need hardware that will draw a few textured objects.
But a lot of the time you don't need that much juice. Any 3D hardware has the power to run something with the complexity of the original GLQuake, for example. Most game developers aren't after staggering graphical performance. They just need hardware that will draw a few textured objects.
Maybe Droid developers. Meanwhile, the big studios are targetting the iPhone.
I honestly believe that 1.5 users (and some 1.6) are not heavy users that will be purchasing a lot of apps. the iphone set a trend of buying a replacement phone at least every 18 months. how many 1.5 users are just about to buy a new phone? Also, what is the volume of market usage (sells) on this bracket (1.5 users) I agree that fragmentation is not effective, but is far from being an issue or something unacceptable. I think that newer phones deserve better attention. If I bought a new phone 2.2 or 2.1 I did it because app implementation is going to be faster and better. I am all about not setting breaks on development because everything needs to be compatible/cool with 1.5. 1.5 devices have a hardware disadvantage. my two cents!
Wouldn't it make a whole lot more sense to flow to the size of my screen like anything else, so I can do either?
No. There's a reason that print newspapers are laid out with a story in multiple narrow columns rather than spanning the text across the entire width of the page. Part of reading is finding the next line of text, and that's uncomfortable if the line is longer than about 40em, or 80 characters, or 20 words.
This response is total BS ... getting vanilla Android apps to work across devices and operating systems is trivial enough, but once you do anything interesting (use the GPS, camera, address book, etc) some phones will surely wet the bed.
Write once, debug everywhere.
It's little things like this that make the iPhone that much more attractive. There's no automatic UI rearrangement, but Apple at least publishes examples and guidelines to assist with view management. I've never come across an iPhone app that didn't ensure that the text area was in view when the keyboard was active.
iPad developers have to deal with this now. The iPad can be docked or paired with a physical keyboard. There are APIs and sample code to help deal with this.
I have to agree with csartanis: Hacked system images like Cyanogen show that G1 hardware is, at least, adequate.
The problem is OEMs have no incentive to put money into handsets they sold two years ago. Google has to take up the slack, either by creating incentives to update older handsets, or legitimizing hacks like Cyanogen as a form of "aftermarket upgrade."
I wrote parts of this stuff
Yeah, because the hardware of the (Motorola) Droid is so different than the iPhone 3GS. Oh wait, no, it's almost exactly the same.
The graphics-intensive, pretty 3D games on the iPhone are mostly horribly sluggish. Not very impressive. The iPad is better, but not amazingly so.
Nobody, nobody targeting mainstream mobile devices is doing 3D stuff beyond what we saw on PCs ten years ago.
Yet, you're having to ignore large portions of that install base if you're going with newer features of the OS. You have to decide if that new feature that may be required for your app is worth alienating a significant part of the Android install base. At least with Apple, if they add a feature to the OS, you can reliably begin using it when its released, and be assured that most of your install base can use it.
There are still 1.5 and 1.6 devices being sold. The Hero, the Droid Eris, and the G1 are still being sold, and with the exception of the Hero, have no plans of being updated.
I had to read this a few times to make sure this post wasn't a few months old. Both the hero and eris have received an OTA 2.1 upgrade in may. The only US 1.5/6 devices are the G1, MyTouch and Behold 2.
Wow, you just made me re-animate my /. account.
You have just described some of the major reasons I have gone in a great big circle around the Android phones, even if I find the *idea* of a Linux-based phone OS by Google very appealing. I have an iPhone that has all the same advantages of the Apple computers, only amplified: Complete hardware control and testability. They might be a little more expensive, and Apple might be dickheads, but they still deliver a better end product to the users.
Maybe in a year or two
I don't have an iPhone, and I don't always have $10 for an iPod Touch upgrade. Furthermore, as of 4.0, feature disparity (read: "even more fragmentation") will begin on this hardware line, starting most prominently with the lack of multitasking on my iPod Touch 1G.
Therefore, your argument is void.
Thank you for playing.
Kid-proof tablet..
The problem is OEMs have no incentive to put money into handsets they sold two years ago.
The OEMs should be profiting from their own app stores .. profits being driven from their customers. That they don't get this yet is hugely disappointing .. appstores - and naturally, software updates - are of huge interest to "next-gen" cell users .. but the carriers just don't want to get into it.
I suppose its because of the draconian US laws about content delivery over telephone networks, in the end, though ..
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Your statement is a red herring.
The features that didn't exist before wouldn't exist today if they wanted to make you happy.
The options are either properly predicting the future and making all future features available in advance, but not letting them work (since they can't yet), or waiting till those features are relevant and adding them to the api.
Either way, unless you want a stagnant platform that never evolves, you're going to have API changes to deal with.
On that note, how come my 1994 Newton MessagePad doesn't understand XML? Yeah.
- Michael T. Babcock (Yes, I blog)
Everything you describe seems to apply to . . . just about every other operating system there is.
One exception is Palm/HP's webOS. New versions of the operating system are pushed over the air to all phones shortly after release by Palm.
Patrick --- Are you detaining me or am I free to go?
That's not the point and you know it. The point is that there is a significant number of phones out there that do not have access to these new features, and in all likelyhood never will. Over half the phones out there are on 1.5 or 1.6.
The point is that the iPhone doesn't have this problem, or at least in any way close to Android, because the vast majority of the handsets are running the latest OS. You really only have to target the latest version. With Android, you can't do that. You either use the really old version, you implement separate code paths for the different versions and handsets, or you tell people using the older stuff (which is still being sold as new) to fuck off.
Again: I don't care. And Cyanogen doesn't run on my phone.
Its exactly the point. If new iphones come out with lets say dual cameras, the new OS and API will support that but the old phones never will.
New features will always cause fragmentation. Your only way out is to stagnate in hardware development or to have perfect forward knowledge.
- Michael T. Babcock (Yes, I blog)
I don't have an iPhone, and I don't always have $10 for an iPod Touch upgrade.
Dude what the fuck? I probably spend $10 in the appstore *a day*.
Ogre Wedding Planners llc.
pretty 3D games on the iPhone are mostly horribly sluggish. Not very impressive. The iPad is better, but not amazingly so.
Woohoo Apple bashing the form of an unsubstantiated anecdote. Weee slashdot!
Ogre Wedding Planners llc.