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."
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.
"Android, by contrast, pushes you to design everything as small, self-contained mini-applications."
Hey, that's called the Unix way.
I gave up with the idea of an useful sig...
... 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]
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.
>> 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.
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.
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.
Fire up something like advanced task killer and see what your memory utilization is like. He has a point, getting an app to "close" in the sense that it's not running and not hogging memory is a problem with Android.
There are some people that if they don't know, you can't tell 'em.
1. What are you complaining about? Of course it's a legal grey area, those are some of Google's primary products - why would they make it easy for you to slap Google Maps into a thin wrapper, insert adverts, and call it "Chris's Maps"? Go write your own, silly boy.
2. You are required to declare *exactly one* activity and intent. After that, it's up to you how you stitch together your app's UI elements. The point of multiple Activitys is that they're a) modular, b) stackable, c) can be swapped during low memory events, and d) can have their state preserved by the platform upon exit. Personally, I prefer a low number of activities, then use other UI elements to add navigational depth.
3. New to software development, eh? Over the next 5-10 years, be prepared to learn new and discard old, that's the profession you've entered (recently, it seems.)
4. "Never quitting" is merely the default. It's up to you to detect navigational or logical termination of your app, and invoke the necessary methods to bring it to an end. The reason for this is that, hey! it's a phone, call might come in! and it's a multitasking O/S! Another app's Activity may suddenly be running on top of yours, and you may not want to exit just yet, hmm?
5. Finally, a real problem. Yes, there are apps that leave background processes running continuosly, disregarding the device's sleep state. These are from bad developers -- learn well from their mistakes. Also, you don't have to use those apps, just uninstall them, and also install Power Manager which will extend your battery life.
6. Watch the video "Writing Real-time Games for Android," wherein you will be introduced to some key concepts around embedded and real-time software development. First and foremost, STOP DOING THINGS THAT INVOKE THE GC! Cool it with excessive + string + concatenation and start using StringBuffer. And preallocate objects to that end as well. Et cetera.
7. Intense, dude. Having developed for Blackberry, all I can do is throw my head back and laugh, laugh hard. Android is a V12 Ferrari next to Blackberry's three-cylindar commuter tin can.
8. If you'd read Google's Android documentation, you'd realize this point was moot, thanks to the carefully spelled-out guidelines that will keep your app looking and behaving the same across various screen sizes. True that you'll have to *think* about how to handle an 8x10 format screen in your app, but that's no different than any windowed platform.
9. You start out whining about "platform fragmentation," then return to your point #1. Whatever. Platform fragmentation may, indeed, become a problem one day, but you haven't defined how that will happen, in your point.
10. If I'm not mistaken, Nexus One equals (or eclipses) the iPhone's raw computing power. 1 GHz, GPU, though low on RAM and flash comparatively. I'd rather have a platform with greater RAM, but the architecture of Android is such that it is *meant* to run on low-capability devices.
Apart from the author being a newbie, did we all misread it as not being a spoof??
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
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)
There is a built in task killer, at least in DROID.
Settings -> Applications -> Running Services.
The only program I've found that doesn't quit properly is the Music application that comes standard on the DROID. Even after quitting (either by pulling out headphones or stopping music and exiting out of the application, I still see it running in the "Running Services" list.
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.
Actually, this is a developer sin.
Actually its not.
Why Task Killer is for ignorant fools... ....and why you're fighting Android...
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.
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.
The author seems to be praising Android with faint damnation.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
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.
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.