An Android Developer's Top 10 Gripes

gkunene writes in with the plaint of a veteran mobile application developer who vents his frustration with a list of 10 things he loves to hate about Android. "1. Open Source. Leave it to Google to place all the code for their handset platform in the hands of the masses. Not only does this mean anyone can download and roll a new version of their phone firmware, but it also means absolutely any maker can roll its own Android device. ... After all's said and done, I really must admit that Android, despite its relatively few flaws, is one of my favorite platforms to work with. Quite honestly, if my complaint about how the word 'Intent' makes for awkward grammatical constructions ranks in the top 10, I'd say the Android platform is doing pretty well for itself."

Comments

What?

[MortenMW]

Disclaimer: I actually read the FA (yes, I know this is slashdot). This guy is angry because, amongst other things, Google has made 40% of his debugging skills useless. Apperantly, his problem is that this means that other people without his "superskills" can develop software for Android.

Re:What?

[Anonymous Coward]

Most of what he said seems to be more of a sarcasm than a complaint.

Open source? running in your microwave? You should be happy - more money for you.

Re:What?

[dkleinsc]

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

[poetmatt]

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.

From the G1 in comparison to every android phone since and the nexus one of now, every phone has been basically creeping closer to iphone performance...now they finally have better hardware, but on a shitty touchscreen.

Google has a lot to fix, and I don't know the answers. Open sourcing their maps and other currently locked down apps would be a good start.

Re:What?

[happy_place]

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

Re:What?

[mcgrew]

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?

[Anonymous Coward]

He does have one very legitimate concern, and that is that the platform can easily be forked

So call me when this "disaster" actually happens.

Re:What?

[Aranykai]

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

[ZeroExistenZ]

"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 don't know the needs of people in the workingforce or businesses and that's where you have your targetaudience if you want to get serious on mobile development. (I know some government projects working on augmented reality software, which is pretty cool. But that's also not where my focus is.)

Concerning the "ease", it took some thought to get performance right in my applications and generics aren't that easy as in .NET. There's some more thought required and the debugger might be nice but .NET started to feel like playing with playdoh compared to receiving a bag with sand and a cup of water.

I wonder what the purpose of IT and development is, is it coming to a solution or is it messing on the way to a solution? I know I get more out of delivering something then maintaining a mess or constantly being "almost done".

Easy of development is something that you should be happy about, you're a programmer above a procrastinator or even a sadomasochist, right?

Re:What?

[Threni]

You must have missed the recent story about how they don't seem to be as accurate as the iPhone screen.

Re:What?

[davek]

Sounds to me that he's searching for things to have a problem with, and fully admits it. At the very end of the article, he responds to
his own point 7, where he complains about the grammatical heresy of the Android programming concept of "Intents":

Quite honestly, if my complaint about how the word 'Intent' makes for awkward grammatical constructions ranks in the top 10, I'd say the Android platform is doing pretty well for itself.

If "good debugging" and "poor grammar" are two of the top ten worst points about the platform, then I'd consider it quite a positive article.

Re:What?

[Anonymous Coward]

Doesn't mean they are shitty... I use one everyday with no problems. I never have to draw *perfectly* straight lines... I dunno about you.

Re:What?

[furby076]

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

[delinear]

He will, so long as his phone's not forked.

Re:What?

[Anonymous Coward]

Well it must be true if you read a story about it somewhere. I own a Motorola Droid as well as an iPod touch. The touch screens are equally functional. Neither is better than the other. They both work great.

Re:What?

[Anonymous Coward]

To some extent it already happened, not all phones have an upgrade path:
http://phandroid.com/2009/12/17/android-developers-introduce-device-dashboard/

Re:What?

[TheKidWho]

Apple? The test was done by Motorola!

Re:What?

[drb_chimaera]

However, "touchscreen not as accurate as iPhone" != "Shitty touchscreen". In a lot of ways I prefer the screens on the current crop of Android phones. Based on limit experience I've not noticed any difference in sensitivity in real world use, but prefer the higher res and image quality on the newest Android phones.

Re:What?

[MrNaz]

40% less work != 40% less billable hours. I envy you, you've obviously never met a lawyer.

Re:What?

[MikeBabcock]

And Corvettes aren't as fast as Vipers.

Re:What?

[Ash Vince]

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

[LWATCDR]

Not really.
He hates Java. A lot of people seem to feel that way. I actually like Java more than say c++ because I find the Java object model has a less of a tacked on feel.
The big problem is that he doesn't like the "fragmentation" which is a valid concern for a developer. You have a number of different screen sizes to deal with, you have a number of different cpus that run at differn't speed to deal with you way to many different versions to deal with, and you have what ever custom sillyness that the vendors may put in to deal with.
On thing that is very nice for developers about the iPhone is that it is a very consistant controlled enviroment. It is much more like developing for say a game console than for a PC. That makes hidden gotchas less of an issue.
Android is a lot more like a PC.
So you are half right.
Android makes it way to easy to build simple apps but makes t more difficult to produce top notch professional apps than the iPhone does.
How true that is I don't know since I have yet to dive into the Android SDK but even now I wonder which SDK do I write too? 1.5 which seems to be the most common. 1.6, 2.0, or do I leap to 2.1 and hope everybody updates by the time my app is done?
It is EXTREMELY annoying that there are so many different versions of an OS all of which are shipping on phones right this second!

Re:What?

[gabebear]

It was done by Moto Labs, which has nothing to do with Motorola. http://labs.moto.com/diy-touchscreen-analysis/

Re:What?

[Anonymous Coward]

basically it all sums up to point 10 of tfa: android is not iphone. booo booo call me a whaaambulance.

Re:What?

[StripedCow]

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

[rickb928]

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

[Unoti]

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?

[Skythe]

I think he was more looking to complement Android. It's obvious he's a supporter of the platform, voicing some things he dislikes, but threw that in to make it not-so-negative. I think it's a well written article and he raises some valid points, although i disagree with some (i.e. activities & intents can be very useful).

Re:What?

[A12m0v]

http://www.chevrolet.com/corvette-zr1/

Re:What?

[godefroi]

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

Re:What?

[Anonymous Coward]

Um.... that's already happened, My phone is still 1.6, the droid is 2.0 and the N1. is 2.1. Which version are you developing for?

Re:What?

[Anonymous Coward]

The test was done by a company called Moto which is not affiliated to Motorola.

Re:What?

[TooMuchToDo]

But it's waaaaaay cheaper to purchase a Corvette and add a supercharger (and get a nice interior, air conditioning, etc) than it is to get a Viper.

/owns two corvettes, c5 and c6

Re:What?

[Unoti]

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 challenge than it would be with just one hardware configuration.

For me, the proliferation of hardware configurations is more painful than the proliferation of software configurations. But at the same time, this weakness of the platform is also the greatest strength: there's no other way I can think of for anyone to compete meaningfully with iPhone than to allow anybody and their brother to make the devices and participate in the app store.

Re:What?

[Bill_the_Engineer]

HTC screens are pretty much the best out there.

Really? Then why can't I accurately press the 'P', 'bksp', or 'done' key on my myTouch while in portrait mode?

Re:What?

[LWATCDR]

For some games I would agree with you 100%. And Android does allow you to use native code for some performance critical parts but as the original author stated then you have to debug in two languages.
I don't hate C++ and I have used it for high performance applications. The thing is that I feel that Java gets too much hate. The "problem" with Java it it is too easy to make a program that works. Because of that you get too many people putting out Java programs that work but don't work well. In C++ they just wouldn't work at all.

I still feel that the real problem with Android is in many ways the openness of it. I wish that Google would get EVERYBODY on the same version. I am tired of waiting for Samsung to update my phone to 2.0 or 2.1. It is just silly that Motorola released two phones in the same time frame and one has 1.5 and one has 2.0! or that Verizon released two Android phones on the same day and one had 1.5 and one has 2.0. Or that T-Mobile has phones with 1.5, 1.6 and now 2.1!
This fragmentation on such a new platform is just insane.
 

Re:What?

[rliden]

That's the point of open source though isn't it? Any developer, company, etc can take the code modify it for it's own use and distribute it within the license agreement. Maybe the answer to ensuring cross brand compatibility with applications is for Google to develop a standard interface that requires third party system developers to implement in order to use the Google or Droid trademark on the phone.

Re:What?

[alteran]

I think it's obvious that specific point was tongue-in-cheek.

His mix of legitimate gripes and tongue-in-cheek "criticism" makes the article a little tricky to parse-- but I learned some interesting stuff about Android.

Re:What?

[TheKidWho]

Forgive me o god of /. for I have assumed.

Re:What?

[alteran]

I don't think you've read the article thoroughly. His first complaint is about the developer model and how it clashes with every other model out there, and how it makes porting really painful. He also complains about variable hardware. He complains about the weak enforcement of resource management. He complains about hardware variability.

These are all real complaints. He does throw in a couple tongue-in-cheek "complaints," but it's generally critical.

Re:What?

[Monkeedude1212]

Makes you wonder what his top 10 list comprises of.

Re:What?

[uberjack]

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

Re:What?

[__aaaaxm1522]

Have you done any Android development work? I have, and I can say that it's more likely that Activities & Intents have fueled his rage. The debugging thing was just the kindling that got the fire started.

Re:What?

[Unequivocal]

He was using irony on that point, and a few others. The article isn't as horrible as you might think.

Re:What?

[jc42]

Dunno if I'd call the G1's screen "shitty". But I did have to learn to touch buttons slightly above where they seemed to be, if I want them to work. I still tend to get the button below the one I'm aiming at with some probability.

My wife has an iPhone, and I've done a bit of comparing. I'd say that both have screens that are a bit too sensitive. I've verified (by shining a light from the side) that I don't actually have to touch either's screen to activate something. That probably explains why, on both of them, I'm constantly "touching" something that I didn't intend to touch, and then I have to figure out how to get back to where I was.

The G1's little nipple-like joystick actually helps here a bit. It lets me move the current position around the screen, and scroll, without accidentally touching the screen and activating some button. Now if there were a way to push ("click") it without also getting a motion of some sort before the click takes effect ...

Re:What?

[furby076]

40% less work != 40% less billable hours. I envy you, you've obviously never met a lawyer.

Well played young fellow, well played. Maybe I should have said 40% less work = 40% less honest work :)

Re:What?

[RAMMS EIN]

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

Actually, I rather think that the effort to get the Java code right is probably about the same for Android as it is for "normal desktop or server Java". The difference, though, is that the effect of not getting it right is much more noticeable on a mobile device than on a computer with vast processing power and memory, and practically unlimited electric power.

Also, I suspect that the Java compiler and runtime used on desktop and server systems do a better job of optimizing away inefficiencies than the runtime in Android in its current state.

