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?

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

Re:What?

[uberjack]

He does have some valid complaints though, specifically #6 (so _why_ can't I write an entire app in C?), #3 (Android's management of running apps is still a mystery to me), #8 (I've received complaints that my app's icons look low-res on Droid, and not having one, there's not much I can do short of buying a new phone for testing) and partly #5. With regard to #5, however, you can easily weed out poorly written applications within a day's use of them - for example, I uninstalled Google Listen after two days of use, as I noticed that it cut my battery life by 50%. I don't agree with him that Android needs to follow the same design paradigm as other platforms, but I may be biased, as I never developed for any other mobile platform. As odd as Intents and Activities seem, the end result is not a bad one at all, and is even fairly intuitive in many ways (my favorite analogy is Intent==POST request and Activity==web page).

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

[dunkelfalke]

I've grown up a bit since then and had to develop for Linux not as a hobby but for money. Nowadays I prefer less work and more comfort to be honest.
Unfortunately honesty gets a -1 Troll here nowadays.

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.

Re:Unix way

[Unoti]

It's true. It's also easier to develop in Visual Studio .NET for the Compact Framework than it is for either the Android or the iPhone. Windows Mobile was early to market, and a great development environment for handheld devices for things like warehouses and similar applications.

But Windows Mobile is also getting smoked, for whatever reasons, and the app stores are at least part of that story. A user experience that's not optimized for fingers is probably another. WordStar dominated the word processing market for a while, but was overtaken and is now a distant memory. That's where Windows Mobile is headed.

Re:Unix way

[sarhjinian]

But Windows Mobile is also getting smoked, for whatever reasons

It's getting smoked because, outside of the very specialized vertical-market stuff made by the likes of Intermec or Symbol (for warehouses, losgistics, medicine, etc, as you noted), the devices suck. Oh, sure, the hardware isn't too bad, but the user experience is generally wretched.

Android is actually making similar errors. TFA is right to note the fragmentation of the platform: unlike the iPhone (or, to a lesser degree, Symbian and Blackberry), you're having to deal with any number of permutations of screen, OS, installed applications, store restrictions, etc. Android has the benefit (over WM) of not being completely horrible to use, but it's still nowhere near as unified as the iPhone. It's pretty good, but when you can't even guarantee that email will work the same way on every device (let alone how different handset makers are bundling their own UIs), you've got problems.

And no, this isn't going to be a repeat of the "Mac vs. PC" wars of two decades ago, if for no other reason than customers today aren't as likely to be enthusiasts, and aren't going to put up with the inconsistent experience these devices provide. If Apple (and RIM, again to a lesser degree) has taught us anything, it's that interface polish matters int he consumer market: you can't shove half-baked technology at people and expect it to go well. You'd think Google would have noticed the bitch of a time Nokia is having because they're terminally incapable of making email work as well as RIM, or the pistolwhipping the iPhone is giving Windows Mobile. Near as I can figure out, it's because Apple and RIM a) recognizes it's customers are the people who buy the phones and b) set their priorities by what users need, rather than their developers preconceived notions.

Disclaimer: I actually use a Nokia E71 and really like it otherwise, but I can't believe a company like Nokia would be so foolish as to sell a business phone with such pitiful messaging features. Similarly, I can't believe a company like Google, which has made it's name offering a clean and consistent web presence would so badly fragment the experience on it's handheld.

Re:Unix way

[Qzukk]

Linux distros could solve a lot of the dependency problems by simply allowing multiple versions of the same package to be installed side-by-side

Sort of like how debian can install libgtk1.2 and libgtk2? This has been around for quite a while.

There are two problems here:
Developers use cutting edge libraries that are released before the distributions release new versions (like using libqt 4.6 when debian has 4.4), and that people don't want to bother with the package system (which would Just Work when you use libraries supported by the distribution).

dumb article/crappy developer

[El_Muerte_TDS]

Point 1. Open Source
As the submitter also pointed out. I don't see any problem with the Apache Software License 2.0 licensed Open Source code of Android. How is that a developer gripe? APL2 allows you to close whatever you want to keep closed.

Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF.

