Slashdot Mirror
An Android Developer's Top 10 Gripes
gkunene writes in with the plaint of a veteran mobile application developer who vents his frustration with a list of 10 things he loves to hate about Android. "1. Open Source. Leave it to Google to place all the code for their handset platform in the hands of the masses. Not only does this mean anyone can download and roll a new version of their phone firmware, but it also means absolutely any maker can roll its own Android device. ... After all's said and done, I really must admit that Android, despite its relatively few flaws, is one of my favorite platforms to work with. Quite honestly, if my complaint about how the word 'Intent' makes for awkward grammatical constructions ranks in the top 10, I'd say the Android platform is doing pretty well for itself."
... even with these valid gripes I can't imagine developing on any other platform available for the cell phone. The "Intent" is an odd term but the concept it powerful. Java is a pain but it is accessible. Most of the platform complaints deal with the novel programming style Android uses. It's an event based style with an MVC-esque pattern. Very unusual. Perhaps unusual in a good way.
[signature]
He does have one very legitimate concern, and that is that the platform can easily be forked, potentially ending up in a situation like old-style Unix, where each vendor had different incompatible versions of Unix (HPUX, AIX, etc).
That said, most of his other stuff sounded like "You're making it way too easy to use to create applications!"
I am officially gone from
The biggest reason he gives while this is bad is because it destroys then recreates an activity upon rotating the screen. What I've noticed on my droid is that application refresh the screen when the screen is rotated. To get around the refreshing, developers have to hack around google's API.
1. SDK only available for Mac.
Support Right To Repair Legislation.
My single Android complaint: Why, oh why must it be Java based?
1) Sandboxing in Android actually happens at the Linux process level. Every app run its in own isolated process, with its own instance of the Java VM. You can remove the VM form the picture and it would be just as safe.
2) You cannot build once run everywhere. Its a myth. With J2ME phones, devs test and optimize for every supported handset, and it will be the same for Android.
3) Java *IS* an order of magnitude slower than C/ASM for many things that are important for games, such as matrix math. Google knows this and is trying to work around it with JNI/NDK, but really why the complication?
I guess its too late now, but it makes me very, very sad.
(And makes Apple very, very happy)
Despite your undying love of google forcing you to accept everything from them (i'm liberally assuming here), there some legitimately complaints.
Heh, not really. There are a lot of things I think suck the Android, mostly with various standard applications. For example: no proper file browser in the music player; crappy email client which can't handle larger mail directories; no "update all" for through the market; unreliable bluetooth support (although, it could be just my phone); no vector based user interface (specially an issue now that other resolutions are starting to appear); etc.
The ammount of mini apps running around go directly against the idea that's been creeping around of making applications run on less files, like Mac application structure, or so i've heard, does, while the running applications it's a very valid point.
That's not per se an issue with Android but with application writers. Your application shouldn't start a service when it doesn't need to (looking at you "Astrid", I don't have any reminders). An application should do what it was requested to do and then stop. But other applications need to remain active in the background, like my SSH client
This isn't exactly true. Apps only get to use 16 megs of memory on Android. Sounds like a lot, but it's not, especially if you're working with 2d graphics. That's actually something that's causing a lot of difficulty for me in game development on Android. A 1000x800 image is 3.2 megs by itself (1000 x 800 x 4 bytes per pixel). Put a couple of sprite sheets into memory for animation and you're rubbing elbows with the limits.
The point from the article about apps being unconstrained and able to ruin each other isn't really true, at least not for memory. Perhaps the problem the author cites is more of a problem on Android platforms with only 64megs of memory to work with in total. On my Droid, I am saddened by the opposite problem: only being able to use a small portion of my device's memory.
I wish that Google would get EVERYBODY on the same version. I am tired of waiting for Samsung to update my phone to 2.0 or 2.1. It is just silly that Motorola released two phones in the same time frame and one has 1.5 and one has 2.0! or that Verizon released two Android phones on the same day and one had 1.5 and one has 2.0. Or that T-Mobile has phones with 1.5, 1.6 and now 2.1!
This fragmentation on such a new platform is just insane.
That's the whole point of http://google.com/phone
Google has realized that the fragmentation has been killing development. Combine that with UI changes and it can be a nightmare for developers.
However I'm of the opinion that you should only develop for stock Android of a given release. I just want to slap people who post stupid fucking comments on the app store that "X" doesn't work with Cyanogen mod Foo. The risk of running unsupported firmware is that it doesn't work. You knew that going into it. Why should people cowtow to you?
The point is that the HOPEFULLY with the google store for Android powered phones, they can drive the market to stick as close to stock Android as possible. I would hope that Sense UI and Motoblur devices would be kept off the official Google store or at least come with a disclaimer that this is a customization and that not all apps will work with it.
Additionally, Google needs to implement some sort of automated app scanner that determines if the app is making 1.6,2.0 or 2.1 compliant system calls and version the apps presented in the store to each device as supporting that release.
I have no idea what to do about the screen issue though but I think it's going to come down to two differentiators - Android Powered (Sense UI, Motoblur, whatever Sony is calling their version) and Android Experience (stock - DROID and Nexus 2). Maybe "Android Experience" dictates a fixed screensize or some basic level of specification.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"