Re:What?

[2short]

"He was using irony on that point" No, he was not. He believes that making the OS open source is actually a bad thing. Because it could lead to less consistent APIs if/when phones are running multiple different quirky forks. He may be correct, as far as his narrow, personal interests as an application developer are concerned over some short-term time frame at some possible point in the future. If he truly believes, as I do, that the benefits of making it open source outweigh this, he makes no indication of that in the article.

Re:What?

[carlmenezes]

I have a problem with that test - it does not measure perceived accuracy. They used a paint program to draw straight lines. While that is a good test of the accuracy of the physical device, is that really a good test of the perceived accuracy? The perceived accuracy is what matters to most people. The iPhone may be able to draw straighter lines, but if the Android device feels more responsive and feels more accurate, then that's the one that's more accurate. I guess its like comparing two toys - while one may be made of better materials, etc etc, if the other one is more fun, then people will gravitate to it. As much as I hate it, being an audio guy myself, a system that delivers louder music with a more punchy bass is usually more appealing to people, though it makes my skin crawl when I think that using that system, you will never hear a piece of music the way the artist intended. I think its a similar thing here. If the android devices feel better, they will be more popular. That's it.

Re:What?

[2short]

If only there were an article in which he listed them.

Re:What?

[Anonymous Coward]

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

It is a lot lower level. Mobile development, at this point, requires you to think about performance concerns, both in speed and power consumption. And no amount of high-level language environment can abstract away those concerns. The only way that we can abstract away those concerns will be to pack higher performance chips, more RAM and batteries with more energy into phones.

And Dalvik is a different environment from the standard JVM. Like you said, you have to consider memory management because if you don't, the VM will do garbage collection in the background and, if done enough, drain the battery and reduce the amount of memory available to applications. And you're forced to consider things like the lack of a JIT compiler too.

None of this is to say that a mobile Java environment should be any different...from what I've seen, Dalvik is more sensibly architected than J2ME VMs. It's just that when you have the hardware constraints of a mobile phone, the developer is forced to adjust to the environment.

Re:What?

[tweek]

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 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 should people cowtow to you?

The point is that the HOPEFULLY with the google store for Android powered phones, they can drive the market to stick as close to stock Android as possible. I would hope that Sense UI and Motoblur devices would be kept off the official Google store or at least come with a disclaimer that this is a customization and that not all apps will work with it.

Additionally, Google needs to implement some sort of automated app scanner that determines if the app is making 1.6,2.0 or 2.1 compliant system calls and version the apps presented in the store to each device as supporting that release.

I have no idea what to do about the screen issue though but I think it's going to come down to two differentiators - Android Powered (Sense UI, Motoblur, whatever Sony is calling their version) and Android Experience (stock - DROID and Nexus 2). Maybe "Android Experience" dictates a fixed screensize or some basic level of specification.

Re:What?

[Aranykai]

I felt the same way the first couple of days with my Hero. I ran the calibration tool and it cleared up everything just fine. It's so accurate I rarely, if ever, switch to landscape mode for typing.

If you do buy into that test posted yesterday, it did place the Droid Eris, aka HTC Hero as the 2nd best screen. So, either way, they clearly make a decent product.

Re:What?

[Aranykai]

I'm not sure if the G1 has the same utilities as the Hero, but there was a calibration tool on my phone that might help you with the accuracy.

Re:What?

[LWATCDR]

The Google phone really doesn't help. The Moto Droid is out and is 2.0, my Samsung Moment is out and 1.5, I have no idea what the G1 is at officially I think it is at 1.6....
Screen size? Too late my Samsung is a stock Google build and it has a different screen size than the Droid or the GooglePhone.

Re:What?

[jcrousedotcom]

I can't speak for your specific situation but I do know I had to run the screen calibrate when I got my HTC Hero. I kept hitting the key to the right of where I thought I was. Running the screen calibrate brought what my idea of where a key or button was and where the Hero thought it was to the same point on the screen.

Re:What?

[Pieroxy]

Read TFA again. Apart from the debugging humor, the rest is real.

Re:What?

[Pieroxy]

While true in theory, how could it feel more accurate when it is in fact less accurate? If the line is not straight, it just means that the screen thought your finger was somewhere, when it was in fact somewhere else.

How does that translate into user feeling is something else, granted, but if it is less accurate, I have a hard time believing that it's going to feel more accurate.

Re:What?

[Pieroxy]

More evidence that opensource=fewerbugs?

After reading the article, no it is not.

The statement I quoted suggests the guy is an elitist.

You quoted the story, which almost always is a distorted and truncated view of a bit of the article. I'd refrain from making suggestions about a quote of a /. story.

I'm not going to RTFA as it'll probably piss me off.

Sure, you're much better off with the distorted and truncated piece of info that doesn't inform you.

No wonder Microsoft hates open source so much.

Huh... How did you slip MS in there?

Is this guy primarily an MS dev?

Nope, it doesn't look like he is.

Re:What?

[Pieroxy]

He also says: "It's not just a buzzword, it's a real problem. Quite possibly it's the problem that could sink the Android platform as a whole.". So, what gives?

Re:What?

[Anonymous Coward]

While true in theory, how could it feel more accurate when it is in fact less accurate?

The iPhone could be programmed to smooth out any noise in reading the touch screen. This could cause it to draw straight lines, but feel less accurate, because it is not following exactly what you're doing.

Re:What?

[xenn]

you're an ambulance.

Re:What?

[hey!]

I know. What a wuss.

If debugging your code is *easy* you aren't trying hard enough.

Re:What?

[Unequivocal]

Huh?

"I'm looking forward to an Android-powered toaster oven any day now... This is the most benign [item] on this list, and it's only here because now everyone and their brother is going to make a new "Android-powered" device."

It doesn't sound like a serious gripe to me. It sounds like you're referring to his gripe #8 "Platform Fragmentation" -- that is a serious gripe and makes the argument you describe.

fwiw.

Re:What?

[Danny Rathjens]

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

Re:What?

[Eil]

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.

You must point me to these top-notch professional apps on the iPhone/iPod, because I haven't seen any yet.

I bought an iPod Touch three weeks ago and so far have found that its primary redeeming quality is the excellent web browser. Not much else has really lived up to all of the hype I've been hearing over the past couple years. Even though it carries the iPod name, the UI for navigating and playing audio and video really sucks. Podcast management (the main reason I bought the device) is particularly dismal and there are no downloadable alternatives since Apple forbids it. I've generally found that most applications in the App Store fall into these four categories:

1. Apps which make trivial use of the iPod/iPhone hardware (flashlights, compasses, voice recorders, etc)
2. Content delivery for existing publications, stores and websites (CNN, New York Times, Facebook, etc)
3. Casual games (Tetris, Bejewelled, etc)
4. Personal computation/information software (Tip calculators, notepads, budget apps, currency converters, etc)

I haven't seen a single app yet that I would consider paying actual money for. Maybe it's just because I'm a geek and am therefore difficult to "wow" when it comes to technology, but the point remains. I jailbroke my iPod, but all that really opens up is an adware-supported application installer and shell access to the device. Even many of the jailbreak-only apps seem to be driven by the same "must monetize everything" iPhone development mentality.

The second someone comes out with an iPod Touch equivalent running a full version of Android, I'll be all over it. I'd love to give the N900 a whirl but it costs twice as much as I'd ever pay and the N800 put me off as far as Maemo is concerned.

Re:What?

[Hognoxious]

If it's accurate to less than the width of a finger does it matter?

Re:What?

[mcgrew]

Huh... How did you slip MS in there?

Bugs and "features". He bemoaned the fact that his debugging skills were worthless on the platform.

Re:What?

[carlmenezes]

Because they tested slow movement. How many times have you moved your finger that slowly? To me, its an edge case as far as use cases go. That's why I'm skeptical.

Re:What?

[HR]

I thought his most significant complaint was the one about the completely different programming model using intents -- the way the programs are modularized with control passing between them during execution during different lifecycle states.

Dealing with varying resolutions is kind of a pain but standard stuff on the PC. And if you want to be portable you can target the least common denominator of hardware components. But when one platform is so different in the way the program operates, it makes it very hard to have a common codebase among all the platforms you want to target.

Re:What?

[poetmatt]

what exactly are you talking about? I want a physical keyboard. I am not going to buy a phone that is touchscreen only, and such a concept doesn't work for me.

I didn't mean "bad quality touchscreen", i mean "make a goddamn snapdragon phone with a keyboard so I can give you my money HTC".

Re:What?

[MikeBabcock]

None of which is relevant to the point made in my statement.

"Not as fast as" is relevant like "Not as accurate" is in the GP's post. In this case, both cars are fast, and both screens are accurate, even if one is a little more so than the other.

Unix way

[Nikademus]

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

Hey, that's called the Unix way.

Re:Unix way

[dunkelfalke]

which was fine for terminal applications 30+ years ago.

Re:Unix way

[Nikademus]

And is still in use nowadays.

Re:Unix way

[dunkelfalke]

But then again, so is Cobol.

Re:Unix way

[fredrik70]

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:Unix way

[numbski]

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 of a library so long as they're known to work with whatever version of application x I have, but not screw with application y. For userland applications, it would completely obliterate the concern for dependencies. The downside of course is that instead of `aptitude update && aptitude upgrade` going through and updating *everything* for you, you now have to either have your applications phoning home to check for new versions or the user has to keep up with the latest version themselves (a la VersionTracker for OSX).

I prefer unix personally, and all of my machines are some flavor of it - but man it would push adoption if applications where able to be installed by simply downloading, drag-and-drop. Either that or have it possible via a link to launch Synaptic and start the installation from the program's website. For the user's part, you've now actually made installation *easier* than Windows but the steps involved are similar.

Actually - that latter idea, has it already been implemented? If not, I need to go submit some enhancement requests. :P

Re:Unix way

[drooling-dog]

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

[lokedhs]

And is still fine for mobile devices almost 40 years later.

Imagine that, a software design decsision that worked. It's almost like the people who designed Unix were smart guys who knew what they were doing. Who would have though it?

Re:Unix way

[andreasg]

The only thing it would take to have .app packaging in Linux would be to have the desktop environment file manager (in Gnome for example, Nautilus) recognize them. They don't need to be supported by the OS at a lower level in any way. Now I can't code C, but I bet it could be hacked into Gnome in a few hours. Then you could have people distributing apps like that right away.

Re:Unix way

[dissy]

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:Unix way

[dunkelfalke]

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:Unix way

[dunkelfalke]

Yeah. I love using command prompt on a touch screen only device. It really makes me productive.

Re:Unix way

[Goaway]

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

Re:Unix way

[entrigant]

