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."
What? (Score:5, Insightful)
Re:What? (Score:4, Interesting)
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!"
Re: (Score:2)
Well, isn't that the point?
I've developed on Android the last weeks, because I felt the challenges this summer creating apps are mainly "teensoftware", which is great in alot of dimensions (getting people interested in programming, there's alot of progamming work out there, stop making people wan ting to get lobotomies because you "set your job safe" by writing hard to maintain code) but that teensoftware, doesn't scratch my itch.
Teens and likes
Re:What? (Score:5, Insightful)
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? (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:What? (Score:5, Insightful)
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: (Score:3, Interesting)
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.com]
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 shoul
Re:What? (Score:4, Funny)
Re: (Score:2)
This is true, but not all that bad generally. When I start a new app I do it in a 1.5 emulator, and move to another higher version if I really need to. For me, the different software versions aren't in practice very difficult to deal with. What is difficult to deal with: different hardware configurations. Making an app that works well with a touchscreen, or with a trackball, or with just a D-Pad, or that works great with a keyboard but only if it's there-- those kinds of issues make it more of a challen
Re: (Score:2)
If you're focusing on his one lanky point, then you're missing the point of the article: which is that a LOT of things are messed up on android.
In reality he is concerned about google's lack of actual open source - since apache is like BSD license, guess what happens? The important pieces are kept proprietary in the code, and that creates problems.
the other programming issues and google quirks were equally very accurate. Fragmentation and having piss poor hardware except for a couple phones is also an issue
Re: (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: (Score:2, Troll)
Apple? The test was done by Motorola!
Re: (Score:2, Informative)
Re: (Score:2)
http://www.chevrolet.com/corvette-zr1/ [chevrolet.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
1. Open Source. Leave it to Google to place all the code for their handset platform in the hands of the masses
More evidence that opensource=fewerbugs? The statement I quoted suggests the guy is an elitist. I'm not going to RTFA as it'll probably piss me off. No wonder Microsoft hates open source so much. Is this guy primarily an MS dev?
Re:What? (Score:5, Insightful)
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: (Score:2)
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.
I actually thought he was being facetious, more along the lines of "Darn you for buying me that lottery ticket that made me a millionaire". Though if he billed hourly he is probably annoyed because he has 40% less work :)
Re: (Score:2)
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.
I don't think much of his article should be taken seriously. He makes some very valid points but most of it is written to be very tongue in cheek. In other words, he does not really sound very angry. He even mentions at the end of the article that Android is one of his favourite platforms to develop for.
Re: (Score:2)
Perhaps his real problem is that google is commoditizing the software industry.
I'd say better get used to it, and start making real applications that serve a certain niche, instead of the mainstream applications that everybody uses.
Re: (Score:2)
Had you read the last paragraph, you would not have found the word 'angry' to accurately describe the author's attitude towards Android. At least not as accurate as 'favorite'.
sheesh.
Re: (Score:2)
More like, "I hate Android because it's just WAY TOO AWESOME! Buy my Android book!"
Unix way (Score:5, Insightful)
"Android, by contrast, pushes you to design everything as small, self-contained mini-applications."
Hey, that's called the Unix way.
Re: (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: (Score:2)
The first time I read how this works, I had memories of Windows OLE and hoping this time it would be done right. It looks like it has, for the most part. The activity paradigm works very well so far and is very handy to writing good small stable code.
Re: (Score:2)
Interesting. How does Android protect against a rouge app stealing my Google contacts and mass-mailing out Google mail?
Re: Security (Score:2)
2 ways I can think of:
Re: (Score:2)
I know there's at least one open source project that does what OSX does with it's .app bundles, but I'm really surprised that the .app way of packaging applications for drag-and-drop use hasn't caught on with the rest of the Unix-like OS community. The only reason I can think of off-hand is the architecture concerns - x86 vs x86-64 vs ppc vs arm, etc, but we already live with this today using things like apt and yum. Disk space is cheap, and largely, so is bandwidth. I really don't mind having 10 copies
Re: (Score:2)
ZeroInstall (aka 0install) (http://0install.net/howitworks.html)
rox filer/rox desktop (http://roscidus.com/desktop/)
nixOS (http://nixos.org/nixos/)
GoboLinux (http://www.gobolinux.org/)
If it were a *good* idea one or more of these things would be dominating by now.
Re: (Score:2)
Read my lips: You will always have to create a package for each distribution, app bundles do not solve this problem.
Unless your application is a fully self contained virtual machine AND the program that knows how to run it, depending on nothing but bog standard libc and POSIX, then this will be true. If you want anything remotely complicated you *will* have to deal with distribution inconsistencies.
"But apple..."
You still have to be careful because every version of OS X isn't always the same. Even so it's s
Re: (Score:3, Insightful)
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 us
Re: (Score:2)
And look how popular that is. Hardly anybody adheres to it, even on Unix itself.
Re:Unix way (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
i'm a DBA and i love it when i see queries that make your head hurt. i see it from our devs and online where people write some elegant and complex code to show off. the same thing can be done by an intern writing simpler code to execute something in a few steps rather than in 1 step. and it's a lot easier to debug more smaller steps than a stored procedure that calls 10 other stored procedures and each one of those calls a few more down the line
Re: (Score:2)
And is still in use nowadays.
Re:Unix way (Score:5, Insightful)
But then again, so is Cobol.
Re:Unix way (Score:4, Funny)
Stop you guys, I am running out of paper rolls on my teletype.
Re: (Score:2)
which was fine for terminal applications 30+ years ago.
...or when you need to get a lot of things done in a hurry and without fanfare.
Re:Unix way (Score:5, Insightful)
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: (Score:2)
Stupid non-argument. Just because every desktop environment for Linux epically failed in transporting the Unix philosophy to the graphical desktop, that does not mean that it is bad. Quite the opposite, since those “monolithic applications, task bar and windows” environments are really crappy to what proper a Unix GUI would have meant.
First imagine a couple of applications. E.g. a word processing app, a drawing app and a address database. Now imagine every function it has, split into its own tin
Re: (Score:2)
It is more powerful alright. But it is also a mess of layers ontop of layers which makes the system slow and unrespondable because of the huge overhead. It is also like a huge corporation with lots of management layers - clearly arranged when looking at the whole, but difficult to understand from inside and very slow. It is IMHO more efficient to combine the small modules in a larger and more generic ones.
But as I already mentioned, it is just an opinion.
Re: (Score:2)
which was fine for terminal applications 30+ years ago
Which is why Windows Mobile has really over taken the market with its lack of modularity and all of it's custom development targeted specifically to the platform... Oh wait
Re: (Score:2)
In lots of markets it really has. I am working in the field of vehicle telematics and Windows CE/Mobile is huge in this market. Also, before iPhone Windows Mobile had a huge chunk of the PDA phone market for years.
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
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 sc
Re: (Score:2)
and people used to use keyboards back then too!
Re: (Score:2)
...or for recent operating systems such as OSX, Linux, BSD, etc. Plus, a GUI does not necessarily mean "huge mammoth application," so the idea of these mini-applications is not just limited to terminal apps.
The idea of having modular, small applications is a much better one than the mammoths that we sometimes see in the application world. I don't know if you're trolling, or what, but small, self-contained, mini-applications that do one thing and one thing well really is a better way (for the most part).
Re: (Score:2)
I would almost argue that any OO code (well, the code that follows a decent object model) is really composed of small, modular, self-contained, etc. etc. mini-applications that do one thing well and are easy to test, debug, etc. And when you put them all together, you have a "mega-application". That OO thing sure seems to work for [insert most modern languages here -- even scripting languages].
But then, what do I know. :D
Re: (Score:2)
Large programs, built using small tools that do one thing and do them well, with simple and well-defined inputs and output, with orthagonal effects on the rest of the system....the Unix way...are the most successful, stable, and easily updated systems in use.
Your UID leads me to believe you've read The Art of Unix Programming by Eric S Raymond....did your brain fall out since then?
Re:Unix way (Score:4, Insightful)
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.
And still ... (Score:3, Interesting)
... 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.
Re: (Score:2)
You know what I find funny? I got modded redundant and this was the only post in the Forum when I left it. Now that's funny! +1 funny to the moderator.
Re: (Score:2)
I'd actually like to see some Android development done in Go. I see it as a good direction for both Google and the Platform.
veteran mobile application developer ? (Score:4, Insightful)
>> 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.
Re: (Score:2)
Apply your interpretation of 3 to point 8.
Seriously, why the sudden 1800 degree turn?
Arghh, 180 degree of course... (Score:2)
(as the topic says)
Re: (Score:2)
i prefer printf() debugging - how is point 8 related to point 3? i can do printf style debugging on every platform :)
Re: (Score:2)
It's not simply about printf...
In response to #3 you wrote that he should be glad the platform made his debugging skills largely obsolete, that he should get on with the times, and so on.
Yet, it #8 you write that he can continue to deal with something that shouldn't be such a pain in the a** to begin with, nowadays.
Re: (Score:2)
Show us on the doll where Chris Haseman touched you.
Re: (Score:2)
Show us on the doll where Chris Haseman touched you.
heh - i wonder how many people realize he is a martial arts trainer as well. i think hats off to the guy for getting the press - but, he seems to be complaining a lot about something he seems to be supporting heavily (author of book et al)..
I'm not a coder however... (Score:2)
My comment is probably not worth too much not being a developer at all but I am an iphone owner and I must be honest the Nexus one does look pretty interesting.
I'm also an Aussie and the Nexus one isn't coming here unfortunately due to incompatibilities with Telstra (the most evil company around, sadly they do have a good phone network)
I will say most of his stuff is meaningless to me but as a hardware junkie, his 8'th point about the amount of target platforms, inherant in the nature of an open platform li
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??
(Potential) iPhone Developer's Top 1 Gripe (Score:3, Interesting)
why Java? (Score:2, Interesting)
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 th
Re: (Score:2)
Re: (Score:2)
What would be more appropriate here than Java?
C? C++? Java is innovating itself into the ground. Have you read the Java 7 documents?
Re: (Score:2)
hold your horses, Java aint *that* bad. With the ability to write c libs for your java code I think things should be ok. Personally I prefer to do the UI in java/xml and then any heavy number crunshing in c. that way you use the languages for what they are best for. At least until someone ports QT to android phones. ;-)
Also when they get the JIT to work for the Dalvik runtime things will also be a bit better
Re:why Java? (Score:4, Interesting)
GP's point #3 was about C++ being more efficient by a lot. His point actually is valid. Consider all the things you need to be mindful of when writing efficient Android apps in Java [lampwww.epfl.ch] There are so manu things that you need to be careful not to trip over, even in Android's optimized Java. Things that a C++ compiler would optimize out no problem. Generally Android's java is very optimized and is terrific and surprisingly fast, but it's still no C++ in terms of performance. But it's also easy to write for generally and very approachable, so I'm not complaining. Just saying that Gp's point #3 should not be dismissed entirely without due consideration.
Re: (Score:2, Troll)
Generally Android's java is very optimized and is terrific and surprisingly fast
I have no idea where you get this impression. Android's dalvik engine is widely known to be roughly 20x slower than most other non-JIT'd java VMs. Its slow by any measure. And worse, most CPU intensive tasks which are commonly required for many mobile applications fall into a category where performance is especially poor for the current Dalvik implementation.
The good news is that Android's Dalvik will soon have its initial JIT offering which will speed up applications, on average, roughly 100%-150%. Once re
He Calls Himself an Android Developer? (Score:2)
1. Open Source
This is the most benign on this list, and it's only here because now everyone and their brother is going to make a new "Android-powered" device.
I'm tempted to quote the whole paragraph but this last bit made me laugh!
I thought this was a good thing because it means more competition, the "barrier to entry" is low - it's accessable to almost anyone and enables innovation.
3. Device Debugging ..Back in my day (and by "in my day," I mean two years ago..Why do I hate this extremely useful tool? I hate it because it makes about 40% of my debugging skills nearly useless!..
curse their cotton socks, has quite literally taken a process that used to involve hours of work and reduced it to simply pressing F11. Not only is it straightforward and easy to use, but it also works on every platform out there (Mac, PC, and Linux).
He MUST be JOKING - must be!
No developer in thier right mind would see this as a bad thing!
Especially "Back in my day (and by "in my day," I mean two years ago)". This "wealth of experience" proves his naivety.
6. Java--Thanks, But I'll Take It from Here
As a programmer, it makes me feel like I'm getting a very slow lobotomy..nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time..write custom libraries in C with their NDK, but now we're debugging two languages..
What a narrow-minded view!. Not everyone wants to write low-level stuff li
Why isn't this on idle? (Score:2)
Come on, my sarcasm detector went off while reading the first "Gripe". But I agree, this one is lame even as a swipe against the "10 reasons I hate/love gadget X" articles. Why isn't this on idle?
5. Developer Cooperative (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
Apps only get to use 16 megs of memory on Android.
That's actually not true. That's a hardware manufacturer's limit and can vary from device to device. Android itself places no such constraint on application memory. The limit is set on a per hardware basis.
From a programmer's perspective, that likely means supporting the lowest common denominator, which is entirely a different issue. Though pragmatically for you, that hardly makes a difference.
You might check and see if the limits are accessible at runtime which will allow you more adaptive flexibility in y
He's right and he's wrong (Score:4, Insightful)
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? (Score:3, Insightful)
Re: (Score:2, Insightful)
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: (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: (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]
Re:dumb article/crappy developer (Score:4, Insightful)
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.
Who says Google talks clearly? (Score:2)
Actually, that's quite simple. It's ok when Google (the copyright holder) says it's ok, otherwise it's not.
Agreed. Understanding what Google actually says might not be so simple, though. I think that's why people have a tendency to employ people* who are experts at interpreting law and contracts.
(*) I mean lawyers.
Re: (Score:3, Interesting)
The biggest reason he gives while this is bad is because it destroys then recreates an activity upon rotating the screen. What I've
Re: (Score:2)
That's a implementation issue, not a design issue. He claims the design is inherently bad, which I don't think is the case.
Re: (Score:2)
The biggest reason he gives while this is bad is because it destroys then recreates an activity upon rotating the screen
That's the default. The behavior can be overridden such that the activity is not destroyed and recreated.
Re: (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 ho
Re: (Score:2)
The OS already closes those apps for you. The system never actually runs out of memory, does it? I wish it were slightly more aggressive sometimes (and some of the task managers simply lower the high water mark to achieve this), but for the most part it works.
I can run my weather software, then check my mail, click a link in my mail to Dolphin (the browser), and subscribe to the feed in Google Reader without much of a hiccup in between -- on an old HTC Dream phone. Granted, its even faster since moving u
Re: (Score:2)
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.
The entire point of applications like Advanced Task Killer is to free up memory. But it entirely defeats the purpose as it is itself an application consuming memory. Plus, the application kills battery power like its going out of style because it constantly polls to obtain process lists and per process information. Add in the fact that many users break applications by using it means that most developers absolutely hate the application because it generates bugs reports wasting endless developer time.
That spe
Re: (Score:2)
It's a problem with developers, and it annoys the piss out of me.
Then you are annoyed by developers following Google's guidelines. The sole exception is that many developers are abusing (incorrectly using) services but even then the OS takes care of it.
There are a precious few apps that actually completely close when you hit menu -> quit. Most don't, and many even lack a quit command altogether.
That's because a quit button or menu item doesn't actually do anything. As such, most developers don't waste space and memory adding a feature which only serves to compound memory pressures.
I get tired of having to run a task manager to manually kill each app after I'm done using it.
That's because the system will re-use the memory as it sees fit. Generally speaking, its vastly smarter than any user at doing so. The
Re: (Score:3, Insightful)
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 wit
Re: (Score:2)
Actually, It's up to the OS, the OS *might* keep it running, until it needs the resources held by the app.
See this:
http://www.anddev.org/lifecycle_of_an_activity-t81.html [anddev.org]
Re: (Score:2)
Point 5 seems simple enough - no tyranny required.
Nice the application in the foreground to have high priority, renice everything not in the foreground behind it. Problem averted.
Am I missing something? I know that doesn't address RAM, but if one wanted to, they could load a small memory management daemon that matches RAM/swap use to the current nice states. Whatever is in the foreground can have physical memory, everything else goes to swap unless physical happens to be free and not in use.
Re: (Score:2)
The problem with that is that I might want to have music playing while I do other things like webbrowsing.
Re: (Score:2)
The problem with that is that I might want to have music playing while I do other things like webbrowsing.
That's why the framework supports priorities. Background tasks are automatically assigned a lower priority. Tasks which play music, etc., should be assigned the corresponding priority so that it reacts accordingly to priority changes. The framework already accounts for all this; assuming the developer is properly using the framework.
Re: (Score:3, Interesting)
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 wri
Re: (Score:2)
You go play with your 'hammer of standards' platform and I'll stick to the everything just works phone with lots of small working packages that interoperate and we'll see who's got more options next year.
Re: (Score:2)
Looks like the author is so green behind the ears he does not even know where the concepts of such mini applications with well defined interactions with other mini ops are coming from. At least one thing is sure, he got the attention he craved so much.
i think we can knock that down to experience :) lets take him back 10 years and program newton and palm os devices and see how much he loves android after that.
Re: (Score:2)
The Intent system is what makes Android so powerful. If I have an application that wants to sent a twitter message, it can send an Intent with a request to do so. This Intent can be picked up by any of the applicaitons you have installed, so that the developer not only doesn't need to develop twitter functionality, the user can also choose to use whichever twitter application he wants, and it'll still integrate perfectly.
In case you were wondering, if more than one app is prepare
Re: (Score:2)
Also, I hear he's fluent in Sanskrit and can divide by zero.
I can divide by zero. The answer will be incorrect, though.
Re: (Score:2)
It appears to be on their bug list [google.com].