Why Android Will Soon Kick Ass
gizmodo.com
gizmodo.com
Not sure about this... I think in large part the problem with Windows Mobile phones is the driver quality/integration -- a problem that you can't separate from the hardware too far.
No one else makes a legitimate phone OS with all this support that can be tweaked down to the very roots. For one thing, I'm excited to be able to download an entirely different version of all of Android’s core applications if I don't like the default 1.0 versions—and that’s every app, everything from the dialer to the contacts manager—something that's technically possible in WinMo but often comes off more as an awkward re-skinning and not a top-down integration.
I know the good folks at Google have given this a lot of hard thought, but the fit and finish of those applications is critical to the reliability of the phone as a phone. Software that hook into those interfaces poorly or without good reason risks a lot of reliability for dubious gain. Anyone who used Mac OS pre-X or PalmOS with a lot of extensions knows exactly what I'm talking about.
That said, I'm more and more pumped about it as time goes on. The openness can't hurt, even if Apple isn't on board (and likely won't be for years if ever).
Yup - The problem with a phone is that yes, the software is important - but people still see it as all hardware and expect it all to just work like hardware.
So people see it as a device, but it's increasingly a platform. Apple's model will certainly be more successful in treading this line - but remains to be seen if that's the determining factor or not.
These things look cool to us because we're the target market. No one else will care.
What Ballmer recognized was that if you have an environment that's friendly to developers, eventually you will have things regular users want. I'm surprised Apple doesn't seem to understand this.
Thanks to an accident of history (NeXT) combined with Apple killing backwards compatibility with OS9 down, they have a really developer-friendly API compared to Windows. On a purely technical level, Apple is far more developer-friendly than Windows.
They are doing their very best to shit that all away though, when it comes to the legal and backwards-compatibility side of things. That's one reason I doubt I'll ever spend my money on Apple.
1. the Win32 API is not the only thing to develop on Windows with. Personally, I find C# &.NET to be much more comfortable to program in than Objective-C & Cocoa.
2. There is no silver bullet. Some platforms are better at some things than others, but it's largely a matter of accidental complexity.
It's interesting to me that Apple seems to be letting useless apps proliferate in the App store, yet is denying some apps that could really have value. If that is indeed the case, they are keeping one of the worst (from a consumer POV) aspects of openness and throwing away one of the best.
Apple knows how to market technology to regular people. So far, android only seems to be aimed at the tech crowd.
Tell my why developers can only use Java applets then that can only access certain API functionality that Google (or the carrier) wants to limit them too? Why can't I program for Android using Python, or C, and why can't I connect to the phone from another machine over SSH to transfer files, or compile applications, or tunnel an X11 session? What was that you said about "no OS handcuffs" again?
> No one else makes a legitimate phone OS with all this support that can be tweaked down to the very roots. For one thing, I'm excited to be able to download an entirely different version of all of Android’s core applications if I don't like the default 1.0 versions—and that’s every app, everything from the dialer to the contacts manager
Openmoko has been making this possible (and infinitely more open) for far longer than Google was even planning Android...
OpenMoko is interesting, but realistically, Google has way more muscle and stands a better chance of spreading Android far and wide.
If I screw something up, or if I one day decide I want to run Debian Linux instead of Angstrom/Openmoko, I'm free to reflash my phone's bootloader, kernel, and rootfs, or specially format its Micro SD card and boot from that instead. With Android, you don't yet have any of that freedom, and if the American cellular companies have anything to say about, you never will.
However, I will grant you the fact that Google has a gigantically higher chance of changing the face of mobile communications with Android than Openmoko, but I'd still rather have my Neo any day.
Because those are pain in the ass languages for embedded devices. Do you really want to manage your own memory in C or deal with the slowness of Python on a mobile device??
There are some things C or C++ are just better at, like operating in a low-memory environment when you want to squeeze as much as possible out of the system. Sure, GC is nice and all, but for things to work well with a modern copying generational GC, you need 2 or 3 times the amount of RAM as an equivalent manually managed tool, because collection is lazy and you don't want to run it on every allocation -- that would be too expensive. So garbage sticks around for a little while.
Alternatively, some people like writing in high-level compiled languages (most of which are faster than Java) like OCaml or Haskell, both of which are suitable for a device that would also be running Java.
>There are some things C or C++ are just better at, like operating in a low-memory environment when you want to squeeze as much as possible out of the system.
No, that depends on the developer. A lot of developers don't want to worry about memory management and memory leaks.
The thing is that they need a VM-based language so they can port the VM over to all sorts of hardware instead of forcing developers to mess around with portability issues. Port of Squeak Smalltalk to the iPhone: http://isqueak.org/HomePage
That has nothing to do with what I said. If you want to avoid the peak memory overhead of using a GC (and the peak memory overhead is quite a bit higher if you don't want to kill performance -- you'd need to run the GC after every statement that could possibly kill garbage otherwise), you need to use C or C++.
And as for other mobile platforms -- Windows Mobile allows C++, IPhone is in Objective-C, Symbian is C++, etc. Java is popular, but it's not overwhelmingly so. And this is even taking into account that it's easier to get a Java based device approved by carriers/regulators because the VM can trap more attempts to break the OS and thus make sure that you can't trick the software into doing out-of-spec stuff.
GC is a wonderful tool. it prevents leaks, but it needs more memory when you're rapidly generating garbage. I wouldn't want to program without it... unless I'm trying to shoehorn things onto a tiny system.
Nevertheless, I can remember thinking "what kind of massive nerd, with way more money than sense, would have a unix server at his fucking HOUSE" back in 1995. I now have a platoon of linux machines in my house. And, openness does generally win in the end, even beating security, useability, and aesthetics.
I am going to hold on to my current phone until I can justify the cost of an OpenMoko.
Now, if you want to make a game tied into the next blockbuster movie and plan to sell a million copies next month and none afterwards, you probably should not invest in the OpenMoko. But if you are thinking in longer terms, I think it is the way to go.
Consider this proposition: you are talking to a courier delivery service (think FedEx or UPS but a smaller regional company). They want to replace the handheld package scanner / data entry thing their delivery drivers use, the current ones cost them $500 per device plus the integration and central servers. They want to invest in something that allows their drivers to fetch more information, such as traffic information and the dispatch messages they currently get by phone or radio, and have it integrated into the hand held computer.
You can't offer to save them a lot of money by writing an iphone app, iphone apps don't have access to the SMS messages among other things.
I'm not sure if you can do it in Android, I'm going to guess yes though. I looked through the SDK reference briefly, and the fact that you had to write in Java was not good, and I wasn't sure how to get access to the SMS functions or call log or stuff like that.
But I know you can do it on an OpenMoko, because you have access to everything. I don't need to learn an SDK, the same APIs I use to program on linux are there. And if the project is big enough to justify a special production run of an OpenMoko with some kind of proprietary RF added and a bar code scanner, the OpenMoko's hardware is open too.
Now, presume that I don't have the deal above in hand, but I am thinking there is a 10 percent chance I can get it in the next 2 years. If my cell phone breaks, am I going to buy an iPhone or an Android ? No, I'm going to make a long term investment and get an OpenMoko.
And, not to belittle Google, but the iPhone apps are NOT something to laugh at. Many of them are insanely good, and it's incredibly easy to get them.
What's more the SDK is also great, I tried to run the latest S60 SDK (Nokia) and after 2 weeks gave up, MS is great but its not for free. With Android it's free and straight forward.
It's too important for them to worry about the details of it?