Where Android Beats the iPhone

snydeq writes "Peter Wayner provides a developer's comparison of Android and the iPhone and finds Android not only competitive but in fact a better choice than the iPhone for many developers, largely due to its Java foundation. 'While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket,' Wayner writes, pointing out GScript and Remote DB as two powerful tools for developers to make rough but workable custom tools for Android. But the real gem is Java: 'The pure Java foundation of Android will be one of the biggest attractions for many businesses with Java programmers on the staff. Any Java developer familiar with Eclipse should be able to use Google's Android documentation to turn out a very basic application in just a few hours. Not only that, but all of the code from other Java programs will run on your Android phone — although it won't look pretty or run as fast as it does on multicore servers.'"

Comments

It's biggest strength

[XPeter]

It's not DRM-laden patent trolling Apple.

Re:It's biggest strength

[Xebikr]

Why was this modded down? Is it wrong? Apple has gone from evil yet innovative to just evil. Their recent lawsuits all but scream "We are out of ideas! Release the lawyers!"

Re:It's biggest strength

[Anonymous Coward]

Why was this modded down? Is it wrong? Apple has gone from evil yet innovative to just evil. Their recent lawsuits all but scream "We are out of ideas! Release the lawyers!"

It was modded down because the iphone owners on slashdot got to it before the android owners did.

Re:It's biggest strength

[Anonymous Coward]

Apple was never "evil yet innovative". The most "innovative" thing they ever did was introduce graphical computing to the masses...by buying the GUI PARC invented and basically using it as is. They've been especially uninnovative since the return of Jobs though, as their main business strategy has been entering rapidly growing markets and doing the same as everyone else, but more expensive and with less features. But they put it in shiny white plastic and market the hell out of it and everyone buys one because they want to be cool and Think Different, just like everyone else. Apple isn't a tech company, they're a fashion accessory company whose products happen to also function as gadgets.

Re:It's biggest strength

[zullnero]

Apple was only occasionally innovative. They generally stole a lot of their ideas just like everyone else. But I agree, they are evil, though they've only really been evil since they got their first big taste of success with the iPod and have slid into crazy evil. Once upon a time, they actually served a useful purpose as a company delivering a product that helped to motivate the whole market towards user-oriented innovation. Mainly by stealing good ideas that other companies had, nabbing ideas from here and there, and making them work within their closed loop and proving to the market that those ideas were good.

Re:It's biggest strength

[Thinboy00]

Think of the 1984 ad... a la role reversal (someone should do a parody replacing "big brother" with Jobs and the jogger with... Tux?)

Re:It's biggest strength

[pydev]

It's actually even worse than that. PARC's GUI was a lot more advanced than the crap Apple actually shipped as MacOS; Apple merely imitated its looks but cut corners on the implementation. That's why MacOS was on a death spiral within ten years: it didn't have a solid architecture or foundation.

OS X actually copied a bit more of PARC's technology, but even Objective-C and Cocoa are lousy compared to PARC's original technologies.

Re:It's biggest strength

[moosesocks]

So a handful of patent lawsuits and a weirdly restrictive app store make a company "crazy evil?"

Pardon me if I can't quite hear Steve Jobs cackling in the background, but technology companies have been suing each other for patent violations as long as they have existed -- even our darlings at Novell are no strangers to being on the plaintiff's stand at patent hearings.

When they got successful with the iPod, they brought legal (and eventually drm-free) downloads to the masses -- great for artists and consumers alike. I'm not a fan of the proprietary format, so I shop at Amazon these days, although Apple certainly deserves credit where it's due for (finally) managing to get the industry on board for a sales model that wasn't entirely draconian. Without iTunes, there'd be no Amazon mp3 store.

The iPhone is also the most open platform to have ever reached a considerable portion of casual cell phone users, and spurred considerable innovation in the industry. Without the iPhone, there almost certainly would be no Android. Again, I don't own one because of the stupid app store policies, but it's not hard to acknowledge the effect it had on the marketplace. It really was the first smartphone that didn't completely suck.

Although Apple's ideas might not all be completely original, their talent scouts seem to have a knack for snatching up promising technologies, and incorporating them into successful products, largely influenced by their user-centric design and extensive usability testing. At the end of the day, this is really all that matters to the company -- it doesn't matter if the technology was invented in-house, purchased outright, or "inspired" by something else. After all, Jobs loves quoting Picasso: "Good artists copy. Great artists steal."

Re:It's biggest strength

[Lundse]

If we give everyone in their seats an iPad, and still replace Jobs, can we keep the jogger - maybe in a Gnu top?

Re:It's biggest strength

[Lundse]

"...but in calling Apple evil, you're espousing a communist standpoint."

No. The communist standpoint would be all corporations, and indeed any mode of production where the tools for production is owned and people then sell their labour-hours to the owners, is inherently and necessarily evil. (Socialism, btw, is thinking you can keep that system and mitigate its evils).

The things Apple are doing; suing, lying, pushing a model where people have no control over 'their own' devices and generally selling a platform to the so-called content owners instead of servicing the public - is evil. Their motivation does not matter, the things they do have bad consequences for everyone but their shareholders, they know it and this is about as close to 'evil' as you get without waxing theological.

Doing whatever makes money is not a get-out-of-having-a-conscience-card just because 'that's what the public wants'. How is that paper on the invisible hand (which allegedly guarantees this weird thesis) coming, Mr. Smith?

Re:It's biggest strength

[CharlyFoxtrot]

They've been especially uninnovative since the return of Jobs though, as their main business strategy has been entering rapidly growing markets and doing the same as everyone else, but more expensive and with less features..

Typical geek. "How can this iPod/iPhone be better ? It has less features !" Would the average person have been able to get work done on the PARC machine ? Probably not, but they could on the mac. Some people actually care that it's nicely designed, that the feature that are included work in thoroughly logical and planned out manner, that it's easier to use and yes it even looks nice. THAT is Apple's strength.

Re:It's biggest strength

[CharlyFoxtrot]

You might want to look at the bigger picture. The mobile world is at war and no punches are being pulled, Apple is just the most high profile combatant. (Not that I agree with the lawsuits.)

Re:It's biggest strength

[centuren]

Apple was only occasionally innovative. They generally stole a lot of their ideas just like everyone else. But I agree, they are evil, though they've only really been evil since they got their first big taste of success with the iPod and have slid into crazy evil. Once upon a time, they actually served a useful purpose as a company delivering a product that helped to motivate the whole market towards user-oriented innovation. Mainly by stealing good ideas that other companies had, nabbing ideas from here and there, and making them work within their closed loop and proving to the market that those ideas were good.

I don't see how they're evil, unless it's a Faustian evil. The iPhone is a product that many people don't mind being locked into, or whatever developer limitations there are for producing software for the app store. That's fine for them, they can spend their money on an iPhone and be happy to do it. I have a Macbook as my portable computer, and I've never been tempted in the least to buy an iPhone. I don't expect Windows Mobile phones to deliver what I want, either. So long as they don't interfere with other companies trying to offer products that meet my personal tastes, what would I have to complain about? That my friends all have iPhones? That's their prerogative. No one needs an iPhone for anything, in my experience.

Re:It's biggest strength

[rishistar]

IMHO Apple has pretty innovative marketing and design departments and a consolidating technology department.

Re:It's biggest strength

[mcvos]

that it's easier to use

This especially. Say what you like, but the iPod's UI was way better than that of any other music player at the time. Same with the iPhone that did way with navigating through crappy menus just to do something basic.

There's tons of stuff wrong with Apple, and I'm glad I switched from iPhone to Android, but Apple does know better than anyone else how to make accessible and usable interfaces.

Re:It's biggest strength

[Unequivocal]

Well said. I don't personally use apple products b/c of their affinity to close and control their market and users. But I recognize that I regularly benefit from Apple's innovations in UI - they do it as well or better than any big company. My HTC Droid Eris is a total copycat of the iPhone, perhaps in some ways better, but before that I was using an HTC WinMo phone that sucked - the only reason I get to use the Eris is because Apple out-innovated the market and Google followed behind copying them and HTC built the hardware to seal the deal.

Re:It's biggest strength

[JAlexoi]

Innovation by definition is introducing ideas to the markets, not actually coming up with those ideas. So, as much as I hate Apple, they were(I can't see into the future) innovators.

Re:It's biggest strength

[Dog-Cow]

You are stupid. It's amazing a monkey like you could even be trained to type.

Apple is not evil. What they do is not evil. Your seem to think (yeah, right) that anything you don't like is evil. That is simply not the case.

Maybe one day you will gain enlightenment and understanding. I wouldn't hold my breath -- but I hope you do.

Re:It's biggest strength

[pwfffff]

Holy shit, buddha posts on slashdot.

Fuck off. You're no more enlightened than a hippy on 12 hits of acid.

Re:It's biggest strength

[smidget2k4]

To be fair, Apple's Lisa's GUI was way ahead of its time (this was heavily based off of PARC, yes). Unfortunately, that computer cost over $10k at the time. The OS they released for the scaled down version, Macintosh, was in fact a piece of crap.

Re:It's biggest strength

[Lundse]

Your seem to think (yeah, right) that anything you don't like is evil.

Try reading my post again, you may find there is exactly no support, nor any reason to suppose, that this is my claim or belief.
And if you then try to adress my actual beliefs, without the personal attacks, we might have a conversation where we engage each other instead of just inventing positions for the other party and railing against them.

I am not holding my breath, though. But do surprise me :-)

Re:It's biggest strength

[Random5]

If by 'way better than' you mean 'the same as' creative's which they ripped off and settled when creative sued them over it, but the damage was done. Good physical design and and advertising had given them a large marketshare and massive mindshare.

Re:It's biggest strength

[countach]

Rushed to market? It's not like Xerox was bringing it to market, only less rushed. We'd still be waiting for a gui if we were waiting for them.

Use "em" not "px" when defining the UI

[modmans2ndcoming]

To those about to complain that screen resolution differences makes developing for android harder, then try using a UI measurement that does not rely on pixels, like em

Re:Use "em" not "px" when defining the UI

[david_thornley]

Then all you'll suffer from is screen size differences.

Re:Use "em" not "px" when defining the UI

[Anonymous Coward]

To those about to complain that screen resolution differences makes developing for android harder, then try using a UI measurement that does not rely on pixels, like em

Incidentally bitmaps that use em have not been invented yet. Vectors are not good for everything, and may take more power to render on the fly.

Also, em solves exactly nothing about how much content can you fit on a display before it becomes unreadable, a problem you may get if you treat DPI as a free variable. Oh and it also doesn't factor in display ratio, unless you think squashing things is the way to go.

Re:Use "em" not "px" when defining the UI

[MemoryDragon]

You always can use layout managers...
Only Windows UI Programmers complain about screen sizes...

Re:Use "em" not "px" when defining the UI

[ducomputergeek]

With our last website design for our shopping cart, we elected to go with a fluid layout and use em. Great right? Nope. We heard so many complaints from customers it was rather eye-opening. The fact that things were "a little different" from screen to screen (say a desktop vs laptop) annoyed and confused people even if a box was just had more space in between. Frankly we couldn't see it. If the screen was wider, there was a bit more separation in places. So we ended up going back and defining everything being centered and by pixels so it looked the exact same no matter if the user had a 12.1" screen or 30" LCD TV. If they had a bigger screen/higher resolution, they just got to see more of the background gradient. The complaints stopped and we didn't alter the design. So go figure....

We also have clients who are insanely anal about their branding and virtually demand things to be "pixel" perfect. With the iPhone/iPod Touch this hasn't been a problem. Android it has. Not to mention the other hardware inconsistencies.

But in our shop, Android is really starting to cost us a lot of money in QA testing. And we guarantee that our software works on all known models as of a certain date. It's in the contract and the clients do pay us well for it. Our testing hardware for the iPhone/iPod Touch has been $1600 over the past two years. (iPhone 3G, iPhone 3Gs, iPod Touch). We've spent over $2500 acquiring Android hardware just in the last six months of last year and have already spent another $1400 this year.

As a result, the cost of us building an Android app is now double that of an iPhone app. And at the rate the new Android phones are coming out, that is likely to increase if customers want a full compatibility guarantee.

Now we're about to launch our first application built using the PhoneGap framework. It's basically a web app wrapped using PhoneGap's "container" (for lack of better description) and should allow us to support iPhone, Blackberry, and Android by only having to support 1 framework and using web programming. But we'll see how well that works.

Re:Use "em" not "px" when defining the UI

[bjartur]

Then use a mix of em and CSS3 px (which are _NOT_ screen pixels), possibly with display ratio @rules. Convert to pixels at install-time if doing so on run-time is to slow. Problem solved. Or just use a Java layout manager...

Re:Use "em" not "px" when defining the UI

[shutdown -p now]

Only Windows UI Programmers complain about screen sizes...

We don't - we've had WPF, with flexible layouts by default, since 2006.

And those who are .NET-allergic and prefer C++ can always just use Qt.

Re:Use "em" not "px" when defining the UI

[mdwh2]

Wow, 2006! I think that proves his point ;)

(I program Windows btw, but it's always been a pet hate that for so long, Windows enforced developers into a pixel-fixed unresizable GUI design. But then I was programming with flexible layouts on the Amiga in the early '90s.)

Re:Use "em" not "px" when defining the UI

[mdwh2]

Who says bitmaps need to resize? A rescaling GUI doesn't mean that everything has to scale uniformly, it just means using the extra space sensibly. Try resizing your browser window right now - does everything scale exactly the same? Of course not. Is it useful to be able to enlarge the window? Of course.

Bitmaps are generally a minor part of GUIs anyway. And if you're talking about games instead, that's the first place you should be learning to program resizeable displays.

Re:Use "em" not "px" when defining the UI

[tknd]

Our testing hardware for the iPhone/iPod Touch has been $1600 over the past two years. (iPhone 3G, iPhone 3Gs, iPod Touch). We've spent over $2500 acquiring Android hardware just in the last six months of last year and have already spent another $1400 this year.

But it costs money (an annual subscription) to be a part of the iphone developer program (gain access to the development tools and software for device provisioning). You're also restricted to running it on certain versions of OSX (OSX upgrades are not free). Meanwhile Android software costs are essentially zero; android dev libraries and emulator are free.

Re:Use "em" not "px" when defining the UI

[shutdown -p now]

I program Windows btw, but it's always been a pet hate that for so long, Windows enforced developers into a pixel-fixed unresizable GUI design.

Well, it's not entirely true - while it wasn't properly resizable, it wasn't really pixel-fixed, either. For example, if you ever programmed directly in Win32 API or in MFC, you might remember that dialogs are laid out not in pixels, but in dialog units, which are actually a bit like em in that they are tied to the pixel size of the default UI font. If user changes the DPI setting in configuration, font size changes correspondingly, and dialogs should scale accordingly.

The problem is that this is only used by default for dialog templates fed to CreateDialogIndirect. If you ever create a window yourself using CreateWindow, and manipulate that, all sizes do indeed come in pixels, and you need to use something like MapDialogRect to convert them yourself. And, of course, most people didn't bother...