Actually, that's quite simple. It's ok when Google (the copyright holder) says it's ok, otherwise it's not.

Point 2. The Tyranny of the Activity

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

That sounds a bit like the old UNIX principle. And what's wrong with having applications that do small things and do it well. I don't want a picture application with it's own twitter functionality, I have a proper twitter client for that. etc.

Point 3. Device Debugging

Why do I hate this extremely useful tool? I hate it because it makes about 40% of my debugging skills nearly useless!

Ok.. so... this article is an humor piece instead of a real article/rant? Or is the writer simply a moron?

Point 4. Applications Never, Ever Quit

but your icon stays in the list of running tasks

Maybe this is a new feature in Android 2.x. But the list of applications you get when holding down the home button is not "running applications" but simply a list of recently started applications. When I leave an application and it has no active processes then it won't show up in the process list. So, I'm quite sure it's not running.

Point 5. The Developer Cooperative
Yes, it would be very nice if the end-user could define system resource limits for individual applications. But other than that, I don't want artificial limitations enforced by the OS by default. Some application simply need more resources than others. If an application is crap, I will uninstall it. Just like I do on my normal PCs.

You know what... I'm not even interesting in the other 5 points on the second page.

Re:dumb article/crappy developer

[FlyingBishop]

Point 4. Applications Never, Ever Quit

