Android is a Terrible Platform
If you’ve come here today looking for the next release of ExEn, I’m afraid I’ve failed you and it’s going to be late (again… sorry).
I’m going to go ahead and blame Android for this. It is a truly horrible platform. The emulator sucks and is essentially unusable for game development. The Android APIs are simplistic, badly designed, and reminiscent of programming in plain ol’ C.
But worst of all are the device-specific bugs, where I have no idea if I can even use any given API as-documented, and what obscure work-arounds I have to employ, because I keep finding cases where apparantly it will cause the app or even the operating system (!) to crash or hang on certain phones. [*]
Neither Windows Phone 7 or iOS have these problems.
And just to be extra controversial for any fan-boys watching: the Android UI and overall experience is a clunky and pale imitation of Apple’s.
Android is a terrible platform and I’d dearly love to see it go and die in a fire.
But, because I’m such a good person, I’m going to continue to persevere with it and get a release out to you soon. The good news is that I’ve got a reasonable idea of how to do what is still left to be done (bunch of OpenGL context management stuff), in such a way that it should mostly insulate you from Android stupidities. So stay tuned.
If you’d like to keep hearing me rant about how bad the Android situation is, subscribe to my Twitter. I’ll no doubt be venting there while I get this done.
[*] A few examples:
- Read Replica Island’s GLSurfaceView.java comments (search for “Qualcomm”)
- Which I’d like to use as it partially mitigates this issue
- Crap like this and this – just Google for “soundpool crash“
| Twitter
Comments
miblon
I cannot agree from a mathematical perspective. “Android is a terrible platform” should be: “I think android is a terrible platform”
Sean Fausett
Hang in there. Does bumping the minimum platform version help? http://developer.android.com/resources/dashboard/platform-versions.html
Andrew Russell
@Sean: I have considered this. Unfortunately it’s very hard to track down the version numbers associated with many of these ridiculous device-specific bugs.
Some of the API silliness is improved in later versions. But in most cases I was looking at either 2.3 or 3.0 for a fix. Going by usage, I wouldn’t really want a minimum above 2.1. At the moment I’m building against 1.6.
JC
There is no way I would build against 1.6.
2.1 should absolutely be your minimum.
You should sacrifice device(s) incapable of running 2.1.
I wouldn’t jump to 2.3 being the minimum because you’re killing the developers who want their games on Verizon devices here in the US.
Anyway, my perspective looking at the biggest mobile carrier in the US and knowing what version seems to have the most marketshare is to have 2.1 be the minimum.
My general opinion is the faster you can get both ports out there with the correct open source license(s) the faster you can have other developers contribute to the project. There is only so much you are going to be able to handle on your own.
Since it seems you received less than half of what you were asking for an OS X port: I would do half the work needed to get a port going and rely on other developers willing to contribute to that port as well.
I think for the most part a lot of people would like to see this project out of the shadows and on a proper site.
Knoxcoder
I feel your pain. I’m working on an app widget and the problems and stupid overlooked things fills me with rage. As a software architect I personally would fire the android team for putting out a product of this low caliber. As much as I like the open idea behind it I secretly hope wp7 gets bigger so I can move to a better platform.
Johan
I am new to the Android platform, having programmed in Symbian before – no matter how horrible Android is, it is a billion times better than Symbian. What worries me is that Android platform was designed close-minded. I don’t see that much of the stuff will be around in 15 years time – because everything was build around how the user interface works today. I don’t see it surviving a paradigm shift (Davlik + Linux kernel maybe, but not the Android java API’s).
Parrotlover77
You lost me when you said mentioned WP7 does not have these problems. Considering WP7 runs C# and XNA natively, that’s not entirely too surprising. Do you know what Android does better than WP7? Everything else. While whining about legitimate bugs is always good blog fodder and apparently CodeProject thought this was a good fun “controversial” blog post to run, your argument is completely moot if your problem is running Android 1.6! If Android bugs are fixed in later versions, but you don’t develop for those versions, you are your own worst enemy. Android 2.1 is a good minimum now. By the time anybody cares about your project, Android 2.3 will surely be a good enough minimum. So go with the version with fixed bugs. The more products that use newer Android versions, the less “splintering” anybody has to worry about. (Another favorite Android slamming blog post topic.)
EC
I’ve done a bit of development on Android, and I found even connecting to WiFi networks programmatically to be an absolute pain. That said, I have the Samsung Galaxy S2 and an iPod touch 4G, and in my experience, in terms of app stability, Android beats the pants off iOS. Facebook, Skype, whoever, all are unreliable pieces of crap on iOS.
It should also be stated, that whatever about developing your app, getting it published on iOS is a nightmare. You’re subject to a prolonged and fairly arbitrary approval process, and many great apps like Swype have no iOS equivalent because Apple won’t let you override stock OS functionality like the keyboard.
Sailing_Nut
Not that this helps anything….
But, it reminds me of way back in the day of people raging against how horrible the Windows APIs were. It gained momentum and people just sucked it up and eventually things got better.
Hoping it goes this way with Android. (But a faster “it got better!”)
kdarty
I’d have to agree with the others. You should NOT be coding for anything below 2.1. That is just crazy. People using phones that still run 1.6 or below should not be your audience. They don’t even know they are running Android because if they did, they would get a new phone with a newer version of Android on it (I say new phone because it is highly doubtful their phone can even update). Developing Apps to be compatible with 1.5/1.6 is a huge pain and not worth your time. Check Google’s stats. You would actually be safe going with 2.2 but just to be nice to the Galaxy S crowd, sticking with 2.1 would be fair. Good luck and don’t give up.
ScottM
I haven’t developed in Android, so I don’t know the specifics. But it sounds to me like Android’s problem is its openness and the fact that carriers tinker with it for their devices. Apple, otoh, loves closed systems. Closed systems are very predictable…and extremely limiting.
Camden
I’m gonna have to agree with JC on this one. Any device that’s incapable of running at least 2.1 is not worthy of being developed for. And instead of testing on the emulator, you should just consider testing on an actual device. It takes less time in the long-run.
Also, from my recent experience with wp7, I can’t agree that the platform does not have those problems. I’ve never seen a platform so locked up south of an apple product. To me, it seems like your blaming your woes on a faulty tools and devices, rather than the platform itself. In which case, there are definitely workarounds. Hang in there.
frank
Is it a case of bad workman blaming his tools? 🙂
Abdul Samad
Well, iphone has a long past as compared to android, android is yet to go through long way to remove all the bugs mentioned here in all these comments, BUT, making JAVA as development language for android gives programmers access to develop stop apps in less time as compared to object C,
Daf
As anyone who has had to dev for any other platform (windows, linux, mac) will tell you: with a diversity of platform versions, you’re going to have a mission supporting them all). Take the advice and choose a reasonable base like 2.1. anyone who has tried to target win9x and the NT family will tell you to forget the old horse. Android’s release cycle had just been faster, but you need to realise that a really good platform dev team knows when to give up on old api and behaviour. Windows began to suck a lot less when microsoft gave up on the 9x/me line. MacOS started to suck a lot less when apple gave up on their own shitty kernel and low-level stuff and just went with bsd. Just pick a base version which works for you and stop whining. Or produce multiple versions if you’re that ocd about it and just can’t let the old clients die in peace. Also bear in mind that the average service life of a phone is about 2 years and 2.1 had been around for at least 1, do you really don’t have much to lose. Spend less time complaining and more time targeting platforms that actually work for you, like 2.1+
Jorge
I kind of agree with you, after some androids shoots … i did start hating it (just like Blackberry development) and did migrate to Apple and start developing IOS Apps … so far it is the best framework i had ever work with
Tarun Juneja
I also wanted to do the development for the android but after looking at the completely unstructured API i rejected the idea and decided to work with WP7 and Apple.
No doubt it is a horrible platform with terrible API.
Raphel
@miblon That’s not a mathematical perspective. Also, it’s quite unnecessary to include “I think”, “I feel”, “In my opinion” constructs. Even if a child couldn’t recognize it as an opinion piece, there are facts given and comparison to other, relative OSes that are concrete enough to contraindicate the need for such.
LB
I agree with the other poster. Using Android 1.6 as your minimum OS level is like writing code to be compatible with Windows 3.1. If you look at the current OS distribution:
http://developer.android.com/resources/dashboard/platform-versions.html
OS version 1.6 represents 2.2% of users. It really makes no sense to use anything less than 2.1 and even going to 2.2 (if you need the NDK improvements) would not lose you a large % of the installed base.
As far as the poor device emulator…on pretty much any platform, using an emulator to test game programs is a losing proposition. If you can’t afford to spend $100 on a used test device, then maybe you should choose another profession.
Andrew Russell
So it seems that CodeProject posted my little rant without any context (and at the same time my comment notifications stopped working). So allow me to respond:
First off, in case you missed it: ExEn is a developer tool. There’s nothing in the 2.1 API that I need (yet), so there’s no reason for me to move off 1.6. At least that’s the case if everything worked as documented. Maybe moving to 2.1 would fix some of the device-specific bugs – but I have no way to determine that! If developers using ExEn want to set a higher minimum API level before publishing, then they can easily do so.
It’s worth pointing out that moving to 2.1 would not solve the main issue that is delaying the release of ExEn for Android.
Just because I complained about the emulator doesn’t mean that I don’t have a device. If I didn’t have one, I’d not get anything done. Out of WP7, iOS and Android, Android is the only one where the emulator can’t handle even slightly complicated 3D graphics work. Also it’s so much slower. (It is the only one to run a full system emulation – which sounds like a good idea, but sucks in practice – particularly when the graphics driver/device is incomplete.)
What I don’t have is access to multiple different Android devices. So if there are device specific bugs lurking – which research indicates that there are – I’ve got no way to test for them.
@frank: I can definitively say that it’s not a case of a “bad workman blaming his tools”. I can say this because I made ExEn for iOS with significantly fewer issues than I’m having on Android.
@Abdul: Seeing as ExEn is written in C# on all platforms, your point is moot. In fact, I suspect that some of the poor API choices on Android are because the API was designed for Java.
@Raphel: Someone gets it 🙂
JC
Andrew is your Android device running 1.6?
Android is not iOS it is fractured across an extreme number of devices:
http://en.wikipedia.org/wiki/Comparison_of_Android_devices
Therefore all the targets you set for iOS become infinitely harder to maintain in Android – because of your inability to run any real world tets that have merit.
Whether you hate Android or not is a moot point there is no way to do device specific testing – for the myriad of Android devices – unless you let others contribute.
The iOS port is for all intents and purposes done. You didn’t meet your funding target for the OS X port and the reason for that I believe is the lack of transparency here.
There just doesn’t seem to be any reason to me why you would not have a proper site for ExEn by now and the releases up on SourceForge or GitHub open to the general public.
The goal was the have an open source project in the end so why are you not allowing for the natural progression of what already works – iOS – to flow into garnering some help for Android?
I don’t mean to sound snide my man, but you’re one guy and you really need a team of people who have different Android devices to contribute to releases. You cannot properly weed out bugs any other way.
I appreciate what you are doing. I appreciate the progress and results the iOS release has already brought forward, but unless you get a real point release out there, with a license that allows others to contribute, this is going to go nowhere fast.
There is nothing wrong with being a project leader and relinquishing some control…
Andrew Russell
@JC: The plan is still to move to a more traditional open source provider as soon as the Android port is done. I’m just extremely wary of releasing something with a dirty great crash bug in it.
At this stage I’ve pretty much resigned myself to coding to the documentation and assuming the platform is bug-free. Then any device-specific bugs will simply percolate through ExEn.
This sucks. Especially because ExEn is specifically supposed to insulate you from the platform. But you’re quite right when you say that I don’t have the resources to deal with these issues myself. Doesn’t mean I can’t have a good rant about them, though 😉
Unfortunately it’s not a question of immediately writing off some devices that are broken and delivering ExEn for Android. Currently ExEn has a crash bug on all devices. It’s more of a question of whether the fix will be A: “nasty”, B: “good on most devices”, or C: “good on all devices”. And now I’m downgrading my target from C to B. There are still silly Android issues to wade through – but they’re not as insane as attempting to work around issues on specific devices that I can’t test on.
JC
Pray Ballmer gets fired and someone who knows how to run a software company gets hired soon. This way WP will go somewhere and Android will die. 😉
As an iOS developer I have no issues saying I like Windows Phone 7. I like iOS better, but I like WP7 all the same.
Gabor
I completely agree and support Andrew’s commitment to quality. There is no sense to release something what is ‘partly’ usable. If your foundation frameworks are not rock solid, your app will inherit this behavior, and users will drop it… No one wants this ending.
About going opensource ASAP and let others to contribute… I think the main difference should be Exen and other projects that Exen is _usable_. What is not rock solid that’s not qualified as usable if you look app releasing and development as _industry_ activity.
Also I have to say I see a real issue here which practically prevents enabling community contributions: the lack of unit tests: No way to check the effect and impact any changes, and no methodical way to measure the quality of the contributed code…
So I think the best one can do: Accept and support Andrew’s commitment and accept the fact: currently there is no alternative that Andrew achieves his goal.