Everything you just described has been available in a myriad of forms on several distributions for years. The .app bundle might as well be a rpm, details like where the installed files go are just details with good package management.

Also, any decent distribution will setup mime types so that a click on a package on a website will bring up the installer. Some have taken it further than that, e.g. OpenSUSE with their 1 click installs from their build service. Search. Click. Done.

Re:Unix way

[blueskies]

and people used to use keyboards back then too!

Re:Unix way

[djdavetrouble]

Stop you guys, I am running out of paper rolls on my teletype.

Re:Unix way

[D Ninja]

...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). A smaller application is easier to test, easier to debug, makes it possible to swap out one small part for another small part, and, by bringing all those small parts together, you can CHOOSE to have a mega-application. However, if you don't want a mega application, you can also choose to only have the small parts you need.

It really is a nice way of doing things.

Re:Unix way

[MikeBabcock]

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:Unix way

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

[Hurricane78]

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 tiny module. Now put them into two groups: First the property changers, and second the tools/wizards/transformations. The first ones are not real functions.
Now imagine a generic properties frame, with all the properties of the current node of the current document in it.
And another generic tools frame, with all the real functions in it.
Now if you select a tool, the properties dialog will show its properties too, because it is just as much a file.
You could also pipe those tools together, to make new tools.
And there are cascading property classes, just as the cascading style sheets in CSS. Which can also be baked into these new tools.
In fact every command line application can become a tool with its own properties and accepted in and out interfaces, by just writing a small description file for it. Which often could even be partially automated by parsing the man page. (Maybe the future man page format would automatically integrate this information.)

Finally, everything you do in this interface would show in a riseable console on the bottom (or top) of the screen. And you could just mark a couple of lines, and drag it into the tools frame, to create a new tool, to create a (shell) script. Then of course, you could modify that thing, add flow control constructs and parameters, etc. (Like you can in Maya.)

One could even go so far as to have different UIs (views and controllers) to show files (in frames). And different codecs (parsers and writers).

Now tell me that is not much more powerful and nice than what we have now?
It would be incredibly easy to extend a application. Even for non-programmers. To grow his own individual environment, fitting his needs.
Because that application would be nothing more than a set of tools and property-to-parse-tree mappings.
And for those who really just want to use the system, and not become experts, one can create nice downloadable presets and collections of tools. Which means they are not left out on the individualization and can also work efficiently.

P.S.: If this got you motivated to implement such a system, contact me first, since I don’t want us doing double work, and this is only the tip of the iceberg, which means I don’t want you building some half-assed solution. :)

Re:Unix way

[dunkelfalke]

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

Re:Unix way

[HunterD]

Simplicity is hard. Programming the Unix way requires a person to focus on radical simplicity. The benefits are huge. It's a lot easier to debug a 200 line program that takes data in on stdin and dumps it to stdout then it is to debug a class that you can only instantiate with your AbstractFactoryFactory.

The mistake that younger developers make is seeing complexity as hard, and representing mad skillz.

When you have a complex problem that you need to solve, it's /easy/ to make a complex mess with awesome hacks that only you can figure out. It's *hard* to solve that complex problem by building simple programs that even the most junior programmers can easily read, interpret and debug. IMHO, complicated designs are a sign of inexperience, not '1337ness'.

Re:Unix way

[Aqualung812]

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?

Re:Unix way

[dunkelfalke]

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:Unix way

[GooberToo]

Simplicity is hard.

We have a winner!

Can't tell you how many times I've run into coders who believe complex = elegance. Or even worse, terse, cryptic coding is elegant.

Simplicity is its own reward - and a bonus for the developer who follows.

Re:Unix way

[andreasg]

But you still have to use a package manager to install/uninstall an app. And you still have to create packages for each distribution.

Re:Unix way

[Rysc]

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:Unix way

[Anonymous Coward]

How does Android protect against a rouge app stealing my Google contacts

It uses a turquoise filter.

Re:Unix way

[SQLGuru]

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:Unix way

[Rysc]

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 still only a small handful of 'distributions' with a small set of changes.

"But on windows..."

You forget that some apps don't work with XP, only Vista, or vice versa. Some apps requite a C runtime DLL that isn't always there. You mostly forget that all Windows plus all service packs for the last 15 years amounts to a fraction of the number of 'current' Linux distributions and has a lot less variance.

If all the Linux world were Red Hat then there would be no problem.

If all the Linux world were Debian then there would be no problem.

It isn't true. It won't ever be true.

You will always need per-distribution packages.

Deal with it.

Re:Unix way

[alen]

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:Unix way

[Unoti]

Sometimes it's a mess of too many layers. But the approach lends itself to enabling someone to radically simplify or eliminate some of those layers, while still reusing key components. That's the power of the simple layered approach. Examples of the power of this approach are in the myriad of Linux-based devices in the world, and the Android devices themselves.

Re:Unix way

[Unoti]

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

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

Re:Unix way

[Anonymous Coward]

which was fine for terminal applications 30+ years ago.

..and keeps getting even more desirable, as systems get bigger and more complex. It was merely a fine idea 30 years ago, but now it's so desperately needed that anyone who isn't thinking that way, looks like a total retard.

Re:Unix way

[siride]

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 and including a much larger set of libraries in the default install, which 3rd parties could depend on. Distros might include several different version of glibc, qt, whatever and then app vendors can assume that unless they are using a very old version, their app can install on any distro and just work without requiring a bunch of dependencies to be newly installed as well.

Re:Unix way

[sarhjinian]

But Windows Mobile is also getting smoked, for whatever reasons

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

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

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

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

Re:Unix way

[Unequivocal]

My experience is that junior coders are not aware of all the environmental resources they have available, and so they tend to write it themselves, not to prove mad skillz, but b/c they don't know about all the tools they can leverage in their environment (be it windows, unix or whatever).

Re:Unix way

[Rysc]

Sounds like you're describing just about every component framework ever created--at least in theory. Making it work in practice and not royally suck appears to be hard.

Re:Unix way

[Anonymous Coward]

Good programmers know what to write, great programmers know what to steal.

Re:Unix way

[RAMMS EIN]

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

That, but not only that. The programmers who came before them were smart, too.

But the creators of Unix had to work with severely underpowered hardware. This is what has motivated the simplicity of early Unix and early C. And this is why software that follows those ideas works so well on embedded devices, mobile devices, and, heck, everything that is underpowered compared to what other software is built for. This is why we have Linux on everything from wrist watches to supercomputers.

Re:Unix way

[Z8]

That other guy was really rude to you so I can see why you're upset with Slashdot, but you're _still_ trolling slightly in your message. That you have to develop for money is just a fact, but why throw "grow up" in there? It just implies that 1) you feel only immature people disagree with "the Unix way" and 2) grown ups don't have Linux programming as a hobby. Anyway, I can see why you get modded Troll, even if I think -1 is too harsh.

Re:Unix way

[dunkelfalke]

I always speak only for myself. But I've also got modded as a troll just because I admitted that I actually like Windows Mobile. Or that for my personal application area iPhone sucks compared to even a HTC Himalaya. Or that I nowadays prefer C# over C because I feel that C leads to a shoddy and insecure programming style.

I am neither a troll nor a Microsoft shill nor a stupid noob. I develop software for a living since 2002 and started programming almost 20 years ago.

Yes, this is offtopic but I honestly don't care, I've hit the karma cap years ago when you could still see karma points.

Re:Unix way

[Anonymous Coward]

What you call cryptic, I call Complete.

Re:Unix way

[mlts]

Before mid 2007, it was Windows Mobile versus BlackberryOS that were the high end choices for the smartphone market. Microsoft made the mistake of not shifting the OS from stylus-based input (as per PDAs) to finger-based as fast as they should have, and MS's offering got left in the dust.

People make fun of Windows Mobile but it is a good OS. It has a very simple, but very workable model for encrypting data on memory cards in WM 6 and newer, and can be wiped from remote either via Exchange, or Microsoft's MyPhone service.

I wish Android could take three features of Windows Mobile: SD card encryption (block level -- LUKS , or filesystem level like EncFS), support for Exchange wipe requests via remote, and the ability to have push E-mail. Samsung's phones offer push E-mail support, but it isn't a feature of Android, even 2.0. At best, most Android devices just check the Exchange server every 15 minutes.

Re:Unix way

[Qzukk]

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

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

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

Re:Unix way

[Draek]

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -- C. A. R. Hoare

Re:Unix way

[Anonymous Coward]

Some things just don't change. 100 years later, internal combustion engines still use pistons and crankshafts. Electrical systems made 50+ years ago still use grounds so someone sitting on an appliance doesn't get electrocuted if there is a short in a motor.

Same with computing. Something fine for terminal applications 30 years ago is likely something that still holds true today. Computers are still computers. We might have faster CPUs, better graphical displays, better networking, and USB powered fleshlights, but essentially we are still using the same architecture on almost all machines as we did in 1980.

Re:Unix way

[bensch128]

Of course the flipside is that it's easy to oversimplify and ignore feature which don't fit inside your design.

From the user's POV, the engineer is not being responsive to his needs and the application is "broken"

So, yes, simplisty is awesome from a maintenance engineering POV but actually kinda sucks when the feature just needs to get done.

Re:Unix way

[Anonymous Coward]

"Simplicity is the ultimate sophistication." - Leonardo DaVinci

Re:Unix way

[Tony Hoyle]

Android has had push email for years.. 2.1 even has a little desktop widget to turn the syncing on and off.

The exchange features are somewhat lacking (although you can buy some very nice apps to make up for that). I don't think that's android's market though.. RIM have the business market sewn up.

I reckon they're looking to usurp Nokia, who are very vulnerable either now, especially now their marketshare has dropped below 50% for the first time.. they've put out a series of smart phones that quite frankly suck (Symbian is beyond help and it's about time they ditched it)... they keep putting shitty resistive touch screens on everything.

Re:Unix way

[Anonymous Coward]

Blackberry does have the Exchange market, and to a lesser extent Windows Mobile, but one of the points which got iPhones in the doors of companies is the exchange support on the 3GS. The iPhone has encryption, and the ability to remote wipe from Exchange.

Android doesn't the full BES support that RIM offers, but it needs encryption of SD cards and other basic Exchange items so the device can be taken seriously in businesses.

And still ...

[Zarf]

... 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:And still ...

[Zarf]

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:And still ...

[SQLGuru]

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.

Re:And still ...

[Anonymous Coward]

Call it an "Intention". You either have or haven't an intent. You can have one or more intentions.

dumb article/crappy developer

[El_Muerte_TDS]

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

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

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

Point 2. The Tyranny of the Activity

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

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

Point 3. Device Debugging

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

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

Point 4. Applications Never, Ever Quit

but your icon stays in the list of running tasks

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

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

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

Re:dumb article/crappy developer

[FlyingBishop]

Point 4. Applications Never, Ever Quit

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

Re:dumb article/crappy developer

[Anonymous Coward]

Applications _do_ quit, by themselves, when the OS tells them to; the quit buttons you see in games and apps are usually there because they want to override the back button to stop you backing out of the app the way every Android app should.

Re:dumb article/crappy developer

[dskzero]

I don't think you read the article properly. Despite your undying love of google forcing you to accept everything from them (i'm liberally assuming here), there some legitimately complaints. 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. The main point to be taken of is the fact that everyone and their mothers will develop handsets with different quirks, which can easily ruin the OS as applications will not "simply work", as they do on Symbian or the Iphone. Either Google sends down the hammer of standards, or the OS is doomed.

