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.
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!
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.
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++.
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.
I wrote parts of this stuff
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.
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?
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.
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.
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.
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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.
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).
"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.