In using OpenGL he is basically giving up all the features Android offers him to stay platform independent.
I think it is clear, when you write a whole, complete rendering engine that doesn't use the android stack, you'll eventually have to deal with different screensizes, input methods, etc.
Most apps i use have been running on my G1 from day 1 and now on Android 2.2 on the Nexus One and i've had no big problems between android 1.5, 1.6, 2.1 and 2.2.
I guess the only thing for games to remain relatively platform independent is to use another intermediate layer (to substitute for a not used android "layer") like the unity3d engine.
While his specific examples were about the OpenGL implementation(s), the spirit of his post rings true in other Android subsystems, as well.
For example, camera support can differ greatly across SDK versions and hardware. Camera callbacks need to be implemented conditionally based on whether autofocus is available and selected. EXIF orientation data isn't reliably recorded on some devices, and the EXIF interface class isn't available in older SDK versions. Lastly, your application will crash if you attempt to take or preview a photo using unsupported dimensions, but the function to query the list of supported dimensions isn't available on older SDKs.
I've also have some experience in J2ME/ Symbian development. Reading this guys story made me cringe, it brought back some bad memories.
My feeling is that it seems minor now; but it should be focused on. You can't let something like this slide for too long before you've got a piece of junk.
While I agree (fragmentation on J2ME is hell), that's kind of a weak argument. If things are worse in place A, that's not an argument things could also improve in place B. Certainly if one is a lot newer, and supposedly better.
Is there really a way to make OpenGL development simple and consistent across a wide range of GPUs and screens? It sounds to me like he's complaining more about how hard low-level cross-platform graphics programming is, not Android itself.
It would be interesting to hear the comments other developers who had written an app that used stock UI components and didn't do anything too crazy. Games aside, a large percentage of the other apps on the marketplace do relatively sane things with common components.
I developed a very simple app (BenPaper); it runs fine on 1.5, all the way up to 2.2. It handles things like device rotation without me writing any code to deal with that because all the layouts are liquid etc. etc. Admittedly it's a very simple app, but on the whole I was impressed with the defragmentedness of the platform.
Compare that to writing a J2ME app, where you have to use a build tool like Polish to build 18 different binaries, run 6 different emulators on your development machine, keep an up to date list of devices and their hardware characteristics...
Provide one screen resolution. Change that resolution infrequently. Provide only high level access to the graphics capabilities of your platform regardless of how much the underlying hardware changes. Do not permit developer access to private APIs. Hmm, sounds familiar...
There is a way to make development simple and consistent across a wide range of devices and it's called Flash. A platform that, last I checked, Google was going out of their way to integrate.
(Which is why it's funny that the author of the post points to .NET without mentioning Flash in his article)
The problem with this approach is that performance goes down the toilet (which is exactly what you see with Flash on mobile devices now). So what Google's doing is offering developers and device manufacturers a chance to write to the device itself through OpenGL.
Everything has disadvantages, openness included. The author seems to want it both ways (open platform with Apple like hardware consistency)
It would be useful to have an API that'll provide device optimal settings given a set of minimum requirements. It wouldn't help with the bug based problems, of course, but it's a start.
Android is still in its infancy. Like all Google products, the early users are the beta testers. 1.5 and 1.6 were technology previews that were mistakenly marketed as phones you could actually use. (I have a 1.6 phone, the Sapphire. It works, but it isn't great. The hardware is low-end shit, and the software tries to make that less noticeable, but the goal of these Android devices was a price point, not a good user experience. And users can tell.)
Like many others, I'm not surprised by this post: of course devices will have different graphical capabilities and developers will need to take them into account for decent performance.
These complaints scream out for a framework/engine builder to come in and provide a uniform interface to the graphical capabilities of the many different Android devices.
Yes, but it's good that this is highlighted when Google is touting that 100K Android handsets is activated every day. It means that for App/Game developers, your can target a lot less than total number of activate (let alone shipped) devices.
Nokia/Symbian has used total number of shipped devices as an argument for their platform, but every Symbian dev knows that it is totally meaningless number. For example targeting S60 2nd edition devices is out of question, but Nokia/Symbian is still calculating 2nd ed. devices in their numbers. I once blogged about this and mobile stats in general: http://dirtyaura.org/blog/2009/01/05/worldwide-mobile-intern...
Detailed info about fragmentation issues is really useful for me and I assume that other mobile devs & companies too
for estimating when and how to develop to different platforms.
While I think the guy has valid complaints I HATE the way that developers abuse the word "trivial". Trivial does not mean "possible" it means ridiculously brain-dead easy and requiring no effort whatsoever. Hello World is trivial, not abstracting part of the platform to be redistributable. Bloody hell.
I feel the dev's complaint was more nuanced than complaining about fragmentation.
The dev was saying there were tons of easy back-ports left on the table that could make the fragmentation much easier for developers to deal with. I walked away feeling that some released Android versions were neglected, more than fragmented.
[edited last sentence to distinguish neglected versions from not caring about the whole platform, which Google obviously does.]
Yes, if this trend continues Apple will fragment iPhone OS devices once every 3 years. Awful when you consider that Android is fragmenting every month with the introduction of yet another device.
Verizon is selling 1.5 and 1.6 devices right now - that's how they're segmenting their product line. AT&T and Apple haven't sold an iPhone 2G in years.
In addition to OpenGL differences (which given how much the graphics hardware in these devices differs should probably be expected), 2.2 is going to be a really big compatibility break. 2.2 is the first OS version who's JVM (Dalvik) has a JIT compiler. The Android team is down-playing the performance gain, but benchmarks have shown that 2.1 Dalvik's performance is terrible and if the new Dalvik is even remotely competitive with other JIT-ing JVM's now, Android 2.1 and earlier are going to seem CPU-starved compared to Android going forward from 2.2.
That's a good thing, if you can count on most (many?) handsets being upgraded to 2.2. That's unlikely, though.
I have been using JIT on my ADP1 with 2.1, and it hasn't broken anything. Performance is great, 3.5mflops in linpack vs 2.4mflops. But I am confused, why do you think there is a compatibility break?
Nah, in October 2010 the first G1 owners' two-year contracts will start ending and they'll get offers for cheap or free upgrades to newer phones. Within a year or two this will happen to most people who bought a first- or second-generation Android device.
At least in the US, the carriers' subscription and hardware subsidy model will guarantee steady turnover in smartphones.
Or just don't support it. Most phones running 1.5 are underpowered, and if users haven't upgraded they probably don't care about being on the cutting edge and aren't buying many apps. I'd expect that the effort isn't worth it unless you have huge sales volume.
There is nothing preventing people from abandoning Android 1.5. Contracts run up and people are thrown fancy new phones for free. Nobody has built mission-critical business apps around Android 1.5, as some big businesses have ActiveX/IE6.
Android 1.5 will simply be discarded. It's already closer to that than IE6 is!
On first reading, I couldn't see any problems mentioned that couldn't be addressed with a Factory pattern. Android game /graphics devs could band together and maintain a framework. iPhone devs would have licensing issues with such a project.
Stop spreading FUD. iPhone devs would not have licensing issues. How about I point you to a number of frameworks that iPhone developers ship with today and have been shipping with since near day one.
[+] [-] buster|16 years ago|reply
Most apps i use have been running on my G1 from day 1 and now on Android 2.2 on the Nexus One and i've had no big problems between android 1.5, 1.6, 2.1 and 2.2.
I guess the only thing for games to remain relatively platform independent is to use another intermediate layer (to substitute for a not used android "layer") like the unity3d engine.
[+] [-] wvenable|16 years ago|reply
OpenGL itself exists to offer platform independence.
[+] [-] jparise|16 years ago|reply
For example, camera support can differ greatly across SDK versions and hardware. Camera callbacks need to be implemented conditionally based on whether autofocus is available and selected. EXIF orientation data isn't reliably recorded on some devices, and the EXIF interface class isn't available in older SDK versions. Lastly, your application will crash if you attempt to take or preview a photo using unsupported dimensions, but the function to query the list of supported dimensions isn't available on older SDKs.
[+] [-] briansmith|16 years ago|reply
[+] [-] waterlesscloud|16 years ago|reply
But the market was also much bigger. And software sold for higher prices.
Android market is too small and prices too low for the platform to be so fragmented.
[+] [-] pistoriusp|16 years ago|reply
My feeling is that it seems minor now; but it should be focused on. You can't let something like this slide for too long before you've got a piece of junk.
[+] [-] barredo|16 years ago|reply
[+] [-] PanMan|16 years ago|reply
[+] [-] eli|16 years ago|reply
[+] [-] dieterrams|16 years ago|reply
[+] [-] DrSprout|16 years ago|reply
[+] [-] dabeeeenster|16 years ago|reply
I developed a very simple app (BenPaper); it runs fine on 1.5, all the way up to 2.2. It handles things like device rotation without me writing any code to deal with that because all the layouts are liquid etc. etc. Admittedly it's a very simple app, but on the whole I was impressed with the defragmentedness of the platform.
Compare that to writing a J2ME app, where you have to use a build tool like Polish to build 18 different binaries, run 6 different emulators on your development machine, keep an up to date list of devices and their hardware characteristics...
[+] [-] swannodette|16 years ago|reply
[+] [-] SamAtt|16 years ago|reply
(Which is why it's funny that the author of the post points to .NET without mentioning Flash in his article)
The problem with this approach is that performance goes down the toilet (which is exactly what you see with Flash on mobile devices now). So what Google's doing is offering developers and device manufacturers a chance to write to the device itself through OpenGL.
Everything has disadvantages, openness included. The author seems to want it both ways (open platform with Apple like hardware consistency)
[+] [-] m_eiman|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
I would just target my apps to 2.0+.
[+] [-] blocke|16 years ago|reply
Target either 1.6 or 2.1 based on what APIs you need. 1.6 apps will work with all later releases just fine if you don't need a 2.1+ specific API.
[+] [-] chwahoo|16 years ago|reply
These complaints scream out for a framework/engine builder to come in and provide a uniform interface to the graphical capabilities of the many different Android devices.
[+] [-] dirtyaura|16 years ago|reply
Nokia/Symbian has used total number of shipped devices as an argument for their platform, but every Symbian dev knows that it is totally meaningless number. For example targeting S60 2nd edition devices is out of question, but Nokia/Symbian is still calculating 2nd ed. devices in their numbers. I once blogged about this and mobile stats in general: http://dirtyaura.org/blog/2009/01/05/worldwide-mobile-intern...
Detailed info about fragmentation issues is really useful for me and I assume that other mobile devs & companies too for estimating when and how to develop to different platforms.
[+] [-] weeksie|16 years ago|reply
[+] [-] lapusta|16 years ago|reply
[+] [-] thesethings|16 years ago|reply
I feel the dev's complaint was more nuanced than complaining about fragmentation.
The dev was saying there were tons of easy back-ports left on the table that could make the fragmentation much easier for developers to deal with. I walked away feeling that some released Android versions were neglected, more than fragmented.
[edited last sentence to distinguish neglected versions from not caring about the whole platform, which Google obviously does.]
[+] [-] swannodette|16 years ago|reply
[+] [-] CountSessine|16 years ago|reply
[+] [-] CountSessine|16 years ago|reply
That's a good thing, if you can count on most (many?) handsets being upgraded to 2.2. That's unlikely, though.
[+] [-] alphamerik|16 years ago|reply
[+] [-] blocke|16 years ago|reply
[+] [-] ck2|16 years ago|reply
You'll have to code workarounds for it for years.
[+] [-] mbrubeck|16 years ago|reply
At least in the US, the carriers' subscription and hardware subsidy model will guarantee steady turnover in smartphones.
[+] [-] orangecat|16 years ago|reply
[+] [-] Legion|16 years ago|reply
There is nothing preventing people from abandoning Android 1.5. Contracts run up and people are thrown fancy new phones for free. Nobody has built mission-critical business apps around Android 1.5, as some big businesses have ActiveX/IE6.
Android 1.5 will simply be discarded. It's already closer to that than IE6 is!
[+] [-] stcredzero|16 years ago|reply
[+] [-] pkaler|16 years ago|reply
[+] [-] dieterrams|16 years ago|reply