The other problem is that many high-level frameworks didn't bother, either. Delphi didn't do so for a long time, forcing to deal with pixels directly, for example. VB6 of all things did it right by introducing "twips", which are DPI-dependent (1440 twips/inch; that's 20 twips/pixel at 72dpi, and 15 twips/pixel at 96dpi), and using them for all UI measurements. Even then, creative code monkeys broke the model by observing the twip/pixel ratio for their specific DPI, and then using that as a general-purpose conversion formula...

Now, as noted earlier, this still doesn't lead to truly reflowable UI. And it's not just a matter of user convenience, either - proper localization with statically sized UI is a pain, especially if you start with English, because strings in most other languages are longer, and can easily overflow UI elements sized for English. In sentences, word count can differ widely, too - sometimes so much so that the label now needs to be two-line to fit. On Windows, this was historically "solved" by letting localizers also tweak dialog layouts as needed, but this is obviously an ugly hack. The only proper solution is reflowable UI.

Oh, and it was there before 2006 in stock offerings; WinForms got layouts in .NET 2.0, in 2005. It's just that it was not very convenient to use, and not well supported by visual form designer. With WPF and its XML-based markup, it's much more natural.

And, of course, third-party frameworks had dynamic layouts on Win32 for ages. Qt had it since the first version, I believe; at least it was definitely in 2.x, which was the first one I've seen.

Re:Use "em" not "px" when defining the UI

[peragrin]

did you miss the part where in order to prove an andriod app will work on a given set of hardware they have to buy the phone.

Even if they pay $1000 a year to apple for said subscription paying $5000 a year for andriod hardware to make sure your app works across them all equally as well isn't cost effective.

it doesn't matter if the development environment is free if the QA testing costs you $5000 a year, as no 2 android phones are the same even from the same manufacturer. Especially when apple provides an emulator for all their hardware platforms.

Re:Use "em" not "px" when defining the UI

[s73v3r]

The developer fees for the iPhone aren't ~$2000 more than Android, which is about the difference they've spent on dev hardware.

Re:Use "em" not "px" when defining the UI

[shutdown -p now]

That's why sizes in Android are specified in terms of density-independent pixels (or other non-variable measurements) and not actual pixels... Maybe this is a problem on your laptop, but it's not a problem on Android.

GP was talking about using px in the context of website design, not Android UI design. My reply was specifically about that. I'm glad to hear that Android uses DPI-independent measurement units, but it seems that GP might not be, since he already had problems with em...

Re:Use "em" not "px" when defining the UI

[MobyDisk]

We heard so many complaints from customers it was rather eye-opening.

Then your layout sucked. Nothing is more annoying than a static 1280x1024 layout on an iPhone, that requires me to zoom in and out constantly. For a good flow layout, take a look at Wikipedia or Amazon's mobile sites. Just because you couldn't do it right doesn't mean all flow layouts are wrong.

As a result, the cost of us building an Android app is now double that of an iPhone app.

You are supporting more hardware devices, so you have to test on more hardware devices, which costs more. Would you rather that each of those pieces of hardware have a different operating system? You should be thanking Google for Android, because the only reason you are even capable of supporting all these devices is because it is so much cheaper because of Android. Before Android, you had to write for even more operating systems.

Re:Use "em" not "px" when defining the UI

[LordLucless]

Apples to oranges. You're comparing developing for a single device with developing for a whole bunch of them. If you supported only one Android model, the way you only support (essentially) one iPhone model, it'd be a fair comparison.

It sounds like the problem is your support contract. If you guarantee support for all models on a given date, then your costs are going to increase as more diversity enters the phone market. If your contract doesn't allow for you to increase your charges as the number of supported devices increase, then it's going to be a weight around your necks.

Re:Use "em" not "px" when defining the UI

[BitZtream]

But it costs money (an annual subscription) to be a part of the iphone developer program (gain access to the development tools and software for device provisioning).

Wrong. Costs money to test on live hardware or post to the app store. For practical purposes, yes it costs money to be a developer. Add in the $99 cost and you'll notice he's still spending less on the iPhone.

You're also restricted to running it on certain versions of OSX (OSX upgrades are not free).

OSX 10.5 is required, which is 2 1/2 years old. Most developers have bought a new machine in the last 2 1/2 years, but if you haven't ... the price of an upgrade is trivial.

Meanwhile Android software costs are essentially zero; android dev libraries and emulator are free

Yep, they are all free, and you can tell.

But looking at the costs you listed, I fail to see any sort of argument about how that makes android cheaper than the iphone for him. We're both just pissing away about details at this point, his point remains.

Re:Use "em" not "px" when defining the UI

[Sancho]

His point is from a flawed premise. The Android emulator lets you target any version of Android with any version of the software. They could have spent 0 in purchase costs in order to effectively test on every conceivable hardware platform. They set unreasonable testing criteria, paid too much to fulfill it, and now they're complaining about it.

Re:Use "em" not "px" when defining the UI

[hunangarden]

You don't have to buy all models of android phones to "prove" it will work. Android Emulator works just fine and you can test different OS versions, screen sizes and resolutions on it. I do own a Motorola droid and do test on it, but I don't lose sleep worrying about how my app will run on different phones, because the emulator testing works well.

People let you know pretty fast if there is an issue with their phone model and you can release an update any time you choose (its actually instant, you post the update to the Android Market and users can immediately download the new version or update their old one).

We've (LLC) sold about 1200 copies of our app for Android, so far it seems to work fine on all models that it was designed for.

Re:Use "em" not "px" when defining the UI

[hunangarden]

Yeah, its a bit of a pain, but not much. Andrdoid acutally lets you have different layouts for different screen size/resolution combinations. You just store the layout in directories that are named for that size/resolution and the phone will automatically use the right one.

By using device independent pixels (use "dip" units for most everything and "sp" units for text) you can often avoid having to use different layouts, but the layout directory model is convenient when you need it (I did).

Re:Use "em" not "px" when defining the UI

[Skreems]

Android does have dynamic DPI-based resizing built in for all graphics assets. It will also let you define "flex" images where sections of the side and center are repeated to stretch the image to different sized content without rescaling. Between the two, it's pretty easy to not care about pixel sizes.

Re:Use "em" not "px" when defining the UI

[Idiomatick]

"Incidentally bitmaps that use em have not been invented yet." Huh?.... Set the 50x50px image to be 12x12em .... works fine on the interwebs.

Basically speaking we can make websites that look good, perfectly fine when dealing with tons of different screens, resolutions and DPI. No reason why aps wouldn't work. YES, it makes it harder. You have to think about it a bit. Bit it is pretty fucking minor. Look at ALLLLLL windows aps. You can resize them freely within certain bounds and they don't fuck up horribly. So it seems like we've been doing this for decades.

Re:Use "em" not "px" when defining the UI

[pydev]

Android it has. Not to mention the other hardware inconsistencies.

"Inconsistencies?" Has it occurred to you that there is actually a demand for these varieties of devices? The iPhone resolution and keyboard simply don't work for me (I tried). They don't work for many other people either. We want high resolution devices with a keyboard. I'm sorry that inconveniences you as a developer, but you'll just have deal with it (unless Apple succeeds into turning us into the United Socialist Apple Republic, where everybody is forced to use a single standard device by Apple Corporate).

As a result, the cost of us building an Android app is now double that of an iPhone app. And at the rate the new Android phones are coming out, that is likely to increase if customers want a full compatibility guarantee.

And the market share is likely going to be double that of the iPhone soon as well. Again, go deal with it. Or if you don't want to deal with it, fine, that's your choice; I'm sure other developers will be happy to take your market share.

We've spent over $2500 acquiring Android hardware just in the last six months of last year and have already spent another $1400 this year.

I hardly call $5000 in hardware per year a significant expense for a development shop. But you don't have to do it anyway since you can test on emulators.

Re:Use "em" not "px" when defining the UI

[GlassHeart]

Professionals who tell their clients that "the software sill work on all shipping Android phones" better have tested on actual hardware. Emulators could not replicate for you chipset quirks, subtle timing problems, and many other issues that only occur on hardware. If you've shipped commercial software tested only against an emulator, I would strongly urge you to not admit it, and maybe get a lawyer.

Re:Use "em" not "px" when defining the UI

[bar-agent]

Mac OS X does a very good job with reflowable layouts, using its "springs and struts" system. It is arguably more effective than Java's over-engineered selection of layout managers. Unfortunately, the iPhone only supports "struts," not "springs," so it is not nearly as good.

(Java has SpringLayout, but that seems to work differently. And I understand that Mac OS X's Core Animation framework provides more powerful layout capabilities.)

Re:Use "em" not "px" when defining the UI

[centuren]

But in our shop, Android is really starting to cost us a lot of money in QA testing.

I can really see how this could be a problem, having had an Android phone land in my lap (free give away of the Behold II). It's a new phone, with an old version of Android, and no explicit word on when to expect an update to the current OS version. I come across apps in the Android Market that replace the desktop environment, or the keyboard, and I can't give those developers money even if their software sounds appealing. I just don't know what I'm missing out on in terms of what I'll gain when I upgrade the ancient Android version it shipped with. I imagine new products shipping with old OS versions must be a royal pain in the arse, on top of the variety of hardware platforms.

Re:Use "em" not "px" when defining the UI

[centuren]

You don't have to buy all models of android phones to "prove" it will work. Android Emulator works just fine and you can test different OS versions, screen sizes and resolutions on it. I do own a Motorola droid and do test on it, but I don't lose sleep worrying about how my app will run on different phones, because the emulator testing works well.

This attitude is why software development will never be an "engineering" discipline.

This attitude is also why open source software development can be done at low cost, relying on community bug reports and fixes for different configurations that aren't directly available to a single programmer.

Re:Use "em" not "px" when defining the UI

[centuren]

Professionals who tell their clients that "the software sill work on all shipping Android phones" better have tested on actual hardware. Emulators could not replicate for you chipset quirks, subtle timing problems, and many other issues that only occur on hardware. If you've shipped commercial software tested only against an emulator, I would strongly urge you to not admit it, and maybe get a lawyer.

This happens all the time in other areas, without need of lawyers. Support of all versions of IE (6+) on all versions of Windows (2000+) comes directly to mind. Web shops don't have a hardware setup for every Windows/IE combination, we use virtual machines (i.e. emulators). We make sure clients sign off on the final product, and professional obligations are honourable fulfilled.

Re:Use "em" not "px" when defining the UI

[backwardMechanic]

Isn't this the old argument about a Mac vs. a PC? Life is easier (predictable) for programmers when the hardware is restricted. But better (cheaper, more choice) for consumers when the hardware is open. There are far more people reading this on a PC than a Mac. Your company doesn't have to support Android - it is free to ignore a large customer base if it wants to. Currently I'd guess there are far more iPhones out there than Androids, but in five years time?

Re:Use "em" not "px" when defining the UI

[Sancho]

"All shipping Android phones" is a somewhat silly claim to make. Do you tell your clients that your desktop software will run "on all shipping Windows laptops?" Your testing costs must be through the roof. It's amazing that anyone makes any money in this field.

Re:Use "em" not "px" when defining the UI

[SharpFang]

A VM PC with a webpage vs an embedded device of different architecture CPU with an app that often interacts with the CPU... it is absolutely apparent that you have never done any embedded programming.

In embedded programming, "it runs without faults on emulator" is getting about as far as "it passes validator.w3.org" in web programming: the fun with nasty bugs and hidden problems just began.

Re:Use "em" not "px" when defining the UI

[nobodyman]

You're comparing apples(no pun intended) and oranges.

If a web app doesn't work in a particular browser, a user can simply fire up another browser. But if a user pays money for app that doesn't work? Well then that user is screwed and you have a serious problem.

Re:Use "em" not "px" when defining the UI

[cynyr]

but i thought all android apps were java based apps that wwwere being run though the same JVM, how would chipset quirks effect that? apart from making the OS not work correctly in the first place, which means that it isn't the apps problem but that model.

Re:Use "em" not "px" when defining the UI

[GlassHeart]

And now you're changing the argument. What I'm objecting to is your contention that they could just use the emulator and not buy hardware, and still "effectively test on every conceivable hardware platform", which is plain false.

If testing on real hardware is what the client wants, you do it or turn down the gig. I don't see how silliness enters into consideration, and testing on all Windows laptops is literally a problem of a different magnitude, and quite irrelevant as an analogy.

Re:Use "em" not "px" when defining the UI

[GlassHeart]

Right, but you missed my first sentence, which comes from "we guarantee that our software works on all known models as of a certain date. It's in the contract and the clients do pay us well for it" constraint from ducomputergeek. If this is what you promise, then emulators are not good enough. If your client knows and approves of your use of VMs, then you're obviously in the clear.

Re:Use "em" not "px" when defining the UI

[david_thornley]

Ah, cluelessness.

I see no reason to believe that Android market share is going to rival the iPhone. Slashdot readers do not make a dominant market bloc, and typically are concerned with greatly different things than the typical customer. They also tend to lack empathy, so they project their tastes on the typical consumer, and frequently whine when the results are not what they expect.

Nor can the testing be done on emulators alone; a guarantee that certain software will be run on all Android devices can only be made by testing it on all devices. Emulators are doubtless useful in the preliminary testing. What GP's clients want is a solid guarantee.

You are also glossing over the basic issue. As Android phones get more popular, they will get more numerous and varied, and testing will get more expensive. This is a sizable competitive advantage for iPhone developers; another one is the relative ease of creating an app that will run on all phones. Since good-looking apps will sell better, another competitive advantage for the iPhone developers is the ease of making apps that look good on a very few specific form factors.

Android certainly isn't going away, and as a recent market entrant it's likely to continue increasing its market share for a while. It's going to be worth supporting. It isn't going to be as worth supporting as the iPhone, and I don't see that as changing any time soon.

Re:Use "em" not "px" when defining the UI

[SharpFang]

how comes you can't install a 5 years old OS on the newest PC and have it recognize and support all the new hardware fully?

The fact it knows how to use the CPU (in single-core 32 bit mode), the lower 4GB of RAM, and in general it -will- run... But that's not the "corporate quality" performance.

Re:Use "em" not "px" when defining the UI

[Dog-Cow]

You are a fucking stupid moron, and we'd all be better off if you died.

The GP stated that his customers complained BECAUSE THE LAYOUT CHANGED. And you come along and tell him he should have made sure the layout changed. You are really too fucking stupid to feed yourself.

Re:Use "em" not "px" when defining the UI

[Dog-Cow]

The GP calls himself pydev. Presumably that means python developer. Thus it is quite obvious that he is clueless.

Re:Use "em" not "px" when defining the UI

[Troed]

(I Am A Mechanical Engineer and Software Engineer)

Software Engineering was a joke from the beginning. Basically it pretended that all software needed to be written like NASA does it, while in reality that should be treated like a special case.

Writing software is a craftsmanship, and open source is most closely likened to basic research.

Software development is as much engineering as social sciences are sciences.

Re:Use "em" not "px" when defining the UI

[adolf]

You're so stupid, I feel ashamed to have a UID close to yours. But: mine's still lower.

So listen, kid:

The GGP used a bad layout, and people complained. That's all there is to say.

Meanwhile, screen resolutions have moved from 640x480 to 800x600 to 1024x768 to, nowadays, 1920x1200. Except for portable devices like the iPhone, at 320x480. Or the various Android devices, at their various resolutions. Or any of the other competently-useful Web-browsing devices folks have in their pockets these days.

So, plainly: Pixels mean nothing. That GGP couldn't figure it out to the satisfaction of his customers (who, if they were complaining, probably don't even know what a pixel IS) means that he's incompetent at the task, not that the idea is unsound.

Re:Use "em" not "px" when defining the UI

[adolf]

guarantee

There's lots of guarantees out there. Craftsman hand tools come immediately to mind -- if it breaks, I take it back and get a new one.

Of course, they're shoddy tools, and break all the time, but at least I can get a new one when it happens.

A guarantee isn't a certainty; it's a fallback.

That's peachy

[Anonymous Coward]

Unfortunately right now it appears that for users it's the other way around.

Re:That's peachy

[ircmaxell]

That's not true. ONE reason for the iPhone's dominance is that there was no competition with a similar hardware class for quite some time. And when I say similar hardware class, I mean large screen, powerful processor and all the sensors. Sure, there was the G1 and others since, but none have had a strong CPU. Until the Droid and the Nexus One. Both have been flying off the shelves (The droid has been around for what, 5 months? And after 2 months the "droid light" app which turns the backlight on the camera into a flashlight was already on the top 10 downloaded apps list... Last year saw a good jump in the number of android based devices sold. I'd be very surprised if Android didn't have at least 10% of the smartphone SALES by the end of this year... At least some of the reasons to buy the iPhone are now shared among a mass of devices (the caliber of hardware, supporting of 3pd apps and "all in one" functionality through a sexy touch screen device)... I'm not saying the iPhone is dead (I'd be REALLY surprised if it went down without a fight), but I am saying that its lead from the rest of the pack of smartphones (in non-business use anyway) is in serious jepardy...

Re:That's peachy

[bigstrat2003]

That completely depends on your needs. This user wants to do what he wants with his phone, not what the manufacturer graciously allows him to do (otherwise, why get a smartphone?). Because of that, Android is an infinitely better choice than iPhone. The UI is about equal (although less pretty), and while people may bemoan the lack of apps, 95% of the apps I've seen on the iPhone are useless. Thus, for my requirements (and yes, I know the mainstream user base doesn't share them. I don't care, as they are not me), Android is light-years ahead of the iPhone.

Re:That's peachy

[mdwh2]

I agree that there's even less reason now for the Iphone to have anything special about it, but even originally:

That's not true. ONE reason for the iPhone's dominance - snip.

Dominance? There's no dominance judging by market share figures. And if we're talking about when the Iphone was first released, then the original Iphone model sold far less.

(I don't know if it's true that the Iphone had the fastest CPU - it's hard to tell with so many made up "firsts" - but whilst this would be useful for gamers, for people who are buying it primarily as a phone, communication and/or Internet device, it's not so important.)

Re:That's peachy

[mdwh2]

That's not what the buyers are saying with their money since they are still buying more iPhones than Android phones.

And there are far more buyers buying Nokia, along with Motorola, Samsung, LG, and even RIM, high above Apple or Google.

You need to expand your sampling of "users" to beyond the slashdot neckbeards.

Yes, exactly. I wish people would do that, instead of pretending it's just Apple versus Google.

Re:That's peachy

[BitZtream]

That's not true. ONE reason for the iPhone's dominance is that there was no competition with a similar hardware class for quite some time.

Sounds to me like you didn't know smart phones existed before you saw the iPhone.

I assure you, I owned more powerful phones before hand, the only thing the iPhone has that its predecessor didn't is accelerometers and iPhone OS, my original iPhone was actually less powerful than the WinMo phone I owned before it.

Hardware wasn't the problem. The problem is that smartphones in general suck, the iPhone happens to suck a whole lot less.

No, don't tell me about what smart phone you have and how it doesn't suck. It does, you just don't realize it, they have a long way to go before the start getting to the non-suck state. We're about at the C64 stage right now. Which many look back on fondly and talk about how great they are ... from their modern, billion times faster PCs.

The problem is that people like you still have no clue why the iPhone is popular. Its not the hardware. Its not the OS. Its not the app store. Its not iTunes. Its the whole package. From start to finish its all fluid. If you say that about Android, the only response I can give you is to come back and talk to me after you've actually owned one.

People don't give a flying fuck about the processor it user, how much ram it has or who makes it. Really, they don't. They care about having a device thats enjoyable to use, across the board. As long as you keep trying to compare a product based only on specifications of the hardware or OS, you'll continue to be unable to understand why your predictions are invariably wrong. Regardless of where you want to believe it or not, style and user experience are actually what the people care about ... well, normal people anyway. It either does or doesn't meet their requirements, thats all they care about tech specs. A 400mhz proc is no different than a 200mhz proc if 200mhz plays their latest downloads of survivor.

The iPhone isn't going to put up a fight because the contenders still haven't figured out that we're boxing, not playing checkers. To put it bluntly, as far as the general public is concerned, the iPhones contenders simply aren't.

Re:That's peachy

[ircmaxell]

I assure you, I owned more powerful phones before hand

Yes, I agree. However, the common person wasn't able to take advantage of that power. Installing an application on a WinMo phone required technical expertese. It was no where near as simple as clicking on the app and selecting install. You had to go into active sync, select the app, push the sync and verify that the install worked. It was a sour enough experience that I only did it for applications that I really wanted...

From start to finish its all fluid. If you say that about Android, the only response I can give you is to come back and talk to me after you've actually owned one.

I have owned 3 android phones. I have also used an iPhone for a non-trivial amount of time (I borrowed one for a month). While I agree that the first 2 (a G1, and a hacked HTC Tyan II) were no where near the experience of the iPhone, the Droid that I have now is to the point that I'd say it's better. It's every bit as fluid (in some cases more so) as the iPhone. Sure, the settings screens and music app leave something to be desired, but the whole UI is definitely ahead of the iPhone. Not because of ease of use (I don't think it's easier). Not because of the sexy factor (The iPhone is more sexy). But because of the extensibility factor. You can change just about every UI element on Android to tailor it to your liking (Home screens, app dock, keyboard, etc)... Rather than telling you how it should fuction, it lets you chose (and the choice is trivial to make)... And I know a number of non-geeks that now own Droids (some of which came from iPhones), and all of them LOVE it. Actually, I've never met someone face to face that's had a Droid and not loved it... That's just my $0.02...

Re:That's peachy

[pydev]

That's not true. ONE reason for the iPhone's dominance

I don't think Apple's tiny market share can be called "dominance".

is that there was no competition with a similar hardware class for quite some time. And when I say similar hardware class, I mean large screen, powerful processor and all the sensors.

There were plenty of large screen phones before the iPhone (and the form factor of the iPhone is almost identical to several Palm devices). However, they weren't popular because they were expensive and had poor battery life. Just like the iPhone. Apple's genius is in being able to sell a hugely expensive phone with a poor battery life to regular consumers, both by putting some fun content on it and by hiding the true cost in subscriptions.

Re:That's peachy

[MemoryDragon]

Actually my HTC Hero is pretty good at non sucking, every aspect except the 3d games performance is way superior to the iPhone...

Re:That's peachy

[homesteader]

Apple apparently had about 16 million tiny market shares last year . . .

It's only tiny if you're comparing to Symbian . . .

If Apple's share is tiny, the Microsoft and Google aren't really even players . . .

Most people wouldn't know a Symbian if came up and bit them . . .

Re:That's peachy

[mcvos]

I have owned 3 android phones. I have also used an iPhone for a non-trivial amount of time (I borrowed one for a month). While I agree that the first 2 (a G1, and a hacked HTC Tyan II) were no where near the experience of the iPhone, the Droid that I have now is to the point that I'd say it's better. It's every bit as fluid (in some cases more so) as the iPhone. Sure, the settings screens and music app leave something to be desired, but the whole UI is definitely ahead of the iPhone. Not because of ease of use (I don't think it's easier). Not because of the sexy factor (The iPhone is more sexy). But because of the extensibility factor.

I got a Milestone (GSM Droid) because it was the first phone that really surpassed the iPhone on pretty much all fronts. All? Well, the UI is actually not quite as smooth as the iPhone, and can be a bit erratic at times, and it's very minor. Maybe it was just a matter of getting used to it, because I don't seem to have the problems that I had when I just got it.

Definitely better s the email app. Or email apps, because there are several. But I really, really like those a lot. To the point that I often read email on my Milestone even when I'm behind a computer.

The standard SMS app sucks, but here's where the superior Android app policy matters: there are several better SMS apps that you can install, and you can remove the original one. I can't replace the sucky iPhone email app with a more powerful one.

My Milestone is not perfect, however. I don't have root access, and I can't easily replace the OS itself with a superior version (does Cyanogen have a 2.0 version already?). I need to root it, and that just shouldn't be necessary. But most people wouldn't need that anyway.

Re:That's peachy

[mcvos]

Actually my HTC Hero is pretty good at non sucking, every aspect except the 3d games performance is way superior to the iPhone...

Smaller screen. Less resolution too, I think.

Re:That's peachy

[MemoryDragon]

Screen is slightly smaller resolution more or less the same, the ui is superior in almost all aspects.

Re:That's peachy

[Some Bitch]

Actually, I've never met someone face to face that's had a Droid and not loved it... That's just my $0.02...

Hi, nice to meet you. The music player sucks to the point of unusability, I still have to carry my iPod Touch with me in order to listen to properly tagged MP3 files or audio books. Android doesn't know what the TPOS frame is for, iX does. Android can't play m4b files, iX can. Android 2.0 and at least the first release of 2.1 has a problem with MP3s skipping when the coverage changes top 3G and back.

I almost love it, but as a media player it's currently horribly flawed. The combination with an iPod Touch is still better than an iPhone but I'd rather have the phone work properly as a media player rather than the current half assed attempt.

Re:That's peachy

[JAlexoi]

Android is becoming more and more "fluid" across the board. That is why Apple is hitting back. 3 years ago iPhone was the best package you could buy, as smartphones went, but now I am a happy Nexus One user and an unhappy iPod Touch user(the only redeeming feature is the 16GB storage and the price I got it at).

Re:That's peachy

[poptones]

I have owned a G1 nearly a year. My brother has an iphone. While he was screwing around with jailbreaking it and trying (and never managing to) use it tethered, I didn't have such issues. About the only "cool" thing he could do that I did not find at first was the geolocation GPS thingy - and google maps has worked a long time now.

I don't own a mac, will never own one. I have my own picture host service that affords me plenty of online storage, and I use gmail and the contacts list and so never have to worry about having access to all my data. In short, my gphone is hella lot more convenient for me than my bro's iphone seems to be for him, and neither of us are what I would call "power users."

You are right about one part though: I really don't give a flying fuck what cpu my phone uses, or how many GB or mhz it has - all I care about is the end to end experience. And for that, from my phone to my gnome desktop and evolution integration, the gphone rocks. The ONLY thing I find lacking is integration of bookmarks, and I'll bet there's an app for that I simply haven't found because I never thought to look until just now. hmmm.

Re:That's peachy

[zigfreed]

It's an iPod that makes phone calls. I base the success on the popularity of the iPod, not the phones it was destined to replace.

amazing!

[vrmlguy]

After reading the article, I was able to port my entire Java repository to Android in just a few minutes. Of course, that consists of three versions of "Hello, world!"

Re:amazing!

[Bluesman]

You joke, but in Java that represents a substantial amount of work.

Re:amazing!

[TwinkieStix]

You can import class files compiled from other languages such as Scala, Jython, etc.

http://blog.headius.com/2009/08/return-of-ruboto.html
http://www.scala-lang.org/node/160

With Java's built in support for dynamic languages, and a little more time, you'll able to compile any language of your choosing into a .class that can be used in Android.

Re:amazing!

[CharlyFoxtrot]

You know I can't count the number of times I sat before an "enterprise" java application and thought to myself "I wish these people were making the software that runs on my phone !" Yeah they're REAL programmers not nansy pansy "designers" like those iPhone types.

Thanks for Playing

[His Shadow]

"although it won't look pretty or run as fast...". That's all, Folks!

Re:Thanks for Playing

[WrongSizeGlass]

Ugly multitasking on an Android is not better than slick single-app execution on an iPhone. It's only a different experience.

Re:Thanks for Playing

[Nerdfest]

... on a multi-core server. Personally, I think you'd be an idiot to expect it to be either. It obviously won't run as fast, and if you haven't created the display to scale to a small screen properly, I wouldn't think it would look good either.

Re:Thanks for Playing

[starfire83]

You can blame that on pre-packaged apps that the carriers put on. Not to mention putting high-end UIs on two year old hardware (HTC Hero). Go over to the SDX forums or Android Forums and read up on how to root your Android and kill those pieces of crap apps that run in the background slowing everything down. Get Advanced Task Killer too. I've put the latest SDX kernel and recovery onto my Samsung Moment and it runs blazingly fast and is free of a lot of cruft thanks to a handy shell script written by Joey at SDX that removes the pre-packaged apps that take up space as well as make themselves run in the background. It's also still fully functional with no problems. Remember, with the proper help and setup Android is still a Linux machine and has tons of flexibility built-in. Besides jail-breaking your iPhone, you don't get much more flexibility out of it. http://www.sdx-developers.com/ http://www.androidforums.com/

Re:Thanks for Playing

[JAlexoi]

Maybe you should understand the philosophy and how to do actual multitasking on Android.

meh

[LiquidCoooled]

iphone and android aren't really inclusive.
open source is meant to be about choice and freedom.

the nokia n900 + maemo allows multiple languages and frameworks (x11 gtk qt sdl gles and whatever else you can throw at it) to peacefully coexist together :)

