SDK Shoot Out, Android Vs. IPhone
snydeq writes "Fatal Exception's Neil McAllister delves into the Android and iPhone SDKs to help sort out which will be the best bet for developers now that technical details of the first Android smartphone have been announced. Whereas the iPhone requires an Intel-based Mac running OS X 10.5.4 or later, ADC membership, and familiarity with proprietary Mac OS X dev tools, the standard IDE for Android is Eclipse. And because most tasks can be performed with command-line tools, you can expert third parties to develop Android SDK plug-ins for other IDEs. Objective-C, used almost nowhere outside Apple, is required for iPhone UI development, while app-level Android programming is done in Java. 'By just about any measure, Google's Android is more open and developer-friendly than the iPhone,' McAllister writes, noting Apple's gag order restrictions on documentation, proprietary software requirements to view training videos, and right to reject your finished app from the sole distribution channel for iPhone. This openness is, of course, essential to Android's prospects. 'Based on raw market share alone, the iPhone seems likely to remain the smartphone developer's platform of choice — especially when ISVs can translate that market share into application sales,' McAllister writes. 'Sound familiar? In this race, Apple is taking a page from Microsoft's book, while Google looks suspiciously like Linux.'"
Android runs on Linux....
requires a intel mac?
dont tell that to my G5... it's happily working.
Do not look at laser with remaining good eye.
iPhone SDK requirements to develop an iPhone app:
OS X 10.5.3 or later (Intel or G5)
ADC membership (free but requires registration)
XCode (free bundled with OS X Tiger and above but not installed)
Objective-C language
To distribute iPhone app:
Yearly License: Individual $99 or Enterprise $299
Android:
Windows XP or Vista, OS X Tiger or higher, or Linux (tested on Ubuntu Dapper Drake)
Eclipse 3.3 or 3.4 (free download from eclipse.org)
Java JDK 1.5 or 1.6 (free from Sun)
Apache Ant 1.65 (Linux/OS X), 1.7 (Windows) (free from apache.org)
Good chart at engadget.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Wrong.
Quoted:
For example T-Mobile will not restrict applications providing a work-around to the SIM lock feature or prohibit Voice over Internet Protocol (VoIP) software, such as Skype applications, that come from the Android development community, according to Gartenberg.
"T-Mobile's CTO [Cole Brodman, who also serves as chief innovation officer for T-Mobile USA] told me that he while he can't say he'd like that to happen he isn't going to restrict it or stop it," said Gartenberg. "That's the spirit of how open they are to being an open platform and the fact they understand what it's all about."
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
Most of the article compares subjective/non-concrete things such as how many people use Obj-C and how many use Java. It misses on one significant aspect of the choice of language. Java opens up numerous possibilities for Android. In my opinion that was an obviously good move from google. Here is why -
1) Safety - Java provides a lot wider safety net than native language can ever.
2) Control - you can enforce the signing requirements in the VM for all code that is run or you can limit it as a requirement to only certain potentially unsafe APIs (RIM does this - you don't need to sign an App with RIM provided keys unless you use the more dangerous APIs.) This arrangement can generally give the user a lot more flexibility and control over what can and cannot run on the phone.
3) Exceptions are non fatal and possible recoverable, memory leaks are harder to induce
4) Verification of software is easier - API usage, control over how much memory is used, what network connections are made etc.
Before people complain Java is ugly and slow - this is J2ME (Java Micro Edition) that we are talking about which is much more lean and has different UI (Android UI doesn't look anything like the ugly Desktop Java and neither does RIMs - both use J2ME) These factors obviously matter a lot in a Cell phone type environment. I am especially happier with my Blackberry that it allows me to control what a Application can do or cannot do - make Wifi connection - No, access my address book - hell no, Access location - yes, Access Device Settings - no etc.
Um, you are aware that Android does not use Swing, AWT or SWT?
In fact, as someone who's actually written code for a bunch of different mobile platforms, including some proprietary ones (shudder, shudder, 20 minute build cycles, shudder), Android is an absolute dream to code for.
In essence, Android encourages applications to be data-centric; and the Android UI allows to to hook up a custom View of your choice to a real SQL backend via automatic cross-process IPC (which allows you to export data to other apps) in about 100 lines of well-spaced code. Compared to, say, Symbian, where you have to spend half your time thrashing through their documentation trying to figure out the lunatic memory management model and the other half waiting for it to build, it's simply so nice. Instead of having to spend all your time on trivial data management issues you can simply press ahead to the application logic itself.
(Not to mention that the Android tools work. The debugger just works, and honours breakpoints, which is more than you can say for Symbian's.)
(Also, as the Objective-C object model was blatantly stolen from Smalltalk, and the Java object model was also blatantly stolen from Smalltalk but with C++ syntax, there's actually much less in it than you might think.)