Slashdot Mirror

Apple's iPhone is a single, phone that's very well-designed and includes a slick interface. Oh yeah, and it has the Apple brand (and the corresponding price tag). Reports are that Apple's phone managed to successfully establish itself a niche in the mobile phone world, but that they failed to sell as many as they had hoped.

Google's Android platform, on the other hand, is more than just a single gPhone, as they like to say it's 'thousands of phones', made by dozens of companies, spanning the super high-end iPhone killers to the low-end cheap free-after-rebates you get with your carrier subscription. The operations that Google has set into motion - departing from the traditional JCP standards process, releasing a new non-Sun Java-like Virtual Machine - these moves have a huge potential to transform the entire mobile phone industry as a whole - and, though it's still early to say for sure, the transformation will more than likely be for the better.

So Apple's iPhone is a great, very well-designed product for a few people, but it is overall much less significant than the potential Android has to seriously shake up and inject innovation into the mobile industry. The two are honestly nothing alike, as much as the media would like them to be.

-Will

I would argue that it's Google versus closed-source phone manufacturers, their service allies, their software allies (i.e, Microsoft), and, most notably, Sun Microsystems and the Java Community Process.

Note the conspicuous absence of any Sun software (or support for it) in the SDK release.

See:
http://ohadev.com/blog/dalvik-vm-icicles-abound-no-sun-in-sight/

Some responses to your points:

(1) It's Java.

Java is the entrenched standard for mobile development. Google isn't pushing Java here, they're trying to maximize their reach to existing mobile developers.

(2) It's eclipse-centric.

As mentioned on their site, Google's developers use a mix of Eclipse, IntelliJ, and NetBeans for development, which is pretty much the standard in Java development. They've probably released an Eclipse plugin first because it had the broadest reach and perhaps it was the easiest environment to create a plugin for. I doubt this means that Google is pushing Eclipse, however, I would expect tutorials and documentation (if not additional plugins) to be released for the other environments soon enough.

(3) Code layout.

Code layout in package directories is pretty much a Java thing, again pretty standard.

(4) I have an iPhone.

iPhone is a single phone. Android will support a whole platform of upcoming phones. This is a big enough difference to be interested in the Android SDK at the very least, if not both. Plus, you can check out the Android SDK now while you'll have to wait until February for teh iPhone SDK.

(5) It appears to come with an emulator, which is very cool!

Yeah, it is very cool! This is also pretty standard for wireless toolkits (WTK), since development on the devices themselves is usually difficult and time-consuming. My company's suite of game development tools includes a similar universal emulator, which I love using. It's pretty much a must for mobile development.

I'm also looking very forward to playing around with the SDK. Hope some great things can come from these developments in the mobile world.

-Will

This is what excites me the most about Android: OpenGL ES compatible Graphics API.

Today, mobile phones in the US are completely "locked-in," not only with regards to content distribution, but also creation of applications. The process of creating a program that will run on a reasonable number of mobile phones is so needlessly complicated, that entire companies are built around technologies that translate between platforms in a semi-automated way (see JavaGrounds, for example).

Although Android won't break open mobile phones on the distribution side of things, it *will* make development a WHOLE lot easier for those of us who enjoy making games for fun, not for profit.

Comparisons between industries in other companies can often inform one of the problems or idiosyncrasies of a particular national industry, and it seems like mobile phone applications in the US are an example of that. See an interesting post on OHADev comparing the state of mobile phone gaming in the US and Japan, for example.

Will Android change the way mobile games and applications are distributed? Will it "open up" the seriously hierarchical mobile services infrastructure? Will it make the world a Much Better Place? Probably not. But, here's hoping that at least in some small way, it will twist open the nozzle, allowing community collaboration and indie developers to forge ahead into the mobile world.

Cheers,
greg

"a custom Java Bytecode interpreter that is highly specialized for the CPU" - Kind of hard to do that in an emulator on a PC. What CPU is this optimized for? (Guessing ARM... Still, to evaluate performance you need real hardware.)

The "custom Java Bytecode interpreter" probably means a Jazelle JVM or variant. These are specialized CPU/JVM combinations that execute Java bytecode in hardware. This technology is used on many of the Java phones already in the market.

The link goes to the "canonical" Google Code project page, but it appears that Google has set up a "special" page for the Android project. Note that if you try to use that format for a "normal" Google Code project, (such as my own PhyloWidget: correct, incorrect) you get an invalid URL error.

Furthermore, I was disappointed to see that the Android project's SVN browser page turns up blank. Come on, we want Source Code!

greg
OHADev

Some friends and I have started a discussion forum for independent developers at ohadev.com, please stop by and leave some comments if you're interested in getting in touch with some independent Android enthusiasts.

prize = 10**7

py fo life

--------
Brian Jordan
http://ohadev.com/ - Android SDK news, code snippets, and discussion

Real fast development.

http://code.google.com/android/intro/installing.html#installingplugin

-------
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples and tutorials

What would be needed would be a developer's model for these phones,
and the correct transfer hardware and developer's kit from a NON-OHA
phone.

Ironically, that makes this really hard, because the old-school (non-
Android) handsets make it very hard to independently develop with.

We have a forum thread discussing this possibility:
http://www.ohadev.com/forum/viewtopic.php?p=23

Cheers,
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples, tutorials,
application submission

What would be needed would be a developer's model for these phones,
and the correct transfer hardware and developer's kit from a NON-OHA
phone.

Ironically, that makes this really hard, because the old-school (non-
Android) handsets make it very hard to independently develop with.

We have a forum thread discussing this possibility:
http://www.ohadev.com/forum/viewtopic.php?p=23

Cheers,
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples, tutorials,
application submission

The most common question I've heard is "What hardware is the Android platform running on?" Nobody outside of Google and possibly the Open Handset Alliance members has run it on hardware yet. If you're interested in trying to hack it, there is a board of people trying to get it on some phones: http://www.ohadev.com/forum/viewtopic.php?t=15 ------------ Cheers, Brian Jordan http://ohadev.com/ - Android SDK code samples, tutorials, discussion

The most common question I've heard is "What hardware is the Android platform running on?" Nobody outside of Google and possibly the Open Handset Alliance members has run it on hardware yet. If you're interested in trying to hack it, there is a board of people trying to get it on some phones: http://www.ohadev.com/forum/viewtopic.php?t=15 ------------ Cheers, Brian Jordan http://ohadev.com/ - Android SDK code samples, tutorials, discussion