Re:dumb article/crappy developer

[PianoComp81]

Point 2. The Tyranny of the Activity

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

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

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.

Re:dumb article/crappy developer

[Darth_brooks]

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.

Re:dumb article/crappy developer

[fredrik70]

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

Re:dumb article/crappy developer

[numbski]

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:dumb article/crappy developer

[Anonymous Coward]

The OS will kill idle apps as needed. Having free memory isn't doing you any good.

Re:dumb article/crappy developer

[El_Muerte_TDS]

The problem with that is that I might want to have music playing while I do other things like webbrowsing.

Re:dumb article/crappy developer

[Anonymous Coward]

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:dumb article/crappy developer

[El_Muerte_TDS]

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:dumb article/crappy developer

[entrigant]

It's a problem with developers, and it annoys the piss out of me. 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.

I don't know if it's because android is attracting developers that aren't use to multitasking on phones (e.g. iphone) so they don't even think of the need for a proper quit or if it's something else, but I hope they learn soon. I get tired of having to run a task manager to manually kill each app after I'm done using it.

Re:dumb article/crappy developer

[El_Muerte_TDS]

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

Re:dumb article/crappy developer

[GooberToo]

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:dumb article/crappy developer

[MikeBabcock]

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:dumb article/crappy developer

[extremescholar]

When you want to quit intentionally cause a seg fault, or exception, or equivalent thereof.

Re:dumb article/crappy developer

[MikeBabcock]

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 up to 1.6 via Cyanogen.

Re:dumb article/crappy developer

[FlyingBishop]

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.

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

Re:dumb article/crappy developer

[GooberToo]

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 specific application has widely been dubbed, "Advanced Battery Killer." Who would think that an application constantly polling in the background, consuming CPU, and using scarce memory would be an absolutely waste...lol...

Thankfully many savvy users are finally realizing that the task killer applications are as much a waste of battery life as they are a waste of dollars. In short, these types of applications prey on the ignorance of the masses and are completely counter productive while being the bane of other developers.

Re:dumb article/crappy developer

[GooberToo]

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 notion is, a cached application provides for a better user experience. By killing applications you require the system to reload it from flash. In short, you are actually making the system slower and actively working against Android's entire design.

Re:dumb article/crappy developer

[GooberToo]

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:dumb article/crappy developer

[GooberToo]

Actually, this is a developer sin.

Actually its not.

Why Task Killer is for ignorant fools... ....and why you're fighting Android...

Re:dumb article/crappy developer

[GooberToo]

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

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

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

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

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

Re:dumb article/crappy developer

[Unoti]

You're not missing something, you're right on. His point 5, tyranny of the commons, is generally not a problem. With the exception of services, apps don't keep on running. With regard to memory, each app is limited to 16M. That's generally a small enough value that in the minimum configuration for Android-- 64 megs-- the app can run. When the user switches applications, it is up to the OS to decide how long and whether to leave that memory allocated to your app.

If anything, the opposite of the tyranny of the commons is a problem: you can't really use all the resources available in the device in the app (for memory at least), potentially leaving the device underutilized.

Re:dumb article/crappy developer

[FlyingBishop]

Why doesn't it show up on my battery usage info screen?

Re:dumb article/crappy developer

[sarhjinian]

The system never actually runs out of memory, does it?