don't take my word for it though, i'm biased

Re:meh

[modmans2ndcoming]

well... lets develop for an OS that is available on .0000009% of smartphone hand sets then since it is the most open.

Re:meh

[gbjbaanb]

You mean Windows? you can't possibly mean Nokia - which, although Maemoblin is very very new, should do well given Nokia's business-friendly sales and general market dominance.

Re:meh

[modmans2ndcoming]

No... Maemo... nokia is a handset maker, not an OS.

Re:meh

[Nerdfest]

There is also a vast collection of open source software that will run just fine on the device with a simple recompile. Another of the advantages of open platforms.

Re:meh

[h4rr4r]

The n900 still uses binary drivers, which means when the n901 ships good luck with that.

Re:meh

[LiquidCoooled]

of course it does, but how many apps actually bang the hardware enough to care?
user space is open and inviting, let the frameworks deal with the nitty gritty.

writing in qt or sdl or gtk or even native x11 apps doesnt touch any of that stuff.

who says that when iphone+4 comes out or the next android device comes out your apps will be compatible there?

Re:meh

[Microlith]

It does?

Can you point out the binary only 3rd party module?

Re:meh

[aliquis]

Maemo is already dead, kinda.

It don't sounds like the N900 will get anything from Moblin and I guess future phones won't get Maemo so ..

http://moblin.org/

