An Android Developer's Top 10 Gripes 272
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."
Re:What? (Score:2, Informative)
Shitty touch screen? Sounds like you haven't actually used one yet. HTC screens are pretty much the best out there.
Disclaimer, have spent an hour with a friend's Nexus and this post was composed on my Hero.
Re:Unix way (Score:3, Informative)
Indeed, the cool thing is that Activities can be shared between processes, My app, for example, can for example make use of Google's picture browsing or the google map activity , no need to write one myself.
Activities are placed on a stack, so when the user hits the back button to leave the 3rd party activity they are returned to my activity
Re:dumb article/crappy developer (Score:3, Informative)
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.
Obviously an inexperienced Android developer (Score:3, Informative)
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 [google.com]," 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??
Re:dumb article/crappy developer (Score:2, Informative)
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.
Re:What? (Score:2, Informative)
Re:What? (Score:5, Informative)
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:dumb article/crappy developer (Score:3, Informative)
Actually, this is a developer sin.
Actually its not.
Why Task Killer is for ignorant fools... [slashdot.org] ....and why you're fighting Android... [slashdot.org]