No, it just gets abominably slow and starts failing apps (eg, try using Maps' Traffic view on a G1: it will turn itself off almost immediately unless it's the only thing running. You can get around this by storing as much as possible on the SD card (or put off the problem by using a phone that isn't as hamstrung as the G1) but it's still foolish; doubly-so because it's making exactly the same mistake Windows Mobile did.

I hate to say it, but maybe Apple was right to make the iPhone most single-tasking?

Re:dumb article/crappy developer

[GooberToo]

So now I'm an accountant?

Bother to do some quick searches. You won't have trouble finding many recommending to uninstall the application so as to drastically improve battery life. And it makes absolutely sense. You can't get the information without polling the system.

This is just one example which was very hastily found via Google.

If you want to see significant battery life improvements, look at trying

Re:dumb article/crappy developer

[GooberToo]

Opps...

I hosed the last link...

If you want to see significant battery life improvements, look at trying WiSyncPlus. Unlike Advanced Task Killer, you won't have trouble finding people recommending that app.

Re:dumb article/crappy developer

[Ren Hoak]

ATK consumes a lot of battery? According to my battery info page (on a Nexus One), my phone was last unplugged for 3h 45m, and ATK doesn't appear in the consumption list at all. The only way ATK can be responsible for an appreciable amount of battery power draw is if its draw is rolled into something else. I would not expect it to be charged to the display (which took 78% of the battery use on that capture); the next highest energy use was by Android System -- which could contain ATK's use, but the system charge was only 6%. Nothing else in the list looks related.

Re:dumb article/crappy developer

[entrigant]

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

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

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

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

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

Re:dumb article/crappy developer

[esarjeant]

Coming primarily from BlackBerry development, I think this "platform fragmentation" is going to be a real challenge. While the general application architecture is neat, if the device hardware is tweaked for different devices this is going to make it increasingly difficult to develop for.

Until the BlackBerry JDE included pre-compiler directives, it was a nightmare to support different device hardware. To make matters worse, some hardware API calls (eg: GPS unit) were disabled by certain carriers even if the device supported it. Of course, the advent of the BB Storm brought a whole new world of hurt with a rotating screen not to mention all the new calls you needed to make for the keyboard to appear / disappear whenever needed.

Since nothing is backward compatible, a BB app compiled for the Storm with JDE 4.7 won't run on a 4.6 device. So the result? You end up with a different JAD file for each operating system version. Don't even get me started on having to sign your apps for the privilege of using "protected" system API calls. Everything runs fine until you get the program onto a real device where the privileged calls are rejected by the BB os and of course the universe of signed API calls changed from release to release as well.

Google may already be on the road to this El Dorado, I think they are going to need to define a reference platform that all Android powered devices must support. If they don't tackle this now, manufacturers will create variants on the core phone concept and the application marketplace will begin to fracture. The idea that you can build a Midlet and bring it from one device to another hasn't been successful, the display metrics of these phones are too varying and the capabilities of the hardware are diverse -- establish a minimal platform requirement for your applications (ala: iPhone) and this problem goes away.

Re:dumb article/crappy developer

[Anonymous Coward]

So just kill the task killer when you're done with it!

Re:dumb article/crappy developer

[Anonymous Coward]

actually, there is a built-in task killer:

Settings > Applications > Manage applications

if those are too many menu options to wade thru for you, you can make a direct shortcut to "Manage applications" on your desktop.

Re:dumb article/crappy developer

[FlyingBishop]

I don't see any evidence that it drains battery. It only tells you memory usage and what apps are in memory, and it only runs when you ask it to. It's not sitting in the background constantly polling (or at least the ad-supported version isn't.) Maybe this is a 'feature' in the full version?

Re:dumb article/crappy developer

[GooberToo]

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.

This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.

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

We were not broadly talking about badly behaving apps - though there are some. In this case, users should either contact the developer and report it as a bug or report it to google as a malicious app. The problem here is, most users are clueless as to the lifecycles of applications and they would almost always be wrong in their reports.

The only likely place you can nail an application is when you see a service running when its application has been terminated and you know for a fact that the application should not be performing background tasks. That's surprisingly common.

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.

Yes, I know, it highlights that you don't know what you're talking about. 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. Even when a developer requests an application to be terminated Android is free not do so, or to do so on a deferred basis. In fact, its not terribly uncommon for deferred termination to take place; only after Android decided another application needed the memory. As such, providing a menu item to terminate an application accomplishes exactly nothing - other than take up additional memory. 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.

My number one complaint for Android applications is, if the application creates a persistent service and it does not provide a means to terminate the persistent service, that's bad.

My number two complaint is, if an application starts at boot and fails to provide a means to disable auto start on boot, I consider that to be very poorly written. I should not have to spend lots of extra time at boot to start all these applications which I rarely run and do not provide real value by starting at boot.

Re:dumb article/crappy developer

[GooberToo]

From the provided link:

Also - not everyone seems to have this problem but I will tell you all right now my phone does a hell of a lot better without any kind of task/app killer than with it.

Its hard to prove a negative. Your anecdotal evidence is a far cry from proving a negative. Especially since part of the problem is that people often state not everyone is experiencing the issue.

Also, having it kill it self doesn't necessarily fix the issue as the system will naturally restart the associated service.

Re:dumb article/crappy developer

[entrigant]

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

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

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

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

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

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

Re:dumb article/crappy developer

[entrigant]

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.

This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.

Allow me to provide a single theoretical scenario that demonstrates the absolute truth of this statement:

I have a ssh session open in one app, and a rdp session open in another. Both apps are currently in the background. I start a 3rd app that puts a memory squeeze on the system forcing android to terminate one or the other.

The simple fact of the matter is android cannot infer which would be less disruptive to me. The only way to do this is to ask. Some operating systems would "ask" by simply refusing to start the 3rd app. Android will simply kill one and let the chips fall where they may.

All I ask is the chance to mitigate this behavior to the best of my ability by providing some control over what remains running. As I said earlier, the necessary code to provide an extra menu entry would likely fit in in the tail end of an already used memory page. Impact on memory usage would be 0.

Re:dumb article/crappy developer

[GooberToo]

How so? Do you have examples?

Its called caching. Fifos. Schedulers...etc.... all classically implement MRU algorithms for various purposes. All of which are the building blocks of just about every significant computer technology. They don't have to know your exact usage to provide value. They need only be close enough. The simple fact is, its doubtful even you know your usage pattern, if there is one at all. As such, its equally a good guess that most recently used (MRU) applications and/or services are also good candidates to remain cached.

Ever use a shortcut on Android? Very probable you just benefited from MRU caching. Want to take a picture and then review your pictures? Same thing...so on and so on...

themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."

You're looking at the specific - look to the abstract, which is absolutely topical. After all, MRU caching is exactly what's being stepped on here. Not exactly hard to figure out.

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.

Meaningless.

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

Learn to read. Then comprehend what you read. That's the way it is. Period. End of discussion. Get that into your head. Android has absolute control over application and service lifecycles - not the other way around. As part of the released guidelines, developers should be terminating their unneeded services - and that's the abuse. The same is not true for activities.

The primary problem is abuse of services, not missing menu items from activities. I've already stated what needs to be done about those. It doesn't change the fact that Android has 100% control over application life cycles - not the other way around. Period. Get that into your head! Service abuse places additional memory pressures which frequently causes thrashing of activities and services. The fact that services are abused is not proof that the android life cycle is broken, and in no way suggests that adding a useless menu item is a solution. Despite abusive services, Android's life cycle still works well.

Re:dumb article/crappy developer

[GooberToo]

Allow me to provide a single theoretical scenario that demonstrates the absolute truth of this statement:

I have a ssh session open in one app, and a rdp session open in another. Both apps are currently in the background. I start a 3rd app that puts a memory squeeze on the system forcing android to terminate one or the other.

The simple fact of the matter is android cannot infer which would be less disruptive to me. The only way to do this is to ask. Some operating systems would "ask" by simply refusing to start the 3rd app. Android will simply kill one and let the chips fall where they may.

All I ask is the chance to mitigate this behavior to the best of my ability by providing some control over what remains running. As I said earlier, the necessary code to provide an extra menu entry would likely fit in in the tail end of an already used memory page. Impact on memory usage would be 0.

That's nice and all, but let's get back to reality. Android doesn't work that way - which is what I've repeated said. Period. End of discussion. Adding a useless menu item is not going to change anything. Period.

No re-read my posts above about abusive services - to which the cure, in no way, shape, or form, has absolutely anything to do with menu items. Period. End of discussion.

Re:dumb article/crappy developer

[entrigant]

With a cache hit or a failed scheduler prediction the worst you face is a performance hit. Terminating an app due to memory constraints risks data loss. This is not a caching algorithm we're discussing. This is a "try really hard to do multitasking in a memory constrained environment without ever showing the user unpleasant error dialogs" issue. Apparently the android choice is silent termination without regard to consequences.

Also, I'm not sure where you got it in your head that I'm claiming this is not how android is suppose to work. I'm fully aware of that. The discussion is about the drawbacks and consequences. I admire the methods from an aesthetic standpoint, but the fatal flaw is it depends on app authors to play nicely. This is analogous to the problems faced by cooperative multitasking with regards to UI responsiveness.

I accept this is how it is with android, but I do not accept that it is the best method.

Re:dumb article/crappy developer

[entrigant]

How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive? The choice is potential data loss in one, or failure to start another. Android chose the former.

My new app will come up, and I'll be oblivious to the failure of the one that was terminated. Maybe I had an unsaved file in vi in a terminal. Whoops.. the front running web browser needed memory, so the connected was broken to kill the app. Bye bye data. At least I didn't have to be inconvenienced by a web browser that refused to start.

The point is I have to always be keeping this problem in mind while using the device.

Re:dumb article/crappy developer

[GooberToo]

How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive?

Android supports two types of services. The distinction is made based on how the service is started. Non-persistent services live as long as the application does and as such, has a foreground application-like life cycle. This life cycle is very memory friendly. Persistent services continue to run beyond that of the application. Far too often developers are starting their service to run persistently, often at boot time, which provides no benefit in the fact that its there. Thusly, its wasting both memory and CPU. The CPU cost is spent managing its life cycle and constantly loading/unloading it from memory.

As I previously stated, developers are creating persistent services when whey should not be doing so. As a result, the service sits in memory, doing nothing or nearly nothing. Developers who create persistent services but do not actually require a persistent service or do not provide a means to disable their persistent service or do not provide a means to prevent the service from loading at boot, are abusing Android's service facilities and drastically increasing memory pressures; especially one low memory devices. Large increases in memory pressures causes thrashing and high latency user interactions, which provides for a very poor user experience.

Here's an example. Application requires a login. User logs in and checks out the application. User logs out. At this point, there is literally nothing the service can do since the user is logged out. The service should terminate. Almost without fail, developers fail here. The same goes for many news and weather applications. Many don't provide for the user to simply poll at application start, thereby alleviating the need to have a background service running. The result is a service stays running 24/7 to obtain weather information once or twice in a day. The abuse and poor design of many Android applications are nearly endless.

If developers would simply fix their bugs (e.g. SQLite cursor leaks, service abuse), the memory pressures on your typical Android device would be drastically lowered and provide for a drastically superior user experience. As such, this is the real problem. Missing menu items are simply not a factor.

I would go out on a limb and say perhaps as many as 80%-90% of Android applications which use a SQLite database have memory leaks. Worse, many of these applications insist on creating persistent services. Even more insulting, the system even tells you there are leaks and you can see them spewed all over the place in the developer logs. Not hard to draw a conclusion on the negative effects this will have on a device over the course of a day or week; depending on the leak rate.

Re:dumb article/crappy developer

[GooberToo]

With a cache hit or a failed scheduler prediction the worst you face is a performance hit.

We have a winner. That's entirely the point!

Terminating an app due to memory constraints risks data loss.

Not in the android framework. In android, you can only *request* and/or *inform* that you're done service/activity is done. That's it. Android notifies you when the user has finished with your activity, thusly a menu item is completely useless because its *impossible* for it to do anything that you can't already do with the existing notification system.

Accordingly, part of the life cycle is to inform you that the system is terminating your application/service. There is a caveat that services can be terminated without notification but that only happens under extreme memory pressures and even then, Android provides facilities to allow you to maintain state and resume when Android automatically reloads persistent services.

Data loss is not a noteworthy concern.

but the fatal flaw is it depends on app authors to play nicely.

The fatal flaw is that it assumes developers are not morons. The fact that anyone can freely develop and the cost to enter the market is $25.00, means morons are openly invited. The fact that users don't know/understand the difference between a poorly written application and a properly written application only compounds the problem.

but I do not accept that it is the best method.

I never argued it was the best method. I do agree it has some shortcomings which assumes developers are not idiots and actually know how to use the framework.

Re:dumb article/crappy developer

[GooberToo]

Ya, replying to myself.

I will add, if data loss is to happen, its far more likely to happen with the use of applications like Advanced Task Killer as it just kills applications without informing them; which violates normal life cycle of applications and services. Which means, white technically it would be an application bug, its likely to trigger the least tested save/recovery code in the worst way, on a regular basis.

But then again, I already argue using applications like ATK is for users who don't know any better anyways. I would never advocate its use.

Re:dumb article/crappy developer

[entrigant]

I believe we mostly understand each other now, and I want to thank you for keeping the thread going and discussing this with me.

I do have one final question maybe you could answer, however. Can an application indicate to android that it cannot save its own state because it does not control it (e.g. text editor in ssh)? The idea being perhaps failing to start the app that needs the memory might be a better action than terminating the existing app that cannot be terminated without loss of state

It seems based on this discussion that the front running app is king of the hill, and android would do anything possible to start it than present an error condition.

Nitwit suffering from Stockholm syndromw.

[140Mandak262Jamuna]

I read the stupid article and the author is a stupid attention seeking Stockholm syndrome suffering nitwit. Complains the use of the word "intent" of all things as a super class or an API construct. Oh, yeah go ahead and argue with the word subroutine and goto without a space when you are it. Wants the developers to be enslaved by a tyrannical system a la iPhone app approval process.

What I understand from the article is exciting. I am not a mobile device developer, but looks like Google is trying to create fundamental tools like grep, awk and sed in the mobile GUI world. If that is what Google is trying to do, it is a very wise thing. Some 40 years after debut grep, awk and sed are still going strong and power users use it every day. Even when command line interface is disappearing and text files are no longer the main repositories of data. But an updated set of such fundamental tools with a well integrated GUI and the ability to handle more forms of data would be a radical.

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.

Re:Nitwit suffering from Stockholm syndromw.

[ardiri]

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:Nitwit suffering from Stockholm syndromw.

[lokedhs]

You are perfectly right.

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 prepared to handle an Intent, the user gets an option to choose withich one should be used, and can store that as a default for the future.

Everything uses Intents, even basic functions such as sending an SMS, which is why alternate SMS applications works completely transparently. Another Intent is the one that displays the main "desktop". Again, no need to be limited to the default desktop application.

Just because no other mobile OS'es gets this right, doesn't mean that Android is wrong.

Re:Nitwit suffering from Stockholm syndromw.

[Ukab the Great]

Stockholm syndrome? No.

A better metaphor is that Apple's like a strict parent, and Android developers are like the know-it-all teenagers who drop out of high-school because they "don't need all these people's rules" who then get smacked in the face with the stone cold reality of why their parents were so strict about them graduating.

Re:Nitwit suffering from Stockholm syndromw.

[narcc]

Intents are a very good idea. Android just does intents in the worst possible way.

Well, that's my whole opinion of Android really. A few really good ideas implemented in an astonishingly poor way.

Re:Nitwit suffering from Stockholm syndromw.

[lokedhs]

Care to explain how you feel they could be improved?

Who says Google talks clearly?

[jonaskoelker]

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.

veteran mobile application developer ?

[ardiri]

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

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

>> 3. Device Debugging

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

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

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

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

>> 8. Platform Fragmentation

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

Re:veteran mobile application developer ?

[sznupi]

Apply your interpretation of 3 to point 8.

Seriously, why the sudden 1800 degree turn?

Re:veteran mobile application developer ?

[e2d2]

Show us on the doll where Chris Haseman touched you.

Re:veteran mobile application developer ?

[ardiri]

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

Re:veteran mobile application developer ?

[ardiri]

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

Re:veteran mobile application developer ?

[sznupi]

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:veteran mobile application developer ?

[Anonymous Coward]

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

It will be a problem...
"Hey you have the ultimate application on your "Android" phone? Can I have it?"
"Sorry, I have the HTC Andydroid and you have the Moto Droidinator and it isn't compatible. There's some obscure bug that not even Google Search can find an explanation for."

Re:veteran mobile application developer ?

[Unoti]

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.

Really? Perhaps this is true if you're selling to a market where it's easy to control what kinds of devices the users will use-- say, warehouses or something, where the users are buying hardware for run your software. But for applications you intend to sell on the app marketplace, you use C++? Doesn't that mean you need to compile different versions for specific hardware platforms? I'm not saying you're wrong, I'm just interested in knowing how the real pros that know what they're doing do. Can you show me an app on the app store that's been developed in C++?

Re:veteran mobile application developer ?

[ardiri]

for applications you intend to sell on the app marketplace, you use C++?

YES!

actually; we use C basically - on iphone; you need to have some objective-c wrappers to handle the device specific execution entry point. on symbian; you need C++ classes for the the framework base.

you do need to re-compile your binary for every PLATFORM (not device). if you want to see it in action; check out http://www.mobilewizardry.com/multi-platfori/atariretro/ (commercial applications) and http://www.mobile1up.com/ (iphone, desktop apps) - this is what i specialize in. when i hear about platform fragmentation i laugh. be a good architect - and your problems are solved.

all our applications BUILD NATIVE - so, there is no runtime environments required and we have binaries optimized for the platform. when a new platform comes; we simply rebuild utilizing the tools and/or minimal custom coding for the execution frameworks

Re:veteran mobile application developer ?

[ardiri]

my point is he shouldn't be complaining about good debugging environments. be happy and thankful he doesn't need to deal with printf() for debugging.

Re:veteran mobile application developer ?

[Unoti]

Interesting. So you've got linux as a platform, plus windows, plus iPhone. But for Android, wouldn't you need to compile it differently for say, Droid vs Droid Eris vs HTC Hero vs... ?

Re:veteran mobile application developer ?

[ardiri]

actually; the platform i'm built has layers for:

- palm os (68k)
- palm os (arm)
- tapwave zodiac (drm specific)
- windows mobile / pocket pc
- vtech helio
- symbian s60
- symbian s60 (3rd+) (binary break)
- symbian uiq,
- ebookman
- gizmondo (gaming handheld)
- sony psp (homebrew)
- windows desktop (95+)
- linux
- moblin (drm specific)
- mac osx
- iphone / ipod touch
- android (in beta now)

the platform is just a target when we compile :)

for android; we have a thin Dalvik application that gives us a window; from there - we have a native call using the NDK to render the framebuffer that we show as a window within the application itself.

you would NOT build different versions for droid, htc hero, G1 etc.. as long as they use the same CPU architecture (ARM in this case); the applications will work across the various devices.

depending on the phase - we have the various platforms running at the latest version; the key point is our applications use a common source code base - so, adding/removing a platform does not require any changes to the application itself.

if you have further questions - please don't hesitate to contact me. we've been building this layer for over 8 years now - and we have seen platforms come and go! our framework has been used commercially; but as a platform - you don't see it when it is being used.

Re:veteran mobile application developer ?

[DissociativeBehavior]

A true mobile developer demands a native C/C++ interface on mobile devices

A C/C++ interface requires an OS supporting virtual memory and exception handling. Many low and middle end phones only have a simple real time OS with a flat memory space, and no exception support. A memory access violation usually results in a reset.

One of the advantage of a Java VM is that it requires minimal support from the OS and implements all the security required to isolate the application from the rest of the software.

Plus on modern implementations, the java code is almost equivalent to native code: - the most frequently used methods are compiled on the fly - the critical APIs are declared native, meaning they are written in C and not in java.

Re:veteran mobile application developer ?

[ardiri]

wow.. you surely must not get it.

what do you think the JVM is written in? JIT support is NOT available on mobile implementations typically . your confusing the advances in desktop Java vs the mobile versions.

C does not require any virtual memory / exception handling.. and most C++ support requires you disable it anyhow. if you screw up your memory access; of course it'll reset - thats something you'll learn as a mobile developer.

Re:veteran mobile application developer ?

[DissociativeBehavior]

Modern VMs use bytecode compiling, even on mobile platforms. Sun has even open sourced their latest implementation (see https://phoneme.dev.java.net/) C doesn't require virtual memory/exception handling, but without it any application can crash the phone or dump the whole memory map.

Consider the source

[Rogerborg]

Chris Haseman is an independent software engineer specializing in wireless development. He can be found riding his bike between coffee shops in San Francisco. He's the author of the book Android Essentials (published by Apress). In his spare time, he's a resident DJ at xtcradio.com and a martial arts instructor.

Also, I hear he's fluent in Sanskrit and can divide by zero.

A smug superficially supercilious fuck-knuckle hates Android? Well, I guess I'll give it a second look then! I know which 'essential' book about it to avoid, at least.

Re:Consider the source

[Anonymous Coward]

Chris Haseman is an independent software engineer specializing in wireless development. He can be found riding his bike between coffee shops in San Francisco. He's the author of the book Android Essentials (published by Apress). In his spare time, he's a resident DJ at xtcradio.com and a martial arts instructor.

Also, I hear he's fluent in Sanskrit and can divide by zero.

A smug superficially supercilious fuck-knuckle hates Android? Well, I guess I'll give it a second look then! I know which 'essential' book about it to avoid, at least.

As I write this was modded +3 insightful. Seriously Slashdot, some decorum please.

Re:Consider the source

[mcgrew]

Also, I hear he's fluent in Sanskrit and can divide by zero.

I can divide by zero. The answer will be incorrect, though.

Debug on the Underdog

[Anonymous Coward]

Hey, I've been debugging for years on Windows Mobile...so, what's the story?

Re:Debug on the Underdog

[dunkelfalke]

Debugging is actually extremly comfortable if you develop with .NET and visual studio.

I'm not a coder however...

[AbRASiON]

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 like android is a bit of a concern.
There's always positives and negatives in open and closed systems and this is a pretty distinct point, the question is though, what's the solution and who is going to get on it fast?

I'd like to see it solved because I do quite like my iphone but sadly I finally cracked the shits with it being so locked down and jailbroke it. It's better now but I /shouldn't have to/ .... would like to see an open platform at least be 1/2 as popular as the iphone.

We'll see I guess..

Arghh, 180 degree of course...

[sznupi]

(as the topic says)

Obviously an inexperienced Android developer

[Maxmin]

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

(Potential) iPhone Developer's Top 1 Gripe

[Comboman]

1. SDK only available for Mac.

why Java?

[ShenTheWise]

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)

Re:why Java?

[iamapizza]

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.

Re:why Java?

[fredrik70]

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?

[Josh04]

Neither 1 nor 2 is an argument for not using java, and 3 isn't really applicable as not only is it optimised for it's own version of java, but you have the option of writing C anyway.

Re:why Java?

[furball]

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:why Java?

[Unoti]

3 isn't really applicable as not only is it optimised for it's own version of java, but you have the option of writing C anyway.

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 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:why Java?

[GooberToo]

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 readily available, Dalvik will be 10x-500x slower than native code; depending on the nature of the code.

Re:why Java?

[DrXym]

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.

It isn't a myth, at least not for desktop profile apps and higher. I regularly build Java applications exclusively on one platform and encounter minimal issues when they run on a completely different platform. Usually when these problems occur they are my own fault - path issues and the like.

Even on embedded devices such as J2ME, as long as you code to the relevant profile you stand a reasonable chance of your app running on other devices that comply to that profile. Even if you do encounter problems I guarantee you they are an order less complex than having to rebuild, repackage and redeploy binary executables for disparate platforms.

It certainly wouldn't hurt for Google (+ Android phone manufacturers) implementing some form of compliance testing because there would be nothing worse for the platform than if it shattered into dozens of semi compatible versions of the same thing.

Re:why Java?

[Unoti]

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.

Here's where I get that impression. I'm working on an RPG game for Android. I have about 3000 objects in the game world, of which maybe 30 are visible at a time. Of course I'm going to need to implement quadtrees to efficiently traverse the data and figure out which things need to be rendered on screen. But before implementing quadtrees, I put in an ultra-naive brute-force loop that goes through all 3000 objects every frame. To my utter amazement, that naive implementation runs just fine on the Droid and the emulator, with a framerate that performs just fine. Going through 3000+ rectangles every frame, checking to see if the viewport rectangle intersects with each world object-- I fully expected that the pretty much not work at all.

Turns out, when profiling the application, the act of bitmap drawing of the tiles is where nearly all of the time is being consumed, and the traversing of this big data structure is comparatively nothing. Thus, I was surprised at the speed of the code, for my application. If I was calculating fractals or something my story would be different I'm sure, but for me, I was surprised at the speed of code execution.

Re:why Java?

[GooberToo]

That's the difference between, "fast enough" and, "surprisingly fast".

I never said Dalvik wasn't "fast enough" for many simple applications. Otherwise Android would be DOA.

Re:why Java?

[Maxmin]

2) You cannot build once run everywhere. Its a myth.

You're confusing the language with the API. Of course an Android app won't run on a J2ME device, because they COMPLETELY DIFFERENT APIs. That'd be like expecting Windows ME apps to run directly on Windows 7. But if you're writing to pure vanilla J2SE, you *CAN* write once run anywhere, given equivalent API versions.

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?

What's good about Java, and in particular Android, is the separation of high and low-level operations. Sure, it'd be great if we all could code our apps in C or ASM, we wouldn't need Moore's Law to pull some of the beefier OSes and apps out of the swamp, now would we? But we don't all have your programming skill level.

For games on Android, there's OpenGL ES, which provides support for both GPU and emulated GPU operations, allowing for very speedy games.

Re:why Java?

[SoftwareArtist]

Android's dalvik engine is widely known to be roughly 20x slower than most other non-JIT'd java VMs.

Could you give a reference for that claim? I've certainly never heard it before, so I'd like to know what it's based on.

Re:why Java?

[GooberToo]

Search Google's developer groups. There you'll find various benchmark statements as well as benchmarks referring to the anticipated, initial Dalvik JIT implementation. Some of these also come from the NDK groups - which make the need for the NDK obvious.

Re:why Java?

[SoftwareArtist]

I just did a search for "dalvik benchmark" on on the Android Developer group. The only result I found was this one: http://groups.google.com/group/android-developers/browse_thread/thread/1fc0d84e6f8ec080/80b9df7a8cd2584a/ It claims that the experimental, in development JIT for Dalvik is about 20x slower than modern, JIT enabled VMs. That's hardly surprising, given that the developers have explicitly said that it's still under development and doesn't do much optimization yet. And that's completely different from your claim that interpreted Dalvik is "20x slower than most other non-JIT'd java VMs." That claim is not supported by any information I could find, and in fact seemed to be widely contradicted.

Re:why Java?

[GooberToo]

Keep searching. And I'm sure you'll be searching and reading for while. The JIT stuff is somewhat new. The rest is fairly old; spanning over the last year or so.

And I have no idea why you believe the post above is contrary to my assertion. Think about it. That compares JIT to JIT. I stated non-JIT to non-JIT. Neither is contrary.

Re:why Java?

[SoftwareArtist]

The same post stated that the JIT version was about 1.7 times faster than the non-JIT version. In my experience, most JVMs are 50-100 times faster with the JIT than without it. Applying those factors suggests Dalvik is significantly *faster* than most JVMs without JITs.

Again, if you can supply a specific reference to benchmarks that support your claim, please post it.

Re:why Java?

[bingoUV]

Keep searching. And I'm sure you'll be searching and reading for while

I find it more likely (and simpler) to assume that you just lied to appear smart. Burden of proof is on you.

Re:why Java?

[GooberToo]

Actually the burden of proof is on you because I couldn't care less if you believe me.

Option one, I spend lots of time trying to find various articles I've read over the span of a year plus trying to convince some douche of a fact that doesn't significantly matter. Even more so, your ignorance doesn't negatively affect me.

Option two, you spend the same amount of time doing option one for yourself. This means you're smart and can research and are interesting in learning.

Net result, option one would make me an idiot. Option two would educate you whereby you'd likely learn a lot more about android which you didn't already know. Since I'm not an idiot, you're only option is option two.

Tell me, when you have a conversation with someone and they tell you something you didn't already know, do you call them a lair and then wrestle them to the floor to force them to do YOUR research? If you don't, you're a hypocrite. If you do, you're likely writing this from jail or prison. Contrary to the popular trend on the Internet, your ignorance is not someone else's responsibility. If you don't want to be ignorant, do you're own research. I don't owe you anything and neither does anyone else on the Internet. Grow up.

Re:why Java?

[GooberToo]

How in the world did you deduce that 1.7x performance improvement while comparing it only to itself translates into Dalvik being significantly faster than other non-JIT JVMs? That makes absolutely no sense whatsoever. Strongly smells of disconnect from reality and an over abundance of blind Android fanboy-ism.

One example of something I remember reading is one dev talking about how his code was typically fast enough on other non-JIT mobile JVMs and that his code on Dalvik is at least an order of magnitude slower (hmmm...sounds familiar does it...), making the application unusable. His only recourse was to rewrite code via the NDK or wait and see what the upcoming JIT solution will provide for his code. Given that this is representative of typical feedback and Google absolutely doesn't disagree, how in the hell can you possibly believe that Dalvik is at all comparable to other non-JIT JVMs based strictly on relative comparison to it self? You can't unless you're blind to the facts and don't want to know the truth.

Manipulating linear memory, one byte at a time, is an especially poor performance case for Dalvik. This is why basic image manipulation almost always has to be done in native code (user library) and/or OpenGL (which calls back to native code) on Android.

Re:why Java?

[SoftwareArtist]

How in the world did you deduce that 1.7x performance improvement while comparing it only to itself translates into Dalvik being significantly faster than other non-JIT JVMs?

Dalvik JIT speed = 1.7*Dalvik non-JIT speed
JVM JIT speed = 20*Dalvik JIT speed
JVM JIT speed = 100*JVM non-JIT speed


Trivial algebra yields

Dalvik non-JIT speed = 2.94*JVM non-JIT speed

Re:why Java?

[bingoUV]

.... I couldn't care less if you believe me. ... ... I don't owe you anything ...

Right. Which is why you made this reply. Cool.

Tell me, when you have a conversation with someone and they tell you something you didn't already know

It wasn't this. You told me something that I strongly suspected to be false and subsequent research proved that it was even more likely to be false than I thought earlier. Never got an exact reliable study to directly prove/refute it. Add to it your refusal to give links, pointing to google groups which gave somewhat opposite results. Enough time to spend on an idiot trying to appear smart.

Just wanted it to be put on record because modders are at times affected by bluff like yours.

Re:why Java?

[GooberToo]

Add to it your refusal to give links,

Absolute proof you're a fucking idiot. And a lazy fucking idiot at that. Nuff said.

Re:why Java?

[GooberToo]

Okay, I missed the JVM jit speed there...but that still only shows median performance of existing dalvik applications, not worst case. The worst case is significantly slower. Remember, the worst case means those Dalvik applications don't exist because its not usable.

Which brings us full circle, I'm still right.

Re:why Java?

[bingoUV]

Can you elaborate on that?

Re:why Java?

[Tony Hoyle]

That's going to mean you have to produce a different app every time a new phone comes out with a slightly different CPU. Or you'll force the platform onto a single CPU model which would in the long term kill it.

Take if from an Android Dev

[derek5432]

This guy is a moron. Most of his "gripes" aren't even real gripes (e.g. the tools are too helpful!). The others aren't legitimate, except perhaps fragmentation, but that's inherent in the whole point of Android and the SDK has done a pretty good job so far of either letting you design for compatibility mode (in which Android tries to figure out the best way to render your UI) or design for 3 broad categories (basically small, medium, and large screens). The guy really tips his hand when he talks about how Android hardware sucks. Check out this chart: http://mashable.com/2010/01/05/nexus-one-vs-droid-vs-iphone/ In terms of specs like screen and camera resolution, battery life, chipset, etc., the newest generation of Android devices are either comparable or surpass the iPhone. The really stupid aspect of this article is that there are legitimate gripes about the platform that the author completely ignores. Huge on the list should be the inability of Android to run apps from the SD card, and thus the constraints on available space for apps on a device. The market still has all kinds of problems, the most dire a need for a decent desktop portal, something somewhere near comparable to iTunes. As far as the actual SDK, particular APIs are a chore to use (Google Maps, for example), and though Google rolls out new features with every SDK, they are often poorly documented (e.g., the new Account Manager API). All in all, Android is great to develop for. But like every platform it's got its problems, and if you're going to gripe about it, do it right.

Re:Take if from an Android Dev

[mlts]

You *can* run apps from the SD card, but it takes rooting and unionfs to do so. Something I would not recommend to anyone who does not have both a UNIX background, and a bit of modding experience. Similar with enabling swap so the phone doesn't run out of memory.

I know Google did this for security (because SD cards do not have a filesystem that supports UNIX permissions, so one app can mess with another if it is on the card.) However, what would be nice is if Google would dig up the long dead UMSDOS filesystem project and consider using that to enforce permissions on removable media. This way, the SD card can appear as a FAT or FAT32 volume when attached to a computer, but on the phone, permissions would be enforced by the OS and the "--LINUX-.---" files in directories. As an alternative to this, have a loopback mounted partition on the SD card that supports ext3, YAFFS, or a similar filesystem that handles UNIX style permissions.

Re:Take if from an Android Dev

[ppanon]

Huge on the list should be the inability of Android to run apps from the SD card

Mebbe so. But that also shuts down a significant vector for viral malware and worms since SD cards are going to be one of the main physical vectors for data exchange. If you're not going to have a locked down phone which checks centrally signed code signatures, this feature is pretty important to limit malware attack vectors.

He Calls Himself an Android Developer?

[mrpacmanjel]

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 like an anti-aliased font library. The vm that "runs" the android platform is absolutely fine for every day stuff like email apps and "fart" applications!

9. A General Lack of 'Evilness'
This lack of an iron grip (which both Apple and Verizon have effectively, if obnoxiously, employed on mobile developers) is exactly what is leading to the current and future fragmentation..Google, with luck, will learn when it's good to be evil

10. Hardware, Hardware, Hardware
The current crop of Android hardware, for lack of a better word, sucks..

He MUST be JOKING - must be!
He MUST be naive.
Quite frankly I have lost the will to comment further except

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.

I hate to think what he could have said if he hated Android!

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.

He should really go and develop for the iPhone or Windows mobile instead. Both these platforms are more aligned with his way of thinking!

Lack of support for wi-fi proxy

[Anonymous Coward]

I don't understand why this doesn't get more attention, or even some basic acknowledgment from the Android team. Lack of a wi-fi proxy means that Android devices are basically useless for corporate/school wi-fi networks.

When I connect my iPod touch to the corporate wi-fi, I can access the web. When I connect my Hero to corporate wi-fi, I cannot. This is a defect.

Re:Lack of support for wi-fi proxy

[gregarican]

It appears to be on their bug list.

Re:Lack of support for wi-fi proxy

[Anonymous Coward]

Yeah, but missing from the comment section are the magical words "This issue has been assigned to an engineer for evaluation"

Google's main interaction with the issue has been to re-tag is as an enhancement instead of a defect (effectively lowering its priority)

Re:Lack of support for wi-fi proxy

[Anonymous Coward]

Android also needs a good model for connecting to multiple VPNs. This is something that Windows Mobile handles robustly. I can connect to a secure wireless network, then fire up a VPN client, so all my communication is tunneled to the corporate site.

This, I can't do under Android, yet. And until this is not just doable, there will be issues with this platform in the enterprise.

I have high hopes though. Android has gotten very far in the past 14 months since the G1 was released. I'm sure that Google should have support for encryption and robust VPN clients by 3.0.

Worst cast, one will find a custom ROM with Linux kernel modules, and one would just manually do this stuff the age old way, PPP over ssh, or pptp.

It's supposed to be funny!

[Anonymous Coward]

Retards.

Why isn't this on idle?

[AlXtreme]

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?

5. Developer Cooperative

[Unoti]

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:5. Developer Cooperative

[GooberToo]

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

Re:5. Developer Cooperative

[Unoti]

It's true that I can recompile the OS and raise the memory limit. But that's not helpful when I am developing apps to sell on the app store. I generally need to support the least common denominator when developing apps. The least common denominator is 16 megs:

the baseline Android memory class is 16 (which happens to be the Java heap limit of those devices); some device with more memory may return 24 or even higher numbers.

In practice, is the amount of available ram actually higher than 16M on most platforms? I haven't bothered to check what my droid returns for ActivityManager.getMemoryClass(), and I don't have a HTC or any other Android phones. As a practical matter, am I over-constraining myself by limiting myself to just 16 megs?

Re:5. Developer Cooperative

[GooberToo]

It's true that I can recompile the OS and raise the memory limit.

I never said that. That would silly. I said check to see if the limits can be determined at run time so you can allow for larger limits, if you so wish. Otherwise, you'll be forced to only support the L.C.D.

In practice, is the amount of available ram actually higher than 16M on most platforms? I haven't bothered to check what my droid returns for ActivityManager.getMemoryClass(), and I don't have a HTC or any other Android phones. As a practical matter, am I over-constraining myself by limiting myself to just 16 megs?

I left that as an exercise for the reader as I don't know the answer my self. What I do now is that 16MB is likely not a fixed limit across all phones. And even if it is currently a limit across all phones it likely won't be over the next year or so as new hardware is introduced. So being adaptive may be a strategic advantage.

Re:5. Developer Cooperative

[cynyr]

have you thought about not storing the image as an image, but rather just create it on the fly? I remember a while back someone wrote a FPS where all the graphics and textures were generated on the fly.

Re:5. Developer Cooperative

[Yeroc]

Take it as a challenge. Programmers of 70s & 80s did amazing things with limited memory and CPU. We're largely spoiled nowadays and often don't have to pay attention to memory usage or CPU usage. Being forced to pay attention to these details will make you a better programmer in the end.

Re:5. Developer Cooperative

[pjt33]

No support for palettes? Or do you really need 32-bit colour?

Your books sales... down!

[cshinobi]

What the hell are you talking about? Open source a bad thing?!?! That means more apps and more... so much more to choose from. New and great debugging tools a bad thing!?!! What! That's like saying you love to write large webpages in notepad. Time is money mate! As an independent developer you should know that. I didn't read anything other than what I commented on above. This article was so sad. In conclusion I think this dudes blowing of steam because Google just made his book useless.

Re:Your books sales... down!

[Anonymous Coward]

What the hell are you talking about? Open source a bad thing?!?! That means more apps and more... so much more to choose from.

New and great debugging tools a bad thing!?!! What! That's like saying you love to write large webpages in notepad. Time is money mate! As an independent developer you should know that.

I didn't read anything other than what I commented on above. This article was so sad.

In conclusion I think this dudes blowing of steam because Google just made his book useless.

maybe you should learn to read before you waste your time looking like an idiot. that bullet is ironic, the author writes about how awesome open source is.

hehe, next time read before posting ;)