Re:meh

[Lunix Nutcase]

who says that when iphone+4 comes out or the next android device comes out your apps will be compatible there?

And how much did apps break between the original and the 3G version? And then between 3G and 3GS versions?

Re:meh

[Microlith]

Moblin is dead too, effectively.

Anything that would get either is getting MeeGo, and the Maemo and Moblin communities are moving in with force. The N900 is already marked as a target device for the core, which means an effort to bring an actual MeeGo install will not be an uphill battle.

The N900 is getting Qt libraries as part of the base OS, however, so it will be compatible with MeeGo applications.

Re:meh

[BitZtream]

Uhm, if you think Windows isn't a major player in the smart phone market than you haven't opened your eyes recently. I'd estimate WinMo to have about 2 to 3 million times the market penetration of Android, and thats not an exaggeration.

Re:meh

[aliquis]

Ok, so it will come for N900 to then? Not just the next phone in the line?

Then all is fine.

Regarding Moblin vs MeeGo I didn't remembered the name but rather just googled Maemo Intel and picked the first name I saw and assumed it was right =P

Re:meh

[rdnetto]

I agree. Where's the article extolling the advantages of Maemo/Meego over Android?

Re: Meh

[Ecuador]

I am a proud owner of a N900 for a week now. It is the first time a phone truly amazes me, and that is of course all thanks to the OS. I am a mobile developer, so I have so far developed for and owned BREW, Symbian and iPhone OS devices. I liked developing for the iphone, hated the other two, but from a user standpoint I did not enjoy any device, since even browsing was painful (no, I don't consider the iphone's ultra low res usable), and they wouldn't let me do much more than that.
Enter the N900. Android is not a unix machine in your pocket, it is a jvm running java apps on top of a unix kernel, when Maemo is a full debian based distro. Things like opening several browser windows, running apt-get install in the background and switching (kind of expose-style) between them is easy on the device. With an 800x480 res and a full browser (Mozilla based with flash and everything) it is the first time I can browse from a phone (as I am doing right now). As a developer I really appreciated that I could do "apt-get install subversion", sync with my svn server and edit my code with vim.
Don,t get me wrong, I also like android and usually recommend something like a nexus one to nom-power users, but I am sure the average slashdotter would really get excited with Maemo, not android.

Re:meh

[gbjbaanb]

that'll be the old versions of WiMo, and I was talking about the market penetration of Nokia.

it's practically Nokia #1, Blackberry #2, everyone else (including the iPhone) a distant #3.

Re:meh

[trickyD1ck]

Same for closed source. Although, with a simple recompile user experience will suck in any case.

Re:meh

[mcvos]

the nokia n900 + maemo allows multiple languages and frameworks (x11 gtk qt sdl gles and whatever else you can throw at it) to peacefully coexist together :)

don't take my word for it though, i'm biased

I'm not. I didn't buy an n900 because I expected a lot more support for Android (and because a Milestone just looks so much better), but Maemo is definitely the ultimate geek smartphone OS. And you're really the owner of your own system: you're root, unlike on Android or the iPhone.

Re:meh

[mcvos]

You mean Windows? you can't possibly mean Nokia - which, although Maemoblin is very very new, should do well given Nokia's business-friendly sales and general market dominance.

At the moment, Maemo is only available on a single modern handset, which doesn't receive a lot of support in marketing, app stores or hype. Yes, the N900 is pretty amazing, but it's a bad platform choice if you want to reach lots of users.

No it will not

[LWATCDR]

"Not only that, but all of the code from other Java programs will run on your Android phone — although it won't look pretty or run as fast as it does on multicore servers.'""
No because if it has any type of UI odds are that uses swing or awt. Not only that but I doubt that the Android JVM has all the standard libraries that are available on Sun Java.
Yes they will know the syntax of the language but the libraries will be totally different.
Not to mention that is probably very little code running on servers that you will want to run on a phone.

And yes I write in java and I have an Android phone and I have looked at the Android SDK.

Re:No it will not

[peterwayner]

Yes, a fair point. I shouldn't have used "all", although I think you could probably get Swing and even AWT working with a shoehorn.

But it's got a JVM and JVMs take byte code...

And while I wouldn't want Derby or some other serverside process gumming up my phone, I do like the ease of using the same packing and unpacking routines on both platforms. They're just more likely to work a bit better together.

Re:No it will not

[gbjbaanb]

And to top that, its not real Java but the embedded/mobile version so your server-side entierprise java bean based app will just not work. Sure, your java devs will be familiar with the language, but frankly, they're all converting themselves to C# nowadays.

I always thought Android's Dalvik VM was a mistake - they alienated the native C/C++ developers who might have jumped from Symbian to it, and alienated new programmers who think that Java is a lagacy language from the 80s. They'd have been better advised to write a python compiler and use that instead, as long as they allow C library code. In fact the whole Android environment should have been written as C libraries that any language could access without restriction - then you'd get devs from all over using it.

Re:No it will not

[loconet]

But it's got a JVM and JVMs take byte code...

Actually, Android uses Dalvik VM which uses .dex files instead. So no, you can't just take any traditional bytecode file and run on Android straight.

Re:No it will not

[SoftwareArtist]

Yes they will know the syntax of the language but the libraries will be totally different.

Actually, they're mostly the same. They took the standard libraries from Apache Harmony. It's missing a few packages that aren't appropriate (like Swing), but most of what a Java programmer expects to be there, is there.

Here is the index to the API docs: http://developer.android.com/reference/packages.html. As you can see, a large fraction of the java.* and javax.* packages are there.

Re:No it will not

[LWATCDR]

Actually AWT is smaller than Swing. But porting them to Dalvik would be no small task and then you have the question of WHY?
They are not good frameworks to write a mobile app that uses a small screen and touch!
Yes if you know java you have an advantage but not the huge one you have stated.
I am working on porting an app I wrote in java to Android.
The backed processing will port but UI which is a good bit of it will not.

Re:No it will not

[Tapewolf]

The UI and the program entry point have to be written in Java. However, since it supports JNI, you can reuse all the program logic from C/C++, assuming you haven't stuffed it full of win32-specific stuff.

Re:No it will not

[binarylarry]

This is true, although Google wrote an eclipse builder that can take a class file and convert it to dex format.

So you can use class files directly, Eclipse and the Android SDK will take care of converting them for you (transparently).

Re:No it will not

[grouchomarxist]

It also supports .jar files, at least for libraries. I'm using a third-party jar in my Android application.

As long as the code doesn't use stuff like awt that doesn't exist on the Android platform you should be good.

Re:No it will not

[jmrives]

This is true. I have been developing a game app for Android. So, I am quite familiar with the environment. The Java implementation for Android is not complete. The one area that was missing for me is the RMI (remote method invocation for you non-java folks). That said, I have found the development experience to be a good one. I have nearly 15 years of Java development experience. I know a good development environment when I see one.

Re:No it will not

[hunangarden]

Android does not use swing or awt. It has its on UI model. It works pretty well and is easier to work with than swing or awt. Layouts can be done using a WYSIWYG interface and hand edited as needed (its in XML).

You can use many of the standard java jdk classes (java.lang, java.util, java.net, java.math, java.sql, etc, etc), but sure you will have to learn some of the android specific libraries as well.

In general programming with Android is pretty easy for experienced Java programmers. But there is certainly some learning curve to get started.

Re:No it will not

[bar-agent]

I am working on porting an app I wrote in java to Android.
The backed processing will port but UI which is a good bit of it will not.

That is true regardless of whether you are dealing with a phone or not. Back-ends always port easily, GUIs never do, unless you just slap a separate GUI library on top of the native one. Another thing that doesn't port is support for OS facilities like system-wide search.

Fully cross-platform applications are a tantalizing dream, nothing more.

Re:No it will not

[Eric Smith]

Android has most of the standard Java classes other than AWT/Swing. I was pleasantly surprised to find that it even has the Java reflection API.

Re:No it will not

[LWATCDR]

Except the same app works great on OSX, Linux, and Windows.
And is used on all of them regularly.
Cross platform at least for some apps does work today.

Re:Shitty programmers writing shitty code.

[MemoryDragon]

Actually as far as I can judge the indian guys, they do whatever rolls in money, using another language is not a barrier...
Wrong conclusion, and I also worked with people from India who really could write code, ok they are the minority but they exist.
But given how many people in the west write shitty code I assume the percentage is pretty equal!

Developers Developers Developers

[Archangel Michael]

Android not only competitive but in fact a better choice than the iPhone for many developers, largely due to its Java foundation.

Now I don't want an Android phone. I thought it would be good or better for me as a USER, not as a developer. Silly me.

Re:Developers Developers Developers

[zuperduperman]

You should definitely get an iPhone - they are designed to work even for people with severely compromised logic such as yourself. Good at X does not imply Bad at Y.

Re:Developers Developers Developers

[dangitman]

It being attractive to developers is very much a good thing for you as a user.

Actually, that's not necessarily true.

"Being attractive to developers" is often code for "easy for lazy developers to use." For example, Visual Basic is attractive to many developers, but the resulting software often isn't very good for the users. What's good for users is having the best developers write your applications. And the best developers don't tend to be lazy or averse to learning new techniques.

There are countless examples of this in effect action - from terrible Enterprise software written specifically for IE6 or Office, to Flash games versus console games. It's generally not easy to program for a game console, yet that's where the AAA games are. It's much easier for the developer to slap together a Flash game.

Re:Developers Developers Developers

[dangitman]

A developer is a person or organization that writes software. It doesn't necessarily mean they are good developers - that would be a variation of the "No True Scotsman" fallacy. It's a way of denying or disowning bad developers. But in reality - there are legions of bad developers, and software is sold every day that is developed with tools like Visual Basic (or worse) - or with good tools, but poor technique.

There are many companies making big money on awful code. If they don't count as developers, then what are they?

Re:Developers Developers Developers

[pydev]

It's generally not easy to program for a game console, yet that's where the AAA games are.

No, the AAA games are on the PC, in addition to a lot of crap.

Making a platform hard to program will mean that the average quality of a product is better (since it has a high cost of entry to develop for it), but it will also limit overall application availability. In the end, you get more of everything on the easier-to-program platform: you get more AAA products and you get a lot more crap too.

Re:Developers Developers Developers

[rdnetto]

It matters when you're both. That said, I avoided Android cause of its Java foundation and got a N900. haven't regretted it for a second :)
Also, the more power the manufacturer gives to the developers, the more power the developers will be able to pass on to the users in a user-friendly GUI.

Re:Developers Developers Developers

[Archangel Michael]

You missed my point. Completely. When I read X is better than Y, I expect it to be for the PRIMARY user of X and Y, not people tangentially associated.

If I read that a Car A is better than Car B, then read down further that the only thing being considered is how easy it is for a Mechanic to change sparkplugs, then the review is simply missing the point. My Lawnmower has very easy to change sparkplugs, but I wouldn't want to use it as a car.

Not only that, saying something is better for one class of people (developers) than another product that doesn't take into account all aspects useful for that class of people, doesn't make much sense either. In this case writing an app for Android is better for a developer how? IF it doesn't include generating revenue (selling) then it fails to even address one of the more basic criteria I would think is important to a great deal of developers.

The last thing I'd like to point out is that saying Java (or whatever) is better than C# (or whatever) is personal preference and may or may not actually be "better" for developing anything.

So the point I was making was more about the stupid "X is better than Y based on this very narrow viewpoint" article. Give me a narrow enough viewpoint and I'll show you that Dictators are better than Elected Officials.

Sorry you can't see the forest because of the trees.

Not as fast?

[dave562]

From TFA
code from other Java programs will run on your Android phone -- although it won't look pretty or run as fast as it does on multicore servers

I'm not a developer but once of the criticisms I see constantly leveled against Java is how slow it is. Are there any mobile devices out there that can really handle even moderately complex / processor intensive Java code?

Re:Not as fast?

[Anonymous Coward]

It's no longer 2000. Outside of heavy mathematical computation (the kind where your entire dataset fits in your L1 cache and the entire thing streams through arithmetic, bitwise ops, and pointer magic), Java is acknowledged to be as fast or faster than C++, for competently-coded values of Java and C++.

Re:Not as fast?

[0xdeadbeef]

Are there any mobile devices out there that can really handle even moderately complex / processor intensive Java code?

Yes. All of them.

Whether you're allowed to is a different matter entirely.

Re:Not as fast?

[shutdown -p now]

Are there any mobile devices out there that can really handle even moderately complex / processor intensive Java code?

My cellphone is from 2007 (Nokia 6300), and it wasn't considered a smartphone even back then. However, it happily runs Java 3D games - granted, the graphics is rather primitive, and more reminiscent of what we saw on PCs in mid-to-late 90s, but still.

Re:Not as fast?

[scotch]

Java is getting closer, but not "as fast or faster" than C++ or C. At least the last time I looked at any half-way competently executed benchmarks. Maybe you have some new benchmarks for me to look at?

Re:Not as fast?

[bar-agent]

Are you on crack? Java is as fast as or faster than C++? I hope that was sarcasm.

This can happen, given JIT on-the-fly profiling and optimization. It is not true in the general case — in the general case, performance is comparable — but Java can be faster when the C++ code has a lot of const pointer references, uses the default new/delete/malloc/free implementations, or avoids using sophisticated processor instructions for compatibility.

http://en.wikipedia.org/wiki/Java_performance

Re:Not as fast?

[Xest]

Read what it says again- it's not saying that Java is slow, it's just pointing out that apps wont run as fast on a phone as they do on multicore servers, because phones have much lower performance hardware.

Java in terms of speed is fine, it's as fast as C++ apps in the overwhelming majority of cases, and often even faster due to being able to optimise for the specific system the code is being executed on, rather than having to optimise for the general case as C++ compilers have to do.

Re:Not as fast?

[Rakshasa Taisab]

So you're saying that badly written and compiled C++ is slower than highly optimized Java? Color me pink and put a clown nose on my dick, I think I was just flabbergasted.

Windows Mobile

[Dan East]

Then according to his logic, Windows Mobile is better than Android and iPhone combined, because not only can it run Java apps, but you can author software for it in practically any mainstream programming language.

What about Blackberry? It is a pure Java based platform, even more so than Android.

I just think it's silly to say "This device is LISP based, so it is better than device X because some corporation might have LISP developers sitting around that can write apps for it in a language they're used to!"

Re:Windows Mobile

[owlstead]

The Java apps you can run on any mobile device are - by necessity - extremely limited. Java on the Android is much more like programming the normal JDK. There are many runtimes loosely based on the Java platform, but you would not want to use them for anything like an Android device. (I don't know the Backberry runtime so I won' t comment on that.)

