Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Cellphones Google Technology

An Android Developer's Top 10 Gripes 272

Posted by kdawson
from the praising-by-faint-damns dept.
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."
This discussion has been archived. No new comments can be posted.

An Android Developer's Top 10 Gripes

Comments Filter:
  • What? (Score:5, Insightful)

    by MortenMW (968289) on Tuesday January 12, 2010 @08:11AM (#30735916)
    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? (Score:4, Interesting)

      by dkleinsc (563838) on Tuesday January 12, 2010 @08:20AM (#30735992) Homepage

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

      • "You're making it way too easy to use to create applications!"

        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)

        by LWATCDR (28044) on Tuesday January 12, 2010 @09:55AM (#30737098) Homepage Journal

        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)

          by Unoti (731964) on Tuesday January 12, 2010 @10:25AM (#30737532) Journal

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

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

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

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

          • Re:What? (Score:5, Insightful)

            by LWATCDR (28044) on Tuesday January 12, 2010 @11:14AM (#30738324) Homepage Journal

            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)

              by tweek (18111)

              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

    • by poetmatt (793785)

      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

    • Yeah, this article is as much a critique as the guy who answers the job interview question "Name your biggest weakness" as "I love my work too much, and will dedicate all my time to it, and often will work long weekends because I just can't help loving work so much."
    • by mcgrew (92797) *

      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)

      by davek (18465) on Tuesday January 12, 2010 @08:58AM (#30736364) Homepage Journal

      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.

    • by furby076 (1461805)

      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 :)

    • by Ash Vince (602485)

      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.

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

    • by rickb928 (945187)

      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.

    • by godefroi (52421)

      More like, "I hate Android because it's just WAY TOO AWESOME! Buy my Android book!"

  • Unix way (Score:5, Insightful)

    by Nikademus (631739) * <renaud@all[ ].it ['ard' in gap]> on Tuesday January 12, 2010 @08:13AM (#30735930) Homepage

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

      by fredrik70 (161208)

      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

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

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

        Interesting. How does Android protect against a rouge app stealing my Google contacts and mass-mailing out Google mail?

        • How does Android protect against a rouge app stealing my Google contacts and mass-mailing out Google mail?

          2 ways I can think of:

          1. On the marketplace there is a rating system and comments. If an app is malicious in a way that anybody finds out about, you're going to see it in the comments and the rating.
          2. Application permissions-- each application much request what things it needs access to. Ability to access the net, ability to access comments, and so on, are all things an app must state up front that it wi
    • by numbski (515011)

      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

      • by Rysc (136391) *

        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.

    • by Goaway (82658)

      And look how popular that is. Hardly anybody adheres to it, even on Unix itself.

      • Re:Unix way (Score:5, Insightful)

        by HunterD (13063) <legolas&evilsoft,org> on Tuesday January 12, 2010 @09:57AM (#30737126) Homepage

        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)

          by GooberToo (74388) on Tuesday January 12, 2010 @10:22AM (#30737490)

          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.

          • by alen (225700)

            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

  • And still ... (Score:3, Interesting)

    by Zarf (5735) on Tuesday January 12, 2010 @08:13AM (#30735934) Journal

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

    • by Zarf (5735)

      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.

    • by SQLGuru (980662)

      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.

  • by ardiri (245358) on Tuesday January 12, 2010 @08:36AM (#30736162) Homepage

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

    • by sznupi (719324)

      Apply your interpretation of 3 to point 8.

      Seriously, why the sudden 1800 degree turn?

      • (as the topic says)

      • by ardiri (245358)

        i prefer printf() debugging - how is point 8 related to point 3? i can do printf style debugging on every platform :)

        • by sznupi (719324)

          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.

    • by e2d2 (115622)

      Show us on the doll where Chris Haseman touched you.

      • by ardiri (245358)

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

  • 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

  • by Maxmin (921568) on Tuesday January 12, 2010 @09:13AM (#30736496)

    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??

  • by Comboman (895500) on Tuesday January 12, 2010 @09:17AM (#30736536)
    1. SDK only available for Mac.
  • why Java? (Score:2, Interesting)

    by ShenTheWise (1277986)

    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

    • What would be more appropriate here than Java? Obviously not Mono/.NET Compact Framework, that's going to be years behind the 'latest' Android OS version. Obviously not ObjectiveC, as it's not a language but a joke.
      • by furball (2853)

        What would be more appropriate here than Java?

        C? C++? Java is innovating itself into the ground. Have you read the Java 7 documents?

    • by fredrik70 (161208)

      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

  • 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

    • I'll give the guy the benefit of the doubt and some of these points are "tongue-in-cheek" - assuming that's the case then ok verrry funny!

      I'm certainly not defending Google or an Android fanboy but this article is utter rubbish.

      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?

  • by Unoti (731964) on Tuesday January 12, 2010 @10:08AM (#30737288) Journal

    tragedy of the commons: the misuse and overuse of a collectively owned resource. In the case of Android, that common resource is the memory, processor, and battery life of the handset. The tragedy is that any application, while in the background, can use any amount of resources.

    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)

      by GooberToo (74388)

      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

  • by amoeba1911 (978485) on Tuesday January 12, 2010 @12:26PM (#30739592) Homepage

    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.

  • by shoor (33382) on Tuesday January 12, 2010 @01:11PM (#30740312)
    The author seems to be praising Android with faint damnation.

* * * * * THIS TERMINAL IS IN USE * * * * *

Working...