Re: Security

[Unoti]

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 will do in order for it to have access. When you download or install an app, you are shown what privileges the app will have, and you can accept or deny. So you definitely won't be downloading a tower defense game that can steal your contacts and mass mail out Gmail, because you wouldn't grant the permissions. It'd have to be a contact manager or other type of app that it'd make sense for it to have such access. And a malicious contact manager app would probably get poor ratings, and would probably suck anyway and get even poorer ratings.

Its called "sarcasm"

[Anonymous Coward]

LEARN IT, BITCH.

WRONG: Test NOT done by Motorola

[alteran]

The touchscreen test was done by MOTO labs, not Motorola. Not affiliated with Motorola in anyway.

They don't seem to be crypto Apple-fanbois, though. For what it's worth, in the real world, I have a G1, easily the crappiest Android device out there. I have no detectable issues with the touchscreen. Doesn't shock me that Apple's tracks better, but as a fairly aggressive user of the G1, I just haven't come across a need for whatever accuracy is supposedly missing.

My iPhone #1: will Apple accept App?

[peter303]

You dont know whether Apple will accept the App or not until you finished and submitted it to Apple. By then you have invested man-months of developer time and maybe some marketing bucks too. The acceptance rate is pretty high. But there are horror stories such as mention in the CNBC Plant of the Apps documentary.