Having a large base of programmers that know the language and a large part of the API is certainly an advantage. I don't think Objective C is very high in the list of mostly used languages. So it's certainly an advantage. How big an advantage is up to discussion. (If you are not convinced, replace Objective C by a true niche language with it's own API. How many apps would you expect in the app-store then?)

Re:Windows Mobile

[MrCrassic]

But if you read the article, you would see that he goes in depth about actually developing for both platforms. Windows Mobile was actually pretty good on that front, but wouldn't be better than Android because:

1. Most of the core WinMo libraries are on Windows,
2. It's not open, and
3. It's pretty unreliable as an OS in comparison to the others on similar hardware.

Re:Windows Mobile

[Dan East]

My game engine, which has been used in a Top-100 iPhone game, is 99% C++, and only has the minimum amount of Objective-C code required to handle various system events (around 200 lines of code). Of course applications intimately integrating with the iPhone's GUI API would require much more Objective-C. So Objective C is not the only officially supported language for the iPhone for generating native binaries.

Re:Windows Mobile

[binarylarry]

You could do something similar with a Java+C++ application on Android. The Java parts interface with the application apis via dalvik, while the native parts do the heavy lifting.

The Dalvik virtual machine that Android uses is just now starting to get JIT compilation features. It will be a lot more competitive with statically compiled code once JIT is in regular use and starts to mature.

Compare HotSpot to natively compiled code. Today it's very competitive in most cases and you can develop much faster in Java and produce cleaner, more error free applications in less time.

Re:Windows Mobile

[Xest]

Well yeah, you're actually right, as it happens, Windows Mobile really is MUCH simpler to develop for than any other phone platform because you get to use Visual Studio and .NET. Just because WinMo itself has been a bit crap for it's past few releases, doesn't mean it doesn't beat the iPhone and Android in terms of ease of development.

I think you're under the assumption that he's saying Android is better than the iPhone overall because it's easier to develop for, he's not, he's saying it's better than the iPhone for developers who actually want to write apps for that phone, which is absolutely true, just as as you say, Windows Mobile is indeed even better again for developers to develop for.

Re:Windows Mobile

[JAlexoi]

You can actually do 99% of the code of an app for Android in C/C++ also. Because the Launcher application/framework is Java, your point of entry needs to be a Java application, but that is the extent of the requirement.

wake me up when it catches up

[thanasakis]

You can buy and play FIFA10 or even Grand Theft Auto on the iPhone. The games are a pretty good indicator IMHO. When complex and expensive productions from big studios start coming out for a platform, you know that the platform is popular.

And if you think Java makes any kind of difference, think again. The guys that are developing these applications do not seem to care. It's not about happy programmers, it's about happy users. And right now the iPhone still has the edge.

Re:wake me up when it catches up

[Itninja]

When complex and expensive productions from big studios start coming out for a platform, you know that the platform is popular.

All one can really infer from that is Apple is in bed with big game studios.

Re:wake me up when it catches up

[Mark19960]

Some of us carry smartphones to increase productivity, not play video games on a 4 inch screen.
If grand theft auto on your phone is a selling point... god help us all.
If you want to play games, buy one of those portable game widget things that Nintendo or Sony sells.

Re:wake me up when it catches up

[binarylarry]

It works for these guys: http://www.google.com/

Maybe they'll hit it big someday and create a competitor to Android.

Re:wake me up when it catches up

[yogibeaty]

Really? Productivity defined as?

Would an excel spreadsheet render properly on a Droid? Do you code in C# on the Nokia? Pray tell, what forms of productivity do you increase, Almighty one?

Re:wake me up when it catches up

[dangitman]

All one can really infer from that is Apple is in bed with big game studios.

Oh really? What do you mean by "in bed with"? You don't think it's possible that game developers just thought it would be lucrative to develop for a popular platform?I suppose Apple is also colluding with all those fart app developers, and bribing them to develop for iPhone.

If Apple were "in bed" with the game developers, then wouldn't we see more games released for the Mac? Your allegation seems pretty far-fetched given the antipathy game studios have historically had for Apple.

Re:wake me up when it catches up

[dangitman]

Some of us carry smartphones to increase productivity, not play video games on a 4 inch screen.

And some people use smartphones to socialize and play games on a 4 inch screen.

If you want to play games, buy one of those portable game widget things that Nintendo or Sony sells.

So, someone who already has a smartphone should spend potentially hundreds of dollars, and carry a separate device, rather than spending a few bucks for a game on a device they already own? Why, just because you don't approve of games on a phone out of some misguided ideological notions of purity and productivity?

Also, have you seen the relative difference in price for Nintendo DS and Sony PSP games versus the ones for the phones?

Re:wake me up when it catches up

[rxan]

You can buy and play FIFA10 or even Grand Theft Auto on the iPhone. The games are a pretty good indicator IMHO. When complex and expensive productions from big studios start coming out for a platform, you know that the platform is popular.

You're talking about porting applications though. That's different from developing apps "from scratch" for a platform.

The reason there are so many games on the iPhone isn't because it's "easier" to develop for. I'm not saying it is easier. It's because it supports C++ and the major dev houses can easily throw their code on it and run it. Yes there are some modifications, but not much is required. Most games aren't written in Java for the obvious performance reasons.

Re:wake me up when it catches up

[UseCase]

Yep. Lots of us tech heads forget that its about the users. I don't have a problem developing for iPhone or Android. I just following the money/users. I want to put products out that people outside of my peer group will use.

Re:wake me up when it catches up

[Anonymous Coward]

Why? Why would I want to do this? Why on earth would I ever want to buy, and cary around, yet another device when one that I already have a fully capable playing one of these games... if one of these games is what I to play?

Re:wake me up when it catches up

[mdwh2]

you know that the platform is popular.

Non sequitur.

I know a platform is popular, by looking at the sales figures and market share. In the mobile market, that's companies like Nokia, not Apple.

Re:wake me up when it catches up

[mdwh2]

Internet access. Mapping software. Communication. Taking/showing photos and video. Playing music. Running useful utilities (there's more to life than spreadsheets). And *gasp* phone calls.

If all you want to use it for is playing hand held video games, then there are better - and more popular, incidentally - devices for that.

And come on - every time someone points out one of the many basic features that the Iphone lacks or lacked, we get no end of "Why would I want to do that?" So here we are, saying "Why would we want to run video games on a phone?" You only cling to this as being an important, because it's something that the Iphone can do. Next, you'll be telling me how fundamentally important you think multitouch is.

Re:wake me up when it catches up

[VocationalZero]

Also, have you seen the relative difference in price for Nintendo DS and Sony PSP games versus the ones for the phones?

And have you seen the relative difference in quality for Nintendo DS and Sony PSP games versus the ones for the phones?

Re:wake me up when it catches up

[Itninja]

Mac != iPhone

The Mac runs a long-term OS for a desktop computer costing thousands of dollars. The iPhone is a $400 toy/phone that runs an OS that might go 18 months between major updates. Any intern with even a marginal level of skill can "develop" and app for the iPhone. When the big boys put out their games, etc it's less likely because they are thinking 'what a great platform!'. It's far more likely they are told by Apple 'put this game on our platform and we will give your company X number of $$'s'.

Since developing an app for such a nubile platform is something they could do in a week or two with maybe two FTE, why not?

Re:wake me up when it catches up

[dangitman]

I think it's up to him to come up with some evidence for the claim, not for me to disprove it - and no, having some big-name game titles on the iPhone is not evidence.

Re:wake me up when it catches up

[dangitman]

And have you seen the relative difference in quality for Nintendo DS and Sony PSP games versus the ones for the phones?

There's actually not that much difference, plenty of iPhone games have nice 3D graphics, etc. But if you're not a "gamer" and just want to play games casually - you're not really going to care that DS and PSP offer somewhat better titles. Just like the average computer user doesn't need an 8 core workstation with 16GB of RAM, the iPhone meets their needs at a much lower cost.

I don't care either way, as I'm not really into portable gaming. But the argument that people shouldn't play games on their phones is just fucking stupid.

Re:wake me up when it catches up

[dangitman]

Mac != iPhone

Wow, such a genius statement! I never realized that the iPhone is not the same as a Mac! Thanks for enlightening me.

When the big boys put out their games, etc it's less likely because they are thinking 'what a great platform!'.

No, they don't care about the quality of the platform, they care about the income. They saw even tiny independent developers making good money on the iPhone and decided they wanted some of that money. Not to mention that the games industry has been thinking about how to "monetize" mobile phones for quite some time now.

It's far more likely they are told by Apple 'put this game on our platform and we will give your company X number of $$'s'.

That doesn't seem likely at all what evidence do you have of it? Why would Apple just give away money like that? That's not the way the company has ever operated.

You need to take off the tinfoil hat and use logic.

Since developing an app for such a nubile platform is something they could do in a week or two with maybe two FTE, why not?

This contradicts everything you wrote before it. So, which is it? Did they do it because Apple bribed them, or because it's such an easy thing to do? I'm sure you'll be forthcoming with those financial documents showing free money transferred from Apple to the game developers.

Re:wake me up when it catches up

[Xest]

"Most games aren't written in Java for the obvious performance reasons."

What obvious performance reasons would they be?

Java performs perfectly well for game development, the reason developers use C++ still is partly because it's the only language shared between all gaming platforms (PS3, Wii, 360, PC) and partly because it's historically what their developers were trained in because it was historically faster.

There are no performance issues with Java nowadays, it's a complete myth. See here, and keep in mind this page goes as far back as 2004:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Re:wake me up when it catches up

[trickyD1ck]

whatever works...

Re:wake me up when it catches up

[JAlexoi]

Mobile Chrome, same damn shit as mobile Safari(WebKit anyone?). Chrome has a better JS engine though - Google V8.
Android's media player, at least the one in Nexus One, is far more simpler and less confusing than in my iPod Touch. Playlist creation on the device PERIOD!(More than one.)
Multitouch is optional, realy it is. There is a very little amount of cases where it's essential. I have not seen a single time a stack trace on my phone, unless I'm actually in debug mode.
FYI: Nexus One and most new phones don't have Zoom In/Out buttons.

Re:wake me up when it catches up

[jamshid]

Couple of things to keep in mind in the iPhone vs Android development wars:

1) Android also allows native (C/C++) development with the Android Native Development Kit (NDK): http://developer.android.com/sdk/ndk/index.html#overview

2) If Android apps do become popular and a competitive advantage, AFAIK there's nothing to stop Apple or someone else from porting Dalvik and underlying libraries and services to the iPhone. After all, both the iPhone and Android are at their cores just little unix boxes. If so, the project should be called Blade Runner. The Warner Bros lawsuit would be good publicity.

Re:Shitty programmers writing shitty code.

[modmans2ndcoming]

As far as I can tell, 99% of the iphone apps are pure and utter shit.

Free phone.

[RightSaidFred99]

Another great thing about Android is developers can get a free phone.

Re:Free phone.

[phantomcircuit]

Who cares about a free phone. With a top iPhone app I could retire, BEFORE I get out of school!

Yes, there *is* and Emacs mode for this

[helixcode123]

I don't like Eclipse, but I don't have to since there is an emacs mode for Android development.

Re:Shitty programmers writing shitty code.

[Duradin]

FYI Android has fart apps as well.

Re:C? For programming C you should need a license!

[TheRaven64]

At least memory management in Java is easier.

Having seen memory leaks in every nontrivial Java program I've used (which, admittedly, is not many), I'm not certain about this. In C, memory management is hard, but that means that people think about it. In Java, memory management is implicit (which is not the same as easy), which means that people don't think about it. They don't think about the correct times to use weak references, and they end up leaking memory.

Java also has the distinction of being the language used for the only program I have ever seen with a CPU leak: Start it and watch the CPU usage slowly climb over the next few hours (while not actually doing anything, or taking any use input), until it's at 100% about 3 hours later.

Java as an "advantage?"

[Zigurd]

That Java is something that makes Android superior to iPhone is a dubious claim.

Objective-C has advantages, such as that it is compiled. While Android has lots of libraries implemented in C and C++ that speed execution of Android applications, and developers can choose to implement intensive computations in C using the NDK, Objective-C requires no JNIs or other complications of splitting an implementation between Java and C/C++.

X-Code is a purpose-built, clean-sheet IDE that may lack a few power features found in Eclipse, and Eclipse has numerous plug-ins, but Eclipse also has a pretty diabolical UI, especially compared to software from Apple.

Java, Eclipse, and the other Android SDK tools are more than good enough, but they are not a big advantage, or, depending on your tastes, any advantage. There is a rough equivalence here that will probably extend to Android doing for client Java what iPhone did for Objective-C - making it popular. That is, Android apps will probably be the most common form of interactive client Java apps, if they have not already eclipsed AWT, Swing, SWT, and other Java UI libraries. This is going to have a big influence on Java, considering the fact that iPhone programming books crowd the top of the list or programming books at Amazon.

Android's advantage is in openness. Android developers are not just app developers. They can be system customizers and extenders. They can be technology vendors to a large number of OEMs using Android. They can have all kinds of products, customer, and business models, throughout the mobile economy, not just retail customers of the app store.

Re:Java as an "advantage?"

[MemoryDragon]

I personally do not think the UI in Eclipse is worse than the one from XCode but it adds refactoring which objective C ides lack.

Re:Java as an "advantage?"

[BitZtream]

Which year are you living in, Xcode doesn't seem to have a problem doing it for me.

Of course, I've had refactoring in notepad for years. Search and replace is hard.

Re:Java as an "advantage?"

[furball]

I think refactoring was added to Xcode since 3.1. It's under the Edit menu or if you're hotkey around it's Shift-Command-J.

Re:Java as an "advantage?"

[binarylarry]

Wow, you must be a really good programmer if you don't know the difference between search and replace and refactoring...

Re:Java as an "advantage?"

[Space cowboy]

Did you look under [Edit] -> [Refactor] on the menu ? Or type 'refactor' into the help search ? Simon

Re:Java as an "advantage?"

[shutdown -p now]

How well would it refactor selector names when type of receiver is not known statically?

Re:Java as an "advantage?"

[recharged95]

Also, Android's advantage is the JVM/DVM. Virtual machine, sandboxing, and such is cleaner to a developer to work with and can be used to keep users aware of where they are going/visiting/doing. It is the way to go for an app that really works in the cloud. Obj-C and the iPhone SDK are good for desktop-like mini-apps. As for networked/cloud apps, it has issues, which is another reason why the Apple appstore is locked down--they learned their lesson from Microsoft Windows: if you keep it open for developers and give full control of the hardware/filesystem, they're going to find holes and they will be exploited.

One can say each has its merits, Android more cloud network/centric and iPhone SDK more standalone/desktop-ish. Hence why games clearly work better on the iPhone (desktop-console games > network games currently). I tried WebOS and it's very promising more JS/Flash centric style, but it has a way to go as well. The Android team should look into JavaFx along with Flash for their OS enhancements...

I found a lot of graphics power and h/w usability with the iPhone SDK over the Android SDK, but I and other iphone app-devs rely on Apple's closed nature for security with webapps. I talk to devs and most don't even think about security--the SDK pretty much obscures that concept. Otherwise, it's easy to write an app that takes CC data, personal data, usage tracking, etc.. without knowing it's accessible. Also, when the iPhone crashes, it crashes hard whereas I can still hold a phone call on Android hardware if an app crashes (or force close it).... Of course, Apple is addressing security thru deployment via XCode settings (and the millions of menus/plists) instead of the VM and XML files (Android).

And lastly, ok, fanboy comment, but Eclipse tabs > XCode windows for editing. Really.

