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."

Comments

What?

[MortenMW]

Disclaimer: I actually read the FA (yes, I know this is slashdot). This guy is angry because, amongst other things, Google has made 40% of his debugging skills useless. Apperantly, his problem is that this means that other people without his "superskills" can develop software for Android.

Re:What?

[davek]

Sounds to me that he's searching for things to have a problem with, and fully admits it. At the very end of the article, he responds to
his own point 7, where he complains about the grammatical heresy of the Android programming concept of "Intents":

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.

If "good debugging" and "poor grammar" are two of the top ten worst points about the platform, then I'd consider it quite a positive article.

Re:What?

[LWATCDR]

Not really.
He hates Java. A lot of people seem to feel that way. I actually like Java more than say c++ because I find the Java object model has a less of a tacked on feel.
The big problem is that he doesn't like the "fragmentation" which is a valid concern for a developer. You have a number of different screen sizes to deal with, you have a number of different cpus that run at differn't speed to deal with you way to many different versions to deal with, and you have what ever custom sillyness that the vendors may put in to deal with.
On thing that is very nice for developers about the iPhone is that it is a very consistant controlled enviroment. It is much more like developing for say a game console than for a PC. That makes hidden gotchas less of an issue.
Android is a lot more like a PC.
So you are half right.
Android makes it way to easy to build simple apps but makes t more difficult to produce top notch professional apps than the iPhone does.
How true that is I don't know since I have yet to dive into the Android SDK but even now I wonder which SDK do I write too? 1.5 which seems to be the most common. 1.6, 2.0, or do I leap to 2.1 and hope everybody updates by the time my app is done?
It is EXTREMELY annoying that there are so many different versions of an OS all of which are shipping on phones right this second!

Re:What?

[Unoti]

He hates Java. A lot of people seem to feel that way. I actually like Java more than say c++ because I find the Java object model has a less of a tacked on feel.

I generally agree with you sentiment. Generally we don't get to take advantage of a lot of that, though. When working on a performance critical app, such as a game, most of the code you're going to write is going to look and feel more like C++ than Java anyway.

Avoiding garbage collection is a key thing that's always top of mind. So you end up pre-allocating all your stuff, thinking about the cycle of memory management constantly. I'm constantly using plain old arrays instead of collections for performance reasons-- every time you iterate through a collection it generates an iterator that needs to be garbage collected. They recommend you shy away from Enums, because each access requires a lookup. They recommend you avoid encapsulation of getters and setters when you can and just access things directly for better performance. They recommend you use parallel arrays instead of composite objects when you can.

I guess the point is that the Java you're coding on Android, for performance critical apps at least, feels a lot more low level, takes more time to write and get right than normal desktop or server Java. Sometimes I feel like I'd rather have that extra bit of performance and be directly in C++ as long as I'm having to deal with so much low level stuff.

Re:What?

[LWATCDR]

For some games I would agree with you 100%. And Android does allow you to use native code for some performance critical parts but as the original author stated then you have to debug in two languages.
I don't hate C++ and I have used it for high performance applications. The thing is that I feel that Java gets too much hate. The "problem" with Java it it is too easy to make a program that works. Because of that you get too many people putting out Java programs that work but don't work well. In C++ they just wouldn't work at all.

I still feel that the real problem with Android is in many ways the openness of it. 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.
 

Unix way

[Nikademus]

"Android, by contrast, pushes you to design everything as small, self-contained mini-applications."

Hey, that's called the Unix way.

Re:Unix way

[dunkelfalke]

But then again, so is Cobol.

Re:Unix way

[lokedhs]

And is still fine for mobile devices almost 40 years later.

Imagine that, a software design decsision that worked. It's almost like the people who designed Unix were smart guys who knew what they were doing. Who would have though it?

Re:Unix way

[HunterD]

Simplicity is hard. Programming the Unix way requires a person to focus on radical simplicity. The benefits are huge. It's a lot easier to debug a 200 line program that takes data in on stdin and dumps it to stdout then it is to debug a class that you can only instantiate with your AbstractFactoryFactory.

The mistake that younger developers make is seeing complexity as hard, and representing mad skillz.

When you have a complex problem that you need to solve, it's /easy/ to make a complex mess with awesome hacks that only you can figure out. It's *hard* to solve that complex problem by building simple programs that even the most junior programmers can easily read, interpret and debug. IMHO, complicated designs are a sign of inexperience, not '1337ness'.

Re:Unix way

[GooberToo]

Simplicity is hard.

We have a winner!

Can't tell you how many times I've run into coders who believe complex = elegance. Or even worse, terse, cryptic coding is elegant.

Simplicity is its own reward - and a bonus for the developer who follows.