your comment... it's self redundant :)

[roman_mir]

I think you have just created a comment that deserves to be assigned the 'redundant' score because it is redundant with itself.

Look:

Simplicity is hard.

- this is good.

Programming the Unix way requires a person to focus on radical simplicity.

- not too terrible just yet.

The benefits are huge.

- very good.

but now we see this one:

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.

- see? You have done it. You should have stuck to the short sentences - one point in, point out. But no, you had to go there and there you have it: the proverbial

then

.

It's eaiser to debug 200 lines of simple code THEN it is to debug a class etc. etc.

I don't have the moderator points right now, otherwise instead of leaving this comment here I would have done the correct thing. You know what it is.

Re:your comment... it's self redundant :)

[drodal]

That was clever in a recursive way.

Re:your comment... it's self redundant :)

[roman_mir]

(Score:1, Redundant) - I fully expected that :) but to be true, it's not redundant, it's just off-topic. (I fully expect the obvious consequence here also.)

self-deprecating points in TFA and the parent

[roman_mir]

This:

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

Java - probably the worst language used on mobile devices to date.

and this:

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

Java is the answer to platform fragmentation.

Re:self-deprecating points in TFA and the parent

[ardiri]

Java is he answer to platform fragmentation?

no it isn't - it is in *design* - not in practice.

Java provides the classic write once run anywhere; have you ever tried to build a J2ME client? do you know how many skews you have to build to support all the phones? so much for write-once-run-anywhere.

secondly; since mobile devices are underpowered - you need speed/fast applications to make them useful. Java runs on top of a VM - VM's are slow. you are looking at 20x speed slowdown; and there is no JIT (just in time) compilers available on mobile phones.

Java belongs on the desktop and server - not in the mobile space. you can argue as much as you want - i left Java programming to get into mobile development back in 1999. i've got years of experience within this area; surely more than the author of that article.

He's right and he's wrong

[amoeba1911]

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

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

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

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

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

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

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

Re:He's right and he's wrong

[BitZtream]

Compare that to iPhone, you need to pay $100/year to get the SDK

Just for reference, this is not true.

The SDK and emulator are free, you only pay to use the app store or install arbitrary code onto your own devices.

I can see his issue

[Anonymous Coward]

2. The Tyranny of the Activity
6. Java—Thanks, But I'll Take It from Here
7. "Intents"

Sounds to me like he's just not comfortable with Java OO development.

This (fully Java based API on top of POSIX kenel) is the future. This is where Linux desktop should be. The reason for the sad state of the Linux desktop is that C API make it too difficult to create applications more complex trivial. At this point the choice is between .NET and Java. Of course Google choose Java.

I have been looking at the API and the architecture of Android and I am very impressed. It looks very UNIX'ish in many areas. Just consider how they deal with "process groups". It's like POSIX process groups taken to GUI applications level.

What is the opposite of damning with faint praise?

[shoor]

The author seems to be praising Android with faint damnation.

Hit and miss, some good points

[Zigurd]

The gripes are, unfortunately, mostly off target. But you can't blame a developer for having gripes. They deserve an answer. So here goes:

1. Open Source

The heart of this gripe appears to be "What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. "

This is a non-issue. Google hasn't released any proprietary code. Using the capabilities of these applications, or any other FOSS or proprietary applications in Android by means of their remote method interfaces or their Intent filters is OK unless the APIs require a key, as with the maps APIs. The process of getting a Google Maps API key is described here: http://code.google.com/apis/maps/signup.html and most introductory Android programming books cover it, too (http://www.amazon.com/dp/0596521472 in chapter 7). J2ME, BREW, and Symbian all require app signing and all support protected APIs.

2. The Tyranny of the Activity

Android has a unique programming model. It wasn't designed just to make a coder's life difficult. It was designed to prevent a small-screen UI from becoming a maze of hierarchical screen transition and enable re-use of functionality across applications. Android makes "shoveware" ports look bad, which is what Haseman seems to be griping about.

3. Device Debugging

This "gripe" is not really a gripe, but good-natured praise for the ease of debugging on Android.

4. Applications Never, Ever Quit

Android has an interesting and powerful application lifecycle. And, since Android is multi-tasking, more developers will notice that their application has a lifecycle.

5. The Developer Cooperative

This is a valid gripe: On the one hand, Android can manhandle your application's lifecycle, and on the other hand, it is fairly easy for applications to become battery-eaters. Google's developers could have done a better job of automatically detecting battery vampires. Use the "Battery use" in the "About phone" menu in "Settings" to find the applications and other system functions using the battery. That's a tip taken from this article: http://answers.oreilly.com/topic/862-ten-tips-for-android-application-development/

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

Haseman says: "While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one."

Java in Android runs on the Dalvik VM, which, up to now, is a pure interpreter: No precompiler, no JIT. It relies completely on the ability to mix in libraries in C via JNIs http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/jniTOC.html and the NDK http://developer.android.com/sdk/ndk/1.6_r1/index.html.

Why? The short answer is it is hard to put a JIT compiler in a battery powered device. So the developer has to decide what code belongs in Java and what code belongs in C.

7. "Intents"

Here I am right with Haseman, since his gripe is having to write (http://www.amazon.com/Android-Essentials-Firstpress-Chris-Haseman/dp/1430210648/) about classes with names that lend themselves to drifting into being nouns. The Activity, Intent, and Service classes in Android twist up one's prose worse that quarks tha

Re:Hit and miss, some good points

[YourExperiment]

7. "Intents"

If you'll forgive me replying to the most trivial of the ten points: I really don't see what the problem is here. Intents, Services, Activities. They're all nouns, none of them have any problem with being plural, writing with them doesn't seem the least bit stilted to me.

e.g. "My intents in posting this reply are firstly to point out the error in the author's thinking, and secondly to demonstrate that I am an annoying grammar nazi. Having availed you of my services in successfully completing both of these activities, I shall now leave you in peace."

and it's fine for mobile too!

[WebCowboy]

fine for terminal applications 30+ years ago

It seems to me that is an argument FOR "the UNIX Way" today. Think about why this "way" came about. You had expensive mainframe or mini computers with computational abilities probably even more limited than today's mobile phones, with a user interface with limited display capabilites tied to that system therough a slow serial link with constrained bandwidth, and CPU cycles were a limited, sometimes expensive commodity offered by a limited number of organisations.

Fast forward to today, and what Google is trying to achieve:

Google has this, well, expAnsive array of servers worldwide to provide applications and services in "the cloud" to potentially hundreds of millions of users--limiting computational ability afforded to each user. The user interface is supposed to be this mobile device--again with limited computational resources--with limited display capabilities tied to the "cloud" through a relatively slow wireless link with constrained bandwidth. Megabytes of throughput on this network of wireless links are a limited, sometimes expensive commodity offered by a limited number of carriers.

Seems to me I remember something about history and repetition and being doomed...but I forget the rest ;-)

I'm not familiar enough with the Android platform SDK to say if it is good or bad (whatever "way" a system is architected, the implementation may be good or bad), but I do remember the "Unix Way" worked well in those "dark ages", so if one was, um, INTENT on recreating such a situation it'd probably make sense to do what worked very well in the past.

Unix is less work

[wurp]

To me, unix (or GNU/Linux) and a functional command line are much less work than Windows and the mouse.

It worked for me!

[hedronist]

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

I happened to write the first source-level C debugger that actually worked (sdb was buggy as hell, and dbx at Sun was debugged with my debugger). I absolutely loved it when the Yates Report would say that yet another company would "capture 20% of the UNIX market." I waltzed on over, gave their senior geeks a pitch, and waited for the manager fold as they begged for a working debugger.

I say, "The more forks the merrier!"

Platform Fragmentation

[foxylad]

If we cast our minds back twenty years, the same choice faced developers - did you make apps for the nice stable hardware-controlled Mac, or for the chaotic IBM PC compatible world?

Two points: first, it's an amazing reflection on Apple's success that they are a player in both of these choices.

Second, I think the relative success of iphone/android will mirror Mac/PC. Just as PC hardware quickly became much cheaper than Macs, Android phones will soon be significantly cheaper than an equivalent iphone. And more manufacturers will push the envelope faster than Apple will be able to, so Android will evolve faster. Cheaper and more features equates to substantially more sales - ten to one if Mac/PC history repeats itself.

Now I don't know about this guy, but most developers will judge the increased complexity of developing for multiple Android devices a small price to pay for access to a much larger marketplace.