Where Android Beats the iPhone 365
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.'"
meh (Score:4, Informative)
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
No it will not (Score:5, Informative)
"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:Shitty programmers writing shitty code. (Score:4, Informative)
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!
Re:Thanks for Playing (Score:5, Informative)
Re:Not as fast? (Score:3, Informative)
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:No it will not (Score:4, Informative)
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 (Score:2, Informative)
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 [android.com]. As you can see, a large fraction of the java.* and javax.* packages are there.
Re:That's peachy (Score:1, Informative)
Are you kidding me??? (Score:5, Informative)
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:Use "em" not "px" when defining the UI (Score:3, Informative)
Only Windows UI Programmers complain about screen sizes...
We don't - we've had WPF, with flexible layouts by default [microsoft.com], since 2006.
And those who are .NET-allergic and prefer C++ can always just use Qt.
Re:No it will not (Score:4, Informative)
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:Use "em" not "px" when defining the UI (Score:5, Informative)
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 [microsoft.com], 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 [microsoft.com].
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 (Score:5, Informative)
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.
Android can byte my shiny metal (Score:1, Informative)
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 (Score:3, Informative)
Re:Use "em" not "px" when defining the UI (Score:5, Informative)
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.