Actually, this is a developer sin. Pandora does in fact have a functioning quit button (alone among all the apps I have tested. And there are a variety of task killers. The lack of a built-in task killer is a really stupid design flaw in Android, but applications can quit.

Re:dumb article/crappy developer

[GooberToo]

Granted, it doesn't chew battery, but it's a cleanness thing. They should be playing by the rules.

They absolutely ARE playing by the rules. You just don't know/understand the rules.

Most android apps don't, even Google-provided software. The Exchange calendar client continuously starts up even though I don't have a calendar configured.

Unused applications are services are terminated by the system. Unused memory is a waste. The Android framework is in charge of all application and service life cycles.

Really the only problem is that many developers are abusing services when they should be requesting the service be terminated. Or worse, they are starting the service as a persistent service rather than an on-demand service. Both of which are application bugs. Regardless of the bug, the framework still manages the service lifecycle, which is why these abusive developers don't fix their bugs.

Re:dumb article/crappy developer

[entrigant]

This is nonsense and verging on asinine. I don't mean that as a personal insult as you did mention this is in google's guidelines, but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.

Not only are there issues of badly behaving apps draining battery when not terminated, but there are issues of apps with persistent roles such as internet radio, remote terminals, download managers, badly behaving websites with non-interruptible multi page operations, etc.

When I'm involved in a complex work flow I know what needs to remain up and what can be terminated to free up resources. Some magic voodoo app manager does not.

Asking for an extra menu entry to quit an application is not too much to ask. The few lines of code it'd require would fit in the tail end of an unfilled memory page. Don't give me any nonsense about compounding memory pressure. If I hit back or home fine, stay up. If I hit menu > quit then by all means terminate.

There's a reason task managers are among the most popular android applications. In a perfect world with perfect 3rd party apps the magic voodoo app manager might work, and I do appreciate its idealistic goal. The fact of the matter is it doesn't work that well.

Re:dumb article/crappy developer

[entrigant]

This statement is contrary to almost every facet of modern computing.

How so? Do you have examples? While the idea is by no means novel, it is certainly not popular. Nearly every popular general purpose OS leaves application management to the user. In the mobile space some solve it by simply not allowing multitasking to take place avoiding the problem altogether. Resource management via leaving everything on and relying an applications themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."

There are only two or three ways to immediately terminate an Android application and none are recommended. Some provide negative feedback to the user, further annoying them.

Yet some of the more reasonably behaved ones managed it. As a previous poster mentioned pandora is one such app, the *oid series of emulators all have a perfectly functioning quite option.

When Android decides it needs more memory it will terminate applications as it sees fit. That's the end of it, no matter how much you want to complain.

Indeed, and being forced into this should carry the same stigma as the linux oom process killer. If it goes that far something has gone wrong.

veteran mobile application developer ?

[ardiri]

>> how long does it take to be a "veteran mobile application developer?"

checking out his profile (http://www.linkedin.com/pub/chris-haseman/1/369/a32) he has barely touched the majority of mobile platforms :) where is his symbian, palm os (68k, arm), ebookman, embedded linux, psp, nintendo ds, experience? surely - some of us started this stuff professionally back in the late 1990's with devices like the newton and palm professional. boy how things have changed - yet some things stay the same. he announces himself that ""(and by "in my day," I mean two years ago)"".

>> 3. Device Debugging

be thankful - some platforms you still need to do printf() style debugging.

>> 6. Java—Thanks, But I'll Take It from Here

Java - probably the worst language used on mobile devices to date. the desktop and server platform has evolved in many ways which are not being reflected in the mobile space; due to battery life, talk time etc - the typical moore's law of computing doesn't apply to mobile phones. there was a period where CPU speeds dropped on mobile devices - hopefully things will change coming up with new ARM and low powered x86 CPU's - but time will tell.

A true mobile developer demands a native C/C++ interface on mobile devices - if you want something done, more than a bouncing ball on the screen - its the preferred way. NDK under Android is a must - C/C++ isn't that bad - if you know what you are doing.

>> 8. Platform Fragmentation

its a problem? come on - seriously. you deal with it. you design around it; thats where your years of experience really kicks in and allows you to build cross-platform applications without issues. just because most companies hire an outsourcing department or "specialists" on specific platforms isn't a problem - it is a choice. there are plenty of alternatives out there.

He's right and he's wrong

[amoeba1911]

This guys is right in some places, wrong in some others. Changing screen orientation restarts the Activity, but you can tell it in your manifest that you don't want it to automatically restart the Activity on orientation change, giving you the control to do whatever you want.

Android forces you to make the application centered around the Activities, but it's not so bad when you get used to it. It's not necessarily bad, just a bit different.

The debugging? He's definitely being an idiot about this. How is easy debugging a gripe? He's griping that it makes it easier to debug? No, that's just idiotic. Debugging on the Android is very easy and that's a good thing, not bad.

Applications never, ever quit? No, that's not true. I made my app quit save and quit when it goes to background. Other people's apps don't quit. You want your app to quit, you can make it so it quits. Also, if app doesn't quit and goes to background, android will automatically close the background app if it needs the resources to run foreground apps. So they do quit, you can program the app to quit, so he's just plain wrong.

He mentions Java... yes, Java sucks for this. The phone is not very fast to begin with, and running a slow bloated language like Java isn't necessarily the best thing. Java is good for people who don't know how to work with pointers and de-allocate memory, Java is good for people who don't understand programming who want to program things and Java pays for it in performance. Java is like a tricycle compared to low level languages. But the good thing is: it's harder to fall off a tricycle and hurt yourself. With a real programming language you might run into huge problems, late night debugging sessions trying to find where your mistake is. With Java you're playing it safe. Thankfully they provided a NDK, but that's a real pain in the ass, has the speed you want, then has the drawbacks too.
You can get around Java's slowness by following their program optimization guidelines, things like: don't use too many classes, cache calculation results instead of recalculating things, use native java functions ie use indexOf instead of looping through a string. It makes Java bearable.

He mentions platform fragmentation. The main difference between Android devices is their different sized screens. Honestly, that shouldn't be an issue, using XML interface it should all look pretty much the same. If you're doing fancy graphics, you have to be smart and use percentages instead of hard coded sizes for things. Coming from a PC background where users might be running 640x480 or 1600x1200, I think we're all familiar with different screen sizes and how to handle them. Going from 320x480 to 240x320 shouldn't be much trouble for a competent programmer. If you can't handle it, stick to XML interface.

So: Android developing might have it's shortcomings, but they're not as bad as this guy makes it sound. Easy debugging is definitely NOT a shortfall. Also, you can download the android SDK + emulator for free, it runs on Mac, Linux, Windows. Compare that to iPhone, you need to pay $100/year to get the SDK, and even after you get it, you can't run it unless you have a Mac.

What is the opposite of damning with faint praise?

[shoor]

The author seems to be praising Android with faint damnation.