Re:Java as an "advantage?"

[BitZtream]

The joke is that most people think that when they rename something they are refactoring it, in which case a search and replace would effectively accomplish the task. While technically they aren't wrong, thats not what people who knew what the word meant before it became a buzzword on an IDE menu think of when they see it.

I admit, it wasn't a very good joke.

Re:Java as an "advantage?"

[binarylarry]

Ah, my bad. ;)

Re:Java as an "advantage?"

[Skreems]

Objective-C has advantages, such as that it is compiled.

I would heavily dispute this. Yes, Objective-C is compiled, while Java is "only" byte-code. However, Java performance has improved dramatically in the past 10 years since the "Java is slow" meme started, while Objective-C still uses an amazingly slow message handler evaluation mechanism to resolve virtual function calls, instead of anything resembling a real OOP mechanism. Nice and flexible if you know how to use it, but a lot more potential for performance pitfalls if you don't have a really good handle on how to organize your classes.

Re:Java as an "advantage?"

[bar-agent]

How well would it refactor selector names when type of receiver is not known statically?

The type of receiver usually is known statically, because it is usually declared like FancyPants *tweed. How well does Eclipse refactor when you use Class.forName().getMethod()?

Re:Java as an "advantage?"

[bar-agent]

However, Java performance has improved dramatically in the past 10 years since the "Java is slow" meme started, while Objective-C still uses an amazingly slow message handler evaluation mechanism to resolve virtual function calls, instead of anything resembling a real OOP mechanism.

Objective C caches this stuff. Hell, it probably pre-populates the cache at compile time. We are talking about a modern compiler here, not some amateur effort from the 80's. It does data-flow analysis and everything. What you end up with is basically a vtable and a numeric index, plus a bunch of fallback metadata.

Re:Java as an "advantage?"

[kaffiene]

Refactoring does not mean just renaming your variables

Re:Java as an "advantage?"

[shutdown -p now]

It doesn't refactor that at all, but I dare say that seeing "id" in ObjC code is much more common than Reflection in Java code - and that's because the language is designed that way. For one, dynamically dispatched method calls are no different from static ones in syntax; for another, the syntax used to declare a reference to object of unknown type is very short and concise. Add to this the lack of generics, so collections etc are untyped, and you get an environment in which dynamic dispatch is much more prolific.

In Java at least, any code using Reflection will feature strings heavily, and IDEs, generally, never muck around string literals, so that is as programmer expects. In ObjC, you don't know whether "[foo bar]" is dynamic or not, and whether that "bar" will be considered by refactoring tools.

Also, I've heard many ObjC aficionados argue that ObjC is better than Java precisely because it allows for seamless dynamic dispatch and "duck typing". If it's such an advantage, then it would make sense to use it heavily.

Re:Java as an "advantage?"

[Xest]

"Objective-C has advantages, such as that it is compiled."

Huh? Java is compiled too, but it's JIT compilation which is better in that it allows optimisation for the specific device on which it is being run, not the generic platform on which it is expected to be run. The claim that Objective-C being compiled is an advantage makes no sense at all. The rest of that paragraph seems to be based on the false premise that Java is inherently slower than Objective-C which just simply isn't true.

"X-Code is a purpose-built, clean-sheet IDE that may lack a few power features found in Eclipse, and Eclipse has numerous plug-ins, but Eclipse also has a pretty diabolical UI, especially compared to software from Apple."

I do agree, I'm not a fan of Eclipse, but then, Apple's software doesn't come close to beating Visual Studio, so in this respect it's really Windows Mobile that has the IDE advantage of any platform. It's a shame really there's no official support for NetBeans rather than Eclipse for Android, NetBeans is IMHO, much better.

"Java, Eclipse, and the other Android SDK tools are more than good enough, but they are not a big advantage, or, depending on your tastes, any advantage. There is a rough equivalence here that will probably extend to Android doing for client Java what iPhone did for Objective-C - making it popular. That is, Android apps will probably be the most common form of interactive client Java apps, if they have not already eclipsed AWT, Swing, SWT, and other Java UI libraries."

I'm not sure you know too much about Java, but it's far and away the most commonly used language across the globe and has been for many many years. Android is small fry in terms of overall Java development, even on the client side. When you go into a Doctor's surgery to book your appointment, use a system to pickup your prepaid Cinema or Airline tickets, get served by someone at checkout, the chances are these systems are all client side Java. Even on the desktop there are some prominent Java apps- Vuze (Azureus) is a popular BitTorrent client for example that has a pretty nice interface.

Regarding iPhone books as Amazon top sellers, it's also not really a meaningful metric (although I just had a look myself, and it doesn't even seem to be true- are you sure you weren't looking at your recommendations?). This could simply because Android has great online documentation for example.

Java certainly is an advantage, if not only because it's prominence as a language and portability between Windows, Linux, Mac, Android phones, Blackberrys, Unix and so forth means that even if you have to write the UI, you don't have to re-write the libraries. As pointed out above, it's not as if performance is an issue in Java either, see here, and keep in mind this page is now 6 years old:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

The only thing Java really does need is IDE improvements, if NetBeans or Eclipse were taken up to the quality and usefulness of Visual Studio then that'd be awesome.

Re:Java as an "advantage?"

[Skreems]

My understanding was that since event handlers can be added and removed at runtime, the system has to check every type back up the inheritance tree until it finds a handler, so for example stuff like falling back to a default handler on the Object-equivalent type can be very expensive. There are ways to use it well, but it's possible to really badly screw it up, pretty quickly.

Re:Java as an "advantage?"

[mswhippingboy]

if NetBeans or Eclipse were taken up to the quality and usefulness of Visual Studio then that'd be awesome.

Huh? You're kidding right?

I use Eclipse and VS all day long every day. IMHO, Eclipse is far and away the better IDE any way you slice it. It also talks to everything and it doesn't cost thousands of dollars (yea, I know there's an Express edition, but if you intend to do Enterprise development you better be ready to take out a loan).

Eclipse gets slammed a lot for it's supposed "diabolical" UI, but I just don't get that. It feels perfectly natural to me and organized just the way I would expect it to be. I can grab a new plugin as needed for additional language support and everything works the same as other language support. I don't need to spend days scratching my head or reading books to know how to use a new feature, it just works as I expect it to. To each their own I guess.

Re:Java as an "advantage?"

[Xest]

I'd guess if you believe that, you don't really use Visual Studio, or at least don't use it to the extent you're making use of some pretty important features like the debugger and refactoring tools.

VS is far and away better than Eclipse, because it simply has a better UI (more tools at your fingertips), better refactoring support, better intellisense, better dynamic help, better debugging.

Eclipse is also slower, the plugin system is flawed meaning you often need multiple copies of the whole IDE.

The whole Eclipse vs. Visual Studio thing certainly isn't one of personal opinion, VS just does everything Eclipse does, and does it better, and does more to boot, that's the problem with Eclipse. It's not that Eclipse is necessarily bad, just that VS is simply years ahead of it in terms of features and productivity. Visual Studio's intellisense for example is simply unparalleled in any IDE, let alone Eclipse's.

