Slashdot Mirror
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.'"
It's not DRM-laden patent trolling Apple.
"The difference between genius and stupidity is that genius has it's limits" - Albert Einstein
Unfortunately right now it appears that for users it's the other way around.
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!"
Nothing for 6-digit uids?
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
liqbase
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.
"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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Ugly multitasking on an Android is not better than slick single-app execution on an iPhone. It's only a different experience.
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!"
Better known as 318230.
... 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.
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
Who need's speling and grammar?
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.
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.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Politics
Religion
Mac Products
Can I bum a sig?
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.
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?
... and then they built the supercollider.
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.
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.
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.
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.
"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.