I use Eclipse for Android and PHP (Zend) development for what it's worth, I'd just much rather be using NetBeans (which I've used in the past for Spring) or Visual Studio (which I use for WinForms, MFC and ASP.NET MVC).

Again, it's really not that Eclipse, or many other IDEs for that matter are necessarily bad, it's just from an objective standpoint VS simply does more, and does nearly everything better and allows you to be much more productive.

Re:Java as an "advantage?"

[JAlexoi]

Hm.. How about NOT NEEDING TO LEARN A NEW LANGUAGE for an advantage? You know that Java is probably the most wide-spread programming language ATM, do you? That is the whole point. Not how people feel about Java, not drawbacks of a VM based system and so on...

Re:Shitty programmers writing shitty code.

[shadowrat]

yeah, but they are free and open fart apps without all the drm. farts should be FREE!

Are you kidding me???

[thetartanavenger]

The pure Java foundation of Android

Android is not java. Yes it has java aspects but it is not java! It's bits of java with a customized Android API.It doesn't even run a normal JVM, it runs the Dalvik VM.

Not only that, but all of the code from other Java programs will run on your Android phone

Seriously, no. Just... no. Try compiling a program that uses Swing, AWT or javax stuff.

Don't get me wrong, I really like Android and hate iPhones. I have a G1 (lacking on RAM as much as it is). I've programmed for android although for fun, not the marketplace. I've even made my own ROM, again for fun. But claiming Android is Java and that everything that Java can do Android can also do natively is just naive

Re:Are you kidding me???

[Pastis]

You are both right.

There are multiple Java.

Android uses the Java language, not the Java APIs/SDKs, nor the Java execution environment.

Re:Are you kidding me???

[dzfoo]

So, when the poster of the article claimed that,

>> "[n]ot only that, but all of the code from other Java programs will run on your Android phone",

he actually meant all of the code from other Java programs that do not use any framework or libraries, just stock built-in stuff; you know, the Language.

I wonder how common those are, and if are interesting enough to want to run on a mobile phone.

        -dZ.

The only thing that counts.

[codepunk]

Having built some rather processor heavy apps for the iphone the only thing that counts to me is to be able to utilize every single cpu cycle. Writing apps for these devices is easy, writing apps that can perform is another matter entirely.

Re:Shitty programmers writing shitty code.

[owlstead]

Java does not just allow bad programmers to write sloppy code, it also allows good programmers to write better code (than in C/C++ and direct derivatives). Shitty programs are available in all languages. I managed to write a shit application in Lua in a minute flat. How difficult is it to grasp this concept? Do you really want a programming language that makes it harder to write manageable code, on purpose?

I'm getting sick of this argument. Most of my esteemed C++ colleagues like Java once they've actually tried it out for real. Unfortunately we don't always get Java libs for the hardware we are using.

Re:Shitty programmers writing shitty code.

[EastCoastSurfer]

Haha. If you know C and have an idea about OO concepts then obj-c is just as easy to learn as anything else. Many (most? all?) C libraries that don't rely on graphics should work just fine on the iPhone. Maybe it's C that's too hard for people to learn?

The future is arriving faster every day.

[ErikZ]

"...although it won't look pretty or run as fast as it does on multicore servers."

The Nexus One is multicore.

Platform choice and Cost

[Ewlkaz]

Developing for the iPhone requires OSX. Publishing an app to the market requires a $99 license. App Store rules are quite stringent. Developing for the Android Platform requires Windows, Linux or OSX. Publishing an app costs nothing. Market rules are a lot less stringent than App Store. iPhone OS is closed. Android OS is open source allowing developers to support phones that hardware companies have dropped.

Re:Shitty programmers writing shitty code.

[owlstead]

Because of education and (more) free thought I think the current generation of Asian programmers is - on average - not as apt as most western programmers. That has however nothing to do with cleverness, and it will certainly change in the future. It certainly better that they start with Java than with C++, which would certainly make everything a downright mess. The GP is under the illusion that having a harder language makes people stop programming. Instead they'll just make crappier programs.

Re:JavaFX

[owlstead]

That'll be the upcoming Android X then...

Re:Shitty programmers writing shitty code.

[greencpu]

hard to believe a guy with this elitist attitude uses a mac.

3 Subjects That Make People Irrational

[aplusjimages]

Politics
Religion
Mac Products

Re:3 Subjects That Make People Irrational

[ioliver]

You forgot sport!

When will we learn...

[BearRanger]

That a phone that caters to developers is NOT a phone that the rest of the world has much interest in using. I love the flexibility promised by Android, but if smartphones are going to take over the world I would not want my grandmother to have to deal with fragmentation and software complexity. Android phones and the iPhone occupy two different market niches. This is a good thing for both developers and consumers.

Re:When will we learn...

[Zapotek]

Erm....not realy man. The fact that is developer friendly doesn't make it user "un-friendly".
Granted I bought the G1 dev edition for that reason (and for the hardware QWERTY kb), I have friends who really enjoy it, even without any programming knowledge.
Honestly, I haven't written any significant amount of code for it but I really like the fact that If I needed to I could very easily do so with minimal restrictions.
Hell I can even write C binaries for it, albeit with a little bit more effort.

Re:When will we learn...

[pydev]

but if smartphones are going to take over the world I would not want my grandmother to have to deal with fragmentation and software complexity.

You're suggesting that the iPhone is less complex? Don't make me laugh.

Re:When will we learn...

[genik76]

If there are no developers, there are no programs. And if there are no programs, there are no users.

Re:When will we learn...

[aCC]

That's so true! I LOVE my N900 (even more open than Android), mainly because of the endless possibilities of what I can do with it. Freedom to do anything with your phone/computer rocks.

But in the current state of its software I would NEVER recommend it to my wife or family. They are so much better served by an iphone at the moment because it just works. Maybe once all the developers have fixed the missing features of the N900 it starts to get interesting for non-developers (probably in the 3rd generation N900 like with the iphone). To me the current software of N900 feels like KDE 4.0 felt. Ready for developers but really lacking for users.

The N900 is like a DIY set of a Ferrari. Not much use if you don't spend a lot of time putting it all together and fixing what needs fixed.

NOT a full comparison.

[MrCrassic]

I don't know enough about Android to really comment on other aspects of usability, but this article mainly compares development between both platforms. To be frank, though, I don't think the Android Alliance had to do a lot to be better than a system that only allows developers to code on OS X with a language that's almost entirely bound to that platform and under the control of an authoritarian and seemingly draconian submission control system.

However, under the Android platform gains critical mass (which the Droid and the Nexus One, to a lesser extent, are trying to do), the best bet to gaining lots of visibility and/or profit is by developing for the iPhone.
The article is pretty comprehensive; I recommend it. (Probably means nothing here on /. though. :p)

Syntax

[mosb1000]

No kidding, who cares about syntax? That's maybe 1% of programming, the rest is creativity and knowing the libraries. If the libraries don't transfer, you have kept almost nothing.

Said this Months Ago And Got Flamed

[curmudgeon99]

How curious. Right here on Slashdot I said this exact thing--months ago--and I got flamed without mercy. My reasons? The unpredictable nature of the iPhone app acceptance and then Java.

Re:Shitty programmers writing shitty code.

[MrCrassic]

Mod parent up. This is not troll material; in fact, it has a really good point.

Re:C? For programming C you should need a license!

[H0p313ss]

Java also has the distinction of being the language used for the only program I have ever seen with a CPU leak: Start it and watch the CPU usage slowly climb over the next few hours (while not actually doing anything, or taking any use input), until it's at 100% about 3 hours later.

I call bullshit on that one, I leave Eclipse running for days on end and never see that. I'm not saying it's impossible, I'm saying that this is not a Java issue it must be the application you're using.

Re:Shitty programmers writing shitty code.

[MrCrassic]

And 150% of statistics are made up on the spot.

Pandora for the iPhone is so well-written, it's practically a secondary music application for many folks. Many of the popular games on there work pretty well (and are lots of fun too!) and several of the applications I've downloaded have been pretty high-quality (read: few crashes, all of which are related to Safari hogging up memory and the memory being way too limited in the first place). I would be skeptical of thinking iPhone apps are pretty crappy when many, many people have at least four pages worth of apps on their phones.

Was going to say the same thing, foundation there

[SuperKendall]

As you noted, the foundation libraries are pretty much all there - it would be an adjustment going from other GUI frameworks, although you're going to have to re-think what you do anyway for a mobile device with a mostly touch interface!

author's programming chops

[Sebastopol]

But if I turned it back to portrait, it mysteriously worked because the bounding rectangle for the screen was now taller, not wider. That took more than a few minutes to find.

He's an app developer for mobile, but doesn't have the forethought to code for variable display sizes? rtard.

Nirvana Quest

[strangeattraction]

What the F@#ck I just just quit using Java to use Go. Can't Google make up it's mind. Ok, it is all quite clear now. It isn't the language that makes a product it is what you make with the language that is the product. That explains the popularity of the totally impure ObjectiveC. Infidels! calm restoring. Naval gaze.

Re:C? For programming C you should need a license!

[binarylarry]

Java's generational garbage collector doesn't leak memory unless you trap references like you mention in your first paragraph. Even then, it's not leaking memory in a traditional sense, you've just prevented the GC from being able to access and free the memory without crashing the application.

Ha.

[mbessey]

> This has thankfully prevented it from becoming the language of choice in major outsourcing and offshoring destinations
> like India, Pakistan and Vietnam

A quick perusal of iPhone-related questions on Apple's discussion boards, or on stackoverflow.com, would quickly cure you of this belief. A lot of people at the "bang the rocks together" level of expertise are trying to develop iPhone apps. People (and companies) go where the opportunity is.

I've been approached by one India-based organization to act as a "Public face" for them here in the states, so I know there are shops full of inexperienced iPhone developers in India who are pitching US companies on developing their "mobile strategy" for them.
 

Re:C? For programming C you should need a license!

[Al Dimond]

This is generally a good point. Many common programming errors aren't handled any better in managed environments than native ones.

Interestingly enough, I've worked on a C++ app with a "CPU leak" bug. Some versions of wxWidgets on Linux (such as 2.8.10, which is the current stable release and packaged by many distros) have a bug where certain apps will eat CPU this way if left open but unfocused and idle. Audacity is one such app -- I'm an Audacity developer and none of us could figure out a way to work around the problem.

Hilarious

[SuperKendall]

All one can really infer from that is Apple is in bed with big game studios.

Right, that's why the Mac is such a hotbed of game development!!!

Does it mean nothing to you that with a VERY cold start in relation to the game industry, that Apple has in fact drawn in many large game companies within just a few years? It's pretty obvious Apple is not in bed with anyone, the game developers were the ones who came to Apple when they saw users actually bought games on the device in droves.

As always the only thing getting game companies excited is money, not time between the sheets with one tech company or the other.

Re:C? For programming C you should need a license!

[binarylarry]

You must be a terrible programmer (like the parent).

You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected.

Serious difference.

Re:Was going to say the same thing, foundation the

[LWATCDR]

most but not all. Still the very idea that you can just take all your java apps and run it on Android is just wrong

Re:C? For programming C you should need a license!

[Lunix Nutcase]

In C, memory management is hard, but that means that people think about it.

So then how do you explain the countless C programs that have had and might still have memory leaks? Oh and all the buffer overflow errors. Or null pointer dereferencing. Most people tend to think that anyone writing C is actually thinking hard about these things, but in my professional experience and through the years of using many applications written in C, either open source or proprietary, I'd really beg to differ.

Use Intellij IDEA

[SoftwareArtist]

Agreed about the Eclipse UI. If you're going to do Android development, use Intellij IDEA, which has quite good Android support and is a vastly superior IDE.

Re:Use Intellij IDEA

[mswhippingboy]

Intellij IDEA is ok, but only on par with NetBeans or Eclipse, certainly not superior. However, I prefer Eclipse for several reasons

• It's 100% free (not just a scaled down "community" edition).

• There are plugins for everything you can image (most are free as well).

• I have to develop in multiple languages (Java, C++, Perl, Python, PHP, Groovy, even COBOL!) as well as several Web technologies (Ajax, .jsp, javafaces, etc). All (and many more) are nicely supported in the same IDE.

• Eclipse is always under heavy development and is improving at a phenomenal pace. This used to be a PITA due to things getting broken, but each new release now is more stable and feature rich than ever.

• It provides a powerful foundation for writing RCP applications to create custom standalone tools.

• Evidence that it will be around for a while can be found in all the support from the development industry. Almost all development toolmakers of any size play well with Eclipse it they support any third-party IDEs at all.

Like religion and politics, IDEs are very much a personal preference and I've tried (and continue to try) just about all of them, but I haven't found any that are superior to Eclipse for day-in/day-out development productivity. Apple can keep their XCode and Objective-C. I've been force to use it for development as well and I gotta say, it's like going back 10 years. XCode is the most confining environment I've worked with in a long time. Objective-C is only still around for one reason - because Apple practically forces it down developers' throats. It should have died along with NextStep (it seems to be the worst of C++ and SmallTalk combined). Sure, you can use other languages and IDEs on OS X, but Apple makes it clear that XCode/Objective-C is the preferred development environment and it's the ONLY environment if you want to develop for the iPhone.

Flamebait

[morty_vikka]

Aren't a lot of developers making a lot of money as a direct result of the tight controls apple has placed on iphone apps?

Isn't that a good thing for indy developers and small companies?

Shouldn't devs be applauding apple's approach instead of trashing it at every opportunity?

Re:Flamebait

[mswhippingboy]

Developers making $$ on iPhone apps are few and far between. The odds are pretty slim that you can recoup your investment.

http://www.fiercemobileit.com/story/most-iphone-developers-dont-make-money/2009-06-17-0

Re:Flamebait

[babyrat]

great survey they did... talking to 100 game developers, half of whom had never developed a game before. And to top things off, their percentages add up to 90%...sounds like a real trustworthy analysis.

Re:Flamebait

[mswhippingboy]

That's just one of many, many articles on the subject. Educate yourself a little on the subject and I'm sure you'll come to the same conclusion.

Re:Flamebait

[centuren]

Developers making $$ on iPhone apps are few and far between. The odds are pretty slim that you can recoup your investment.

http://www.fiercemobileit.com/story/most-iphone-developers-dont-make-money/2009-06-17-0

That's our choice as developers. If we make a bad investment in choosing to develop iPhone apps, so be it. It's not like there aren't plenty of other ways we can apply the same set of skills.

Re:Flamebait

[Dog-Cow]

I have 2 apps (and one is just a better, newer version of the other). The apps are very niche and only appeal to a small percentage of the total world population, never mind the iPhone/iPod Touch owning population.

And yet, I've made more than I spent on development. It's not a living, by any stretch of the imagination, but I most definitely have recouped my development costs.

It's like comparing bad to worse.

[zullnero]

Seriously, neither Android nor iPhone are all that great for serious development. They're both underwhelming platforms for real mobile development. Android has a leg up in many aspects as it embraces more open methods of development and more open standards, but when the dust clears, both platforms have been pushed to the forefront as a result of marketing hype.

There are better options out there, but most of us mobile developers who know there are better options have been herded along with the flock of sheep simply because we have to develop apps that the biggest flock of sheep will use or end up wasting our time and effort. Compared to more comprehensive and seriously powerful applications we used to write for older mobile OS's, the bulk of them these days are basically crapware.

Re:It's like comparing bad to worse.

[BitZtream]

There are better options out there,

Lets start with a Citation needed and follow up with 'Define better'.

As a professional developer, I define better as better by the one that produces the highest net profit for me. Net, not gross. After taking all income and costs into account, including my frustration level or joy in doing it.

No matter how you look at it, the iPhone and its app store is the clear winner to just about anyone on the planet that wants to make money rather than campaign for their favorite OS.

I guess you and I have different definitions of better.

Yours seems to revolve around being an emo/goth and struggling so hard to 'be different' that you end up being like every other angsty teenager out there and by doing so make yourself in fact just a tool of the very thing that bothers you. You try so hard to be different that you end up following all the other 'different' developers.

Meanwhile, the rest of us well balanced individuals are laughing at you all the way to the bank.

For a sheep, i seem to have a lot of spare time to do what I want and plenty of money to do whatever I personally feel like doing, while you seem to spend your time telling us how you're different. I've heard it before, you aren't different, you're just like every other tool who thinks he's different. I got news for you, Mommy lied, you really aren't special.

Compared to more comprehensive and seriously powerful applications we used to write for older mobile OS's

And once again ... Citation needed, but lets just skip straight to the point. You are a liar. 'We used to write more on less' ... yea, really, then why did you not write the same thing on these current phones? Because you didn't write better on less, you just thought you were bad ass for the crap you turned out before hand.

God, what are you, a developer at RIM or something, thats the only place I've seen mobile developers make such retarded statements in a long time. They too seem to think their shitty phones are actually 'good' rather than 'sucking marginally less than the other crap on the market at the time'. I'm wondering when someone is going to clue them in.

And geeks are such great predictors of success...

[sootman]

"... a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket... Any Java developer familiar with Eclipse should be able to use Google's Android documentation to turn out a very basic application in just a few hours."

It also has wireless, and more space than a Nomad. The iPhone's defeat is imminent!

Re:Shitty programmers writing shitty code.

[aliquis]

Just because they are free doesn't mean they aren't patent infringing!

Why a free phone to someone who has one already?

[JSBiff]

That program doesn't seem to make a whole lot of sense to me. According to the article you linked to, you have to have *alread* created an app, put it on the market, gotten a good rating, and a lot of downloads. Stands to reason that if you have already developed a popular android market app, you must already have an android phone to test your app on? Why would you give a free phone to someone who already has one? What business benefit does that provide?

That sounds kind of like offering a free knife or pot to a professional chef, or maybe a free drill or reciprocating saw to a professional carpenter. They would already have their tools.

Giving free phones to developers who are not *yet* developing for the Android platform might make sense - say, giving them to interested iPhone developers to try to get them to port their apps to Android. Or perhaps to college students or other new programmers who code up some sort of app using the SDK emulator, but don't have a phone to test it on yet.

Re:Wow.

[peterwayner]

You can convert .class files with a tool called dx and you don't need to do it by hand.

But let me explain what I was thinking when I said "It won't look pretty". That could mean a text line output or some other Android interface. I think I should have been more specific and spelled out just how much work it will be if you're trying to duplicate some of the code that isn't available.

Re: Do I know you?

[140Mandak262Jamuna]

Since I am the only Indian who could really write code, you could be talking about me. But I don't seem to place you. Do you know me?

Re:Shitty programmers writing shitty code.

[aztracker1]

I don't think you understand how modern versions of the JVM or even .Net's CLR work. Most code can run damned near as fast as C/C++ counterparts. The benefits are less complicated memory management (to the developer), and a codebase that's more portable to different systems.

Code get's compiled as needed, then run.. once you've run through a segment of code, it's compiled, and runs as compiled code; said code is now compiled, so repeats run through the same compiled code again; just like code compiled in C/C++... Now, some of the underlying constructs have a slightly higher overhead than with an unmanaged language.. just the same, it's far from an "order of magnitude slower" ... take a look at some of the IronJS (dynamic language running under a managed engine) vs V8 (dynamic language under a C/C++ engine).

"How difficult is it to understand this concept?"

Indeed.

Re:Shitty programmers writing shitty code.

[ardor]

Unfortunately, Java is a backwards language with zero interesting features whatsoever. The C++ you seemingly abolish allows degrees of polymorphism and modularity Java will never, ever reach. No, I am not talking about low-level C hacking. Look up generic programming in C++, for starters. Or the functional stuff you can do in C#. Or anything you can do in Haskell, which might be an academic language, but is the ultimate eye opener regarding the essential features Java lacks, such as a proper lambda, closures, first class functions, "real" generics. (Anonymous classes are only a very rough approximation to the first two.)

Yes, I have worked with Java for real. If possible, I use C++ or C# instead. Or Python, Ruby, Lua, ... almost any other language out there is more powerful than Java these days. Note that I am deliberately not including the virtual machine or the standard library in this - I am talking about the language only.

Re:LOL. Living in the past, are we?

[mini me]

much more difficult language to learn and master than Java

What is so difficult about it? Objective-C is very similar to Ruby. Ruby was promoted as the easier alternative to Java in the early Rails days. So how can someone pick of Ruby without much effort, but strugle to learn Objective-C, when they are pretty much identical languages? Even the major frameworks, Cocoa and Rails, share a lot of similar design patterns.

Re:Please point me to the baseband source code...

[Microlith]

Looks like they are about equally "open" to me...

By that hyperbole, the OpenMoko Freerunner was also closed and thus no better than an iPhone.

Extremism will get you nowhere except ignored. You know there's a huge difference between "closed because the vendor wants it closed" and "closed because the vendors hands are legally tied."

I suggest pursuing the option you have, and getting the laws changed.

Re:C? For programming C you should need a license!

[grouchomarxist]

Eclipse appears to have significant memory leaks. After using it for a while it starts consuming a significant portion of my system memory and slows things down substantially. I need to restart it to get it running at a decent speed again.

That's why Unix was written in Java

[gig]

If you're a Java developer, of course Android's Java is great for you. But saying that is better than the C on the iPhone is ridiculous. The proof is in the pudding: the iPhone's apps are much deeper and sophisticated because in many cases they are 90% desktop code, dropped in and create an interface.

It is not the developers' perspective that matters

[QuietLagoon]

It is the customers' perspective that matters. Far too often developers think the world revolves around themselves. It doesn't.

Security

[beaverbrother]

Is anyone else worried about viruses on Android? While I'm sure apple doesn't go too far to vet security, Google doesn't really examine Android apps much at all. I wouldn't be surprised if trojans, etc get distributed through the Android marketplace in the near future

Re:Security

[Belial6]

I would be more worried about viruses on The iPhone. It is trivial to hide a trojan in a program. Nothing Apple does will even slow that down. So, given that the marketplace host is doing nothing to stop or even slow down viruses, how do the two compare? Well, with the iPhone, every application is basically Admin. If you can run any code, you can run it all. Android on the other hand, only lets you have access to features that you publicly request. Certainly, this won't stop some people from installing a wallpaper downloading app that requests access to their contact list, but at least there is a mechanism for the interested users to know if there is code in the app that wants to access to all of their friends phone numbers.

Re:Shitty programmers writing shitty code.

[ceoyoyo]

PyObjC has a one liner description of how to convert an Objective-C call into a Python call and vice versa. It's not difficult.

Re:Why a free phone to someone who has one already

[joshki]

The point is to get hobby devs (like me) who are stuck on older hardware up to developing for 2.0 and 2.1.

Android can byte my shiny metal

[Anonymous Coward]

I develop a fairly major app for iPhone, BlackBerry and Android.

As a developer that likes to tinker, the lack of root access to the iPhone offends me. It is like selling a fast car with a governor that limits you to 55 mph. The draconian signing certificates and provisioning profiles can be very frustrating. And the simulator SDK (not the simulator itself) is incompatible with iPhone development, which is ridiculous. That is to say, there are headers and libraries supported on the simulator but not the hardware, like someone might choose the simulator as a final release platform.

But that is about it. I have a few significant complaints about developing for the iPhone. None crop up on a daily basis. There are many enjoyable aspects about the iPhone. The hardware is consistent and reliable. The IDE is consistent and reliable. The device is responsive and predictable.

Compare that to Android and Blackberry, where dealing with the IDE, simulator and hardware are a daily ordeal. Java is slow. Eclipse is buggy. In the car metaphor, these things top out at 55 full throttle. And the idea that you have full access to a system from Java is kind of a joke. Android has done away with the application metaphor in favor of the Activity. The openness of Android seems really cool and will probably end up like the security nightmare that is IE6.

And can I just say that the Android naming conventions are painfully stupid. Everything has a catchy thesaurus name that bears little relation to the actual functionality. They may have cured my of my own anal naming conventions. Activity, Intent, Parcel, Arghh. Apple names are wordy, ugly, straight forward and very informative.

The documentation for all 3 is fairly weak. Apple dictates who can say what about everything, but even with that it is often easier to find helpful search results on iPhone related problems. I would say that Android wins for documentation overall.

Overall, developing on the iPhone is nowhere near as painful as Android or BlackBerry. The initial role out is worse on iPhone, but the daily grind is not nearly as bad. I kind of lumped Android and Blackberry together there, but Blackberry is really much worse than Android.

And the article mentions using existing Java code on Android. We ported from BlackBerry to Android and maybe 1% of the actual code made it across untouched. You would think, moving from one Java smartphone to another Java smartphone, that anything at all might share some commonality. But no. Even the core classes for arrays and maps are different. Only the strings survived.

webOS is, perhaps, even better

[El Royo]

Developing for webOS is perhaps even better for developers. Personally, I hate Java. I think I'd rather go through the pain of learning Objective C. I wasn't a big fan of JavaScript, either, until I started working with it for webOS apps. Now, with the PDK (plugin development kit) coming out, developers can write in C/C++ and access SDL for applications that need that extra oompf. The underlying Linux OS is readily accessible, moreso than it is on Android, I've been given to understand. There's a tremendous homebrew community out there creating patches, themes and more. Check out http://webos-internals.org/ if interested in seeing that side. And, with Palm-blessed sideloading of apps, developers can make their own way.

Re:Infoworld Has Too Many Crackheads Working There

[scotch]

I wish I hadn't commented in this discussion so I could mod you up. Also, I wish I had mod points.

Denta Smile Md

[jaffredi]

I had the same problem with my iphone pearl and was told it was because of memory shortage. Like when you go on the internet alot or something, Denta Smile Md

Re:C? For programming C you should need a license!

[bar-agent]

You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected. Serious difference.

Not really. You don't have to actively do something stupid, you just have to not do something smart. Or use a library where someone didn't do something smart.

Anything that has back references can easily become uncollectible, and consequently so can anything that simply refers to other data embedded in a larger structure rather than making a completely independent (and time- and memory-consuming) copy of that data. And a library can have a dozen of those under the hood, where you'd never know about it.

Re:C? For programming C you should need a license!

[bar-agent]

You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected. Serious difference.

Anything that has back references can easily become uncollectible

More correctly, it isn't that it becomes uncollectible, it is that you are wasting so much memory keeping so much more that you think you are.

Like, you may think you are only keeping an attribute and its value from an XML node, but what you are actually keeping is the entire node, in fact the entire XML tree, plus the complete text file it came from (buffered), plus a line number map, plus the string forms of each element, plus a cross-reference table just in case, plus a similar amount of information from every XML stylesheet or DTD associated with the document, plus their included DTDs, etc.

The public prefers a huge app store to DRM rants

[judeancodersfront]

and would only be interested in jailbreaking if it was a movie that starred Matt Damon. Developers like the app store, users like the app store, and what you don't like really doesn't matter to either group.

Game studios have complained about Apple in the

[judeancodersfront]

past. The iphone is actually a change from that. It's a platform of millions of people that have no problem tossing a few bucks at a game which shouldn't be a surprise given how much the iphone data plan is. But yea it must be bribes. That's the logical answer.

Re:LOL. Living in the past, are we?

[tyrione]

much more difficult language to learn and master than Java

What is so difficult about it? Objective-C is very similar to Ruby. Ruby was promoted as the easier alternative to Java in the early Rails days. So how can someone pick of Ruby without much effort, but strugle to learn Objective-C, when they are pretty much identical languages? Even the major frameworks, Cocoa and Rails, share a lot of similar design patterns.

Try the other way around. Ruby is very similar to Objective-C.

Re:C? For programming C you should need a license!

[RAMMS EIN]

I think it's not so much that C programmers aren't thinking hard about memory management, array bounds, etc. I think they _do_ think hard about them, but still get them wrong. And that's really the worst possible outcome: you lose productivity because programmers are forced to think about low-level details, and still get insecure and unstable software. C is a fine programming language, but I really don't get why people insist on writing their applications in it.

!Java

[Skythe]

While Android is written in Java, the recommended way to program the GUI is using XML. That can be quite the stretch for someone that's never written a layout in XML (read: myself).

Re:!Java

[JAlexoi]

As in Drag-And-Drop WYSIWYG editor that comes with Eclipse plugin is hard for you?

Re:Shitty programmers writing shitty code.

[kaffiene]

What a load of utter crap. Thats the least logical thing I've seen on slashdot in years, and that's saying a lot

Re:Shitty programmers writing shitty code.

[swilver]

I used to program in C/C++. The reason I think Java is a better language is BECAUSE it has less features.

In C, when you show me an excerpt of code, it tells me very little. I donot know the data types involved without finding the appropriate include files (they may have been redefined, typedef'd, etc). Half of the code I see may actually be macros even though they look like function calls, and half of the code you see (especially in include files) is not even relevant at all because it is not even compiled thanks to generous use of #if blocks (and they don't even bother highlighting the blocks with some proper indentation either).

Because C is so flexible, looking at a single source file tells me very little -- I have to make many assumptions. Too much things can be changed or configured, even at a compiler level. In contrast, when you look at a Java source file, you got almost everything you need to understand that piece of code. There's no macro's, redefinitions of common data types or code that is optionally included. An int is a signed 32-bit integer, on any platform. Even that little detail helps to avoid common pitfalls when mixing signed and unsigned arithmetic (everything is signed, deal with it).

Also, each Java file compiles to a single result. It is pretty much standalone useable. Java does not allow you to split things into multiple files willy-nilly, it actually enforces a common structure to all Java projects at a basic level. In C, every project does it in a new way, there's no standard. There's no naming convention. There's basically very little convention at all, at any level.

That is not to say Java is perfect, but less is more does seem to apply here. It gives the programmer less choices, which in turn makes code easier to understand and maintain. It's also strict, which makes later changes and refactorings much more controllable. Unlike a language like Python, where any project that spans more than a few pages can have subtle bugs just because you mispelled a variable.

Re:Shitty programmers writing shitty code.

[ardor]

This is an illusion. The inevitable consequence of a language with very little features is a considerably increase in code complexity, precisely because the language is ill-equipped to express more complex problems.

Case in point: sorting algorithms, containers, callbacks.

• The first one requires you to inherit from Comparable, which is a bone-headed move, because all that is _actually_ needed is just a valid comparison operation a < b (most other languages do it right).
• The second one uses the hack called "homegenous generics" - in fact just a hidden set of casts from/to Object (or from/to the bound type in case of bound generics). Type erasure occurs, something like template < typename T > void foo(T t) { t.bar(); } becomes impossible (unless with bound generics, which are severely limited as well).
• The third one is only really possible by using anonymous classes, which is again over-verbose and misses the point. Again, C# did it better by implementing delegates and allowing for first class functions, as all the other languages do.

Please note that your comparison with C is a bad one. Do not compare Java with C. Compare Java with C++ (proper, modern C++, not "C with classes"), C#, Haskell, Ruby, Python etc.

Re:Shitty programmers writing shitty code.

[dzfoo]

If you make fart noises by hand, you're doing it wrong.

    -dZ.

Re:Shitty programmers writing shitty code.

[dzfoo]

And in E-macs you can do it with a single (shifted) key stroke.

        -dZ.

Troll?

[Jesus_666]

Of course I didn't read much of TFA. Then again, an article with comments like "While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket" can't be very objective. Yeah, you don't like the iPhone. We get it. Now can we please get a developer who isn't obviously biased to compare the two platforms? Or at least one who can hide his bias for more than three paragraphs?

It's all about the killer apps

[Fastfwd]

Making it easy for developers is not the key. Attracting the developers on key strategic apps is it. The number of apps in your store does not matter if you don't have the 5-10 apps that the user wants/needs.

I think that both Apple and Android have an app store that covers the needs of most users but the Apple store is still the most attractive right now. I have not browsed both extensively so at this point it's just the word to mouth about what I can or cannot do with the phone that would sell me on the iPhone.

Re:Shitty programmers writing shitty code.

[mcvos]

Unfortunately, Java is a backwards language with zero interesting features whatsoever.

Other than the JVM, that is. Java sucks, but the JVM is the coolest thing ever, and it supports Scala, Groovy, JRuby, Jython, etc.

Java was great when all we knew was C++, but nowadays we have much better choices available. And we get to keep the one good thing that Java ever gave us.

Not *that* many either

[DrYak]

an embedded device of different architecture CPU with an app that often interacts with the CPU

You're a little bit exaggerating :
- Up until now (apart for a few oddities like running Android on an OpenMoko thanks to Koolu), there are only 2 major CPUs running Android :
Ti's OMAP3 and Qualcomm's SnapDragon.
It's not that there dozen of radically different platform architecture (Unlike say Debian or Gentoo Linux distributions)

- TFA's point is about how development on Android is easy because enterprises can leverage their Java and Eclipse prior knowledge to target Android's Dalvik virtual machine. To rapidly prototype nice and simple application. In those circumstance yon don't even interact with the CPU directly. You produce byte code which will be then processed by android's bytecode interpreter (1.x) or JIT machine (2.x)
You'll really need to test your application on every Android phone under the sun if, and only if, you want to do complex assembly optimised routine (like a video SIMD&DSP-accelerated CODEC).
And generic App developpers should really consider sourcing some already made and ready solution, like a nice port of an open-source library which has been thoroughly tested.

In embedded programming, "it runs without faults on emulator" is getting about as far as "it passes validator.w3.org" in web programming: the fun with nasty bugs and hidden problems just began.

Yes, and ? In web programming, you can try to keep your design simple enough and generic, have it passes the validator, and you know it'll look more or less the same on lots of standard-compliant browser.
For several small scale project that's a strategy I've followed : make standard compliant, don't rely too much on clever hack, test it on Firefox and some KHTML/Webkit powered browser. It'll be *good enough* for lots of situations. Testing has showed that this strategy covers other standard compliant browsers like Opera - without needing to constantly test on it. And just fuck Internet Explorer. Yes, just fuck it. From the beginning, part of the specifications of the project are that it's not guaranteed to work on IE, specially older ones (well I'm in a field where this is actually possible). Problem solved.

Same goes for Android Apps : test them throughly in an emulator and perhaps 2 or 3 major devices. Chances are high that it will perform well enough on a few other, as long as they have default Androids installations following the official behaviour. For devices known to diverge widely in their behaviour, maybe state outright they are not supported (just publicly announce that OpenMoko are not officially supported)

You know what ? This has pretty much worked well for PalmOS devices. Developers tested them thoroughly on 1-2 devices, maybe fixed their creations based on feedbacks done by users on another 2 devices. And it worked for most people.
And that's although PalmOS PDA came with a crazy range of screen resolutions and colour modes, a large selection of OSes, from lots of different constructors, madr a major platforms change (the whole 4.x + Motoral to 5.x + ARM). Make sure your product doesn't rely on crazy hacks, follows standards and best coding practice as recommended by constructor, test thoroughly in an emulator and a subset of device, and you'll probably be OK for other too.
I personally use a piece of software (ePocrates - a medical database) on a PalmOS PDA which I'm pretty much sure was never tested by the developpers (Zodiac - a rare PalmOS power gaming console / PDA hybrid). But it just works. Because ePocrates doesn't rely on any complex hacks, and was tested against enough common devices.

I don't see why Android should be any different from that, specially as the OS is free (much more easy to setup emulators with every different version of it), uses a nice environment for execution abstracting lots of stuff (you don't need to get bare metal for simple apps, just use Java), and is open-source friendly (lots of ports of useful components and libraries - no need to reimplement complex CPU-sensitive stuff)

Re:C? For programming C you should need a license!

[mcvos]

And Eclipse is pretty bad as Java applications go. It's known to eat tons of memory and CPU for doing very little. But I don't think that's a Java issue. There are some very bad design decisions at the root of Eclipse.

Re:Shitty programmers writing shitty code.

[rmadhuram]

How do you know? Any statistics to back this up? Chances are good that some of the apps on your iPhone *were* developed in one of the countries you mentioned.

Re:C? For programming C you should need a license!

[bad_sheep]

True, but the big difference is that in Java, you have wonderful portable tools such as VisualVM, greatly easing to find memory leaks.

Finding a memory leak under a C++ application can take days. In my previous job, we wrote an Java application of 700k+ lines and a C++ realtime portable core of 50k lines. We found memory issues in both, but fixing it in the core took 10 times the time to fix it in the Java one.

Why ? The tools are better and the differences with the OS are hidden by the JVM, so far less work on that side.

Screen Resolution Issue Debunked for the /. Posers

[salesgeek]

What a bunch of dip-shiat posers. First, Android apps are run on a virtual machine (yes, that's right, even on the phone). If you've actually cut code for Android, you would probably be familiar with the build/test cycle which consists of compiling and running on an Android Virual Device (AVD - an emulator that lets you simulate different phone configs) which comes with the SDK. The emulator supports multiple resolutions as well as multiple versions of the Android OS. Screen resolutions are really not that much of a challenge. Funky hardware (say, a totally bizarre, non-standard GPS chip) might be, but I have yet to run into a situation where the Android SDK doesn't provide an abstraction that just takes care of it for app development.

Here's a link to the Android developer documentation on the multiple screen resolutions. It just isn't that tough, and anyone who says multiple screen resolutions are either has never cut code for Android or simply is incapable of reading the manual.

Note to Mr. Buy A Lot of Hardware: Your code does not know the difference between being inside an AVD or running on a real phone. I think someone at your company has a fetish for gadgets and is tickling it at your expense.

Note to /. at large:RTFM before opening mouth, RTFM and you'll be amazed what you learn. For the n00bs: RTFM = Read The Fscking Manual. More for the n00bs: typing $man fsck is not what RTFM wants you to do.

Ironically Android has been designed to provide developers a way to write one application that can be supported by many devices. It's also open source, and the SDK (and built in emulator) is freely available. This means if you want to be an expert on Android, you can download the SDK, and EVEN WITHOUT OWNING AN ANDROID PHONE write your very own applications... or try to or whatever. Just stop acting like you know what you are doing or you are some mobile software development expert when you don't even know what some guy who just installed the SDK knows about 15 minutes into trying out the SDK. Sheesh. // Feel Better Now
/ /. continues to be /.