Thinking about buying an Android phone?

A few things to keep in mind when looking at going for an Android device.

A few things to keep in mind when looking at going for an Android device.

Apple iOS 4.0 vs. Android OS 2.2 for business use

Do the new mobile OS versions change the equation for enterprise adoption?

By Tony Bradley , PC World

With the launch of iOS 4.0 -- the rebranded iPhone OS 4.0 -- slated for June 21 and the recent unveiling of Google's Android OS 2.2, the two leading-edge smartphones platforms have new OSes to build on. There are a lot of cool "bells and whistles"-type features in both, but when it comes to deploying the smartphone as a business tool, which OS is better?

Perhaps neither of these smartphone platforms is "best" for the enterprise environment. Where security and manageability are concerned, RIM's BlackBerry OS is the leading smartphone platform by a wide margin, and even third-place Windows Mobile -- to be replaced with Windows Phone 7 in late 2010 -- is a more established business tool with tighter enterprise integration.

However, iPhone and Android are the best smartphones in general available right now, so business professionals and IT administrators need to be able to weigh which is better for their business needs.

Who wins for business professionals Let's stack up iOS 4.0 and Android 2.2 head to head. Email. iOS 4.0 introduces the unified email inbox to the iPhone. Rather than having a separate inbox for each email account, all email goes to one inbox and conversations are threaded for more efficient messaging. Android 2.2 does not have a unified email inbox or threaded conversations.

However, enterprise customers that use Microsoft Exchange and ActiveSync to push Exchange email to the smartphone already have a unified inbox on both platforms. By setting alternate email accounts to deliver messages to the primary Exchange inbox by default, those messages are then synced with Exchange, and delivered to the smartphone along with the rest of the Exchange messages.

Winner: iOS 4.0

Apps. The Apple App Store has about 225,000 apps -- a four-to-one advantage over the 50,000 apps available in the Android Market. It is debatable whether or not that matters. Certainly 225,000 is more than 50,000, but even 50,000 is a ridiculous number of apps. The core apps used for business productivity can probably be boiled down to a couple hundred, so odds are fair that you can find an "app for that" on either platform.

Winner: A draw

Flash. Apple is not allowing Adobe Flash on the iOS 4.0 platform. Much of the video content and interactive advertising on the Web is Flash-based, so the lack of Flash can be a handicap for iOS 4.0. Adobe did announce a partnership with Greystripe to deliver Flash-based ads as HTML5 on the iPhone and iPad, but much of the Flash content on the Web will be inaccessible. Android 2.2 does support Flash, and the Adobe Flash Player 10.1 beta for Android 2.2 is now available.

Winner: Android 2.2

Acting as hotspot. With iOS 4.0, tethering is now enabled from the iPhone to enable the Internet connection to be shared by other devices. However, AT&T is charging $20 a month extra just for the privilege of having the option to connect another device, and the iPad supposedly will be unable to tether with the iPhone.

Android 2.2 devices are capable of acting as mobile Wi-Fi hotspots. As many as eight devices can share the Wi-Fi connection of an Android 2.2 smartphone. Whether there are additional charges for the hotspot functionality, or how sharing the Internet connection will affect the data consumption and data plan charges may vary from carrier to carrier.

Winner: Android 2.2

Who wins for IT administrators

Now let's stack up iOS 4.0 and Android 2.2 head to head.

Availability. iOS 4.0 will be available as a free platform update for existing iPhone 3G, iPhone 3G S, and iPod Touch devices on June 21. When the iPhone 4 launches on June 24, it will also be equipped with iOS 4.0. Apple has only one hardware platform and only one supported OS version, so there is more stability and consistency in terms of managing the devices. Android is a much more fragmented platform. Android 2.2 has been rolled out to the Nexus One, and is expected to be officially available on other platforms "soon." However some Android smartphones may never get the update.

Winner: iOS 4.0

Diversity. iOS 4.0 -- or more specifically the iPhone it runs on -- is available only from one wireless carrier in the United States: AT&T. It is also only available on one form factor. There are slight variations between the iPhone 3G, iPhone 3G S, and upcoming iPhone 4 -- but for all intents and purposes it is the same hardware platform.

For businesses that are already contracted with another carrier -- like Verizon Wireless, Sprint, or T-Mobile -- iOS 4.0 is not an option. Organizations that want a physical keyboard or a different form factor will appreciate the diversity of smartphone hardware available running Android.

Winner: Android 2.2

Management tools. The iPhone has generally been perceived as a consumer gadget first and foremost. However, Apple revolutionized the game, and more or less erased the line between consumer and business when it comes to smartphones. Over time, Apple has developed a fair set of tools for IT administrators to be able to provision, deploy, monitor, and manage iPhones in the enterprise. Apple has also made strides in strengthening the security of the iPhone.

There are third-party management frameworks such as Good for Enterprise that enable IT administrators to manage Android devices, but by itself Android is still playing catch up in the enterprise tools department.

Winner: iOS 4.0

So that leaves us with three wins for iOS 4.0, three wins for Android 2.2, and one tie. The bottom line, though, is that "best" or even "better" is a subjective measurement tainted by opinion and personal preference. As noted, in some cases where the company is already under contract with a given wireless provider, the decision may be more or less dictated by what's available from that carrier.

In selecting a smartphone platform for the enterprise, IT administrators and business professionals need to keep these factors in mind, but these are by no means the only factors. Signal strength for a given carrier in your region, whether or not the smartphone will work globally for users that travel frequently, how the smartphones fit with any data protection or information security compliance requirements, and a myriad of other factors must also be taken into consideration to determine what is "better" or "best" for your specific situation.

Next: Where Android beats the iPhone

Page Break

Where Android beats the iPhone

Android's openness, flexibility, and Java foundation make it the best choice for many developers and the businesses that depend on them

By Peter Wayner ,InfoWorld

Can Google Android phones compete with the Apple iPhone? A few weeks ago, Google loaned me a Nexus One smartphone for experimentation, and I've spent the time since downloading applications and writing my own code. The good news is that the platform is not only competitive but is often a better choice than the iPhone for many programmers and the enterprises that employ them.

The Android line is now competitive enough that the casual user may look at the two platforms and assume they're twins. Both let you call people and fire up a number of apps by mashing your finger into one of an endless matrix of square icons. Both let you pull up Web pages. To my unsophisticated eye, the iPhone interfaces still look a bit prettier, but for most basic uses, iPhone and Android are as similar as Ford and Mercury or Coke and Pepsi.

The differences become apparent if you want to do more than make a few phone calls and iFart around. The iPhone app marketplace is dramatically larger and deeper, but there's already a palpable difference in the style. 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.

GScript, for instance, is an Android app that lets you write your own shell scripts and fire them off with a tap. Another useful app, Remote DB, lets you turn any SQL query into a button that searches the database remotely, then displays the results. It's the fastest way to generate a custom app -- the only code you need to know is SQL and the UI helps you with that.

That kind of openness is often rejected by the Apple App Store because Apple seems to fear the possibility that someone might add or modify the functionality of a program. Apple's terms specifically limit interpreters and emulators -- enough to force one Ruby implementation to disable the best parts of the eval function. Some reports suggest that the App Store reviewers are finally coming around to understanding the advantages in the technique taught to many freshman in their first computer science class, but no one really knows.

These kinds of flexible functions aren't just for code jockeys who use shell scripts all day long. Apps like GScript and Remote DB make it simpler for the IT staff to create rough but workable custom tools for all corners of the enterprise. The users can simply push a button and watch their phone do the right thing.

It's a Java world Android's relative absence of barriers was apparent again and again as I played with the Nexus One. At first I was a bit skeptical that anyone would do much with the open source license. Did it really make sense to reprogram the UI or the functionality if you're just going to take a few calls and check email? But some folks are relentless tinkerers, and they're building new Android distros. These are a long way from the Linux LiveCD ecosystem, but I can see this avenue being useful for an enterprise that wants to put a nice custom interface on top of Android hardware.

The open source foundation also makes adopting the platform that much easier for Java programmers. I was about to install a library to suck down a distant Web page when I realized that Eclipse was signaling that the library was already installed. Many classic frameworks like Apache's HttpClient are bundled right into the mix. So many parts of building an Android app will be very comfortable to an old Java hand.

Still it's important to be slightly skeptical about this openness. The code to interface with Google's excellent Map project is in the package, a clue that the interface is not open and that you're not welcome to use and distribute them any way you like. Also, many users who take root-level control of their phone are finding that it can be a real hassle to keep up with bug fixes and other changes.

These limits will affect the most capable and most extreme developers, those out to remake the phone from bottom to top. A far greater number of developers and their employers will be happy with the basic freedom to distribute software. While the Android does require the developer to add a digital signature to the JAR file holding an application, the developer can use a self-signed certificate, an option that allows some control without putting Google at the center of all distribution. Keep hold of the key for this self-signed certificate because the phone will only accept upgrades to packages signed with the same key.

After the code is signed, any path between developer and phone is acceptable. A number of third-party programs will grab the APK from the file system and install it. The very fact that I can write "file system" without using felonious words like "jailbreak" is a welcome treat. There's one app, SwiFTP, that lets you upload and download files from your phone over the Internet using a proxy Website. It's quite a nice trick, and not something you'll find in Apple's App Store. When a friend tapped around the demo phone, he thought I'd done something bad, but it was just another app downloaded from the official Android Market.

Hello Android For the programmer, the advantages of the open ecosystem were apparent from the beginning. While it took me several days to get the keys sorted out when I first hooked up an iPod Touch to the Apple Xcode IDE, I actually got the "Hello World" test working on the Nexus One before I fired up the simulator. Eclipse just noticed the Nexus One was hooked up to my PC, then started up the code. I glanced over and my new app was just running.

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.

The biggest challenge for the Java programmer is working through the seemingly endless layers of indirection coded in XML and properties files, all intended to make it easier to create applications for different screen sizes and languages. Apple is just beginning to add these features to support the iPad, but Google anticipated all of this from the beginning. You can set up the simulator to handle different screen sizes. So when is the Google Pad coming? HP and others are already hard at work.

Here is another place where Google's approach is so much saner than Apple's decision to wrap a nasty nondisclosure agreement around its SDK. As Apple would have it, programmers can't talk to other people, such as bosses and investors, about the iPhone and iPad capabilities unless those folks pay the cash and join the developer program. And is it really possible to call something nonpublic if anyone with $99 can get a copy of the SDK? Is this really what the law means by taking reasonable precautions to protect the so-called trade secrets? Go ask Apple's lawyers.

Despite Google's foresight to target screens of different sizes, I found it confusing to work through all of the XML and properties files. There's an old joke that a computer scientist solves problems by adding another layer of indirection. The Google programmers solved plenty of problems in making this new phone and you have to go chasing through multiple layers to figure out how to put the label on a button. This will pay off when your app runs in X different countries with Y different screen sizes, but still it's mind numbing.

While Java programmers will feel right at home with Android on Eclipse, it isn't just for Java programmers; the phone can run any language embedded in Java. Projects like Jython and JRuby are great solutions, and dozens are out there. There are similar options in the iPhone world, but they're crippled by Apple's fear of meta-programming and the evils that can be done with eval.

Through a camera, darkly The SDK is still showing some annoying rough spots. I wrote one app that used the camera, but it would often lock up, and I couldn't figure out why. The code would work in portrait but not landscape mode; one minute it worked and the next minute it crashed. I finally traced the problem to a "helpful" feature of the accelerometer, which would set the camera to portrait or landscape mode depending on the phone's orientation. If I held the phone in landscape mode, my view would crash because it was expecting a parameter that was tall, not wide. But if I turned it back to portrait, it mysteriously worked because the bounding rectangle for the screen was now taller, not wider. That took more than a few minutes to find.

It's also important to recognize that a wide variety of options need explicit permission, and you must declare this in the AndroidManifest.xml file. On several occasions, my code wouldn't run simply because I forgot to turn on the permission to use the camera. Yet the error messages never said something like, "Go edit the manifest, doofus." This configuration, by the way, is implemented with a precision that programmers will love but might leave end-users a bit befuddled. There's one XML tag that enables the camera, while another enables the autofocus on the camera.

These features are lovingly enumerated for everyone downloading a new app. Presumably there are people who want to install software that uses the camera but not the autofocus, but my eyes glaze over when I get to the screen filled with a long list of permissions I'm about to grant. For all I know, I've clicked on one with the XML tag .

There are deeper issues that suggest how difficult it will be for Google to maintain consistency between the various phones. Some commenters at the Android marketplace have already developed a shorthand for buggy software that crashes: FC for Force Close. Some code that works on the Droid will "FC" on the Nexus One.

I think Google worked hard to future-proof its API, and the company certainly did a better job than Apple of planning for tablets and other bigger screens with different sizes. Still, I think the programmers will be testing their code on a number of devices for a long time. That's just one of the disadvantages to encouraging 50-plus models of phones to sport the operating system.

At times, this Java-based world feels just a bit too hardcore. While most of the comparisons in this review are with the dominant iPhone, it's worth mentioning that the Palm Pre and Palm's Mojo SDK may offer much of the flexibility of Android but in a dramatically simpler package. Most of the coding is done with CSS, JavaScript, and HTML, which are much simpler alternatives to the endless layers of XML and Java needed to build an Android app.

Droid futures The most interesting question to me is how Android's openness will change the entire ecosystem on the phone. On the first day I had the Nexus One, I created an entirely new test Gmail account to avoid any problems when I returned the phone. Yet when I called a friend by typing in his phone number, his face popped up on the screen. Was this a demonstration of the power of Google's endless databases to link together everything?

After some experimentation, I concluded that the photo came from the Facebook app I had installed on the phone. When I logged in to Facebook, the app pulled pictures, phone numbers, and who knows what else into my phone. I think I accepted this feature when the Facebook app's AndroidManifest.xml file was loaded, and I'm not sure if I can ever get rid of it.

This deeper openness is going to be the source of any number of surprises that will be even greater and more useful than the unexpected appearance of my friend's photo on the phone. I think some of the more serious companies will start to release APIs to their apps, allowing the programs themselves to link together and solve problems.

But the openness may also be a source of privacy and security nightmares. Banks and other organizations with sensitive information will want to walk carefully into this world. Many of the worst exploits today result from hackers stringing together two or three seemingly harmless features like the one that links photos to the dialer.

There are other interesting questions about the role of cloud services in our smartphone future. Google is still guarding access to the Maps API and forcing developers to get an API key before deploying. I wouldn't be surprised if Apple, Palm, and others are frantically working on their own mapping, search, mail, and who knows what other cloud services. Right now the phones are little clients that aren't too closely linked to the Websites, but I can see that changing if better performance makes it possible to tilt the playing field. The quality of the cloud may become just as important as the slick GUI, app store, or number of pixels in the screen.

This interaction with the cloud will be a question for the future. Right now, it seems that Apple won over the latte-sipping fashion plates who love the endless stream of cute games. Apple's decision to court the game developers is paying off in some amazing titles, but the Android platform is a real workhorse. Anyone who wants to do more than play games will find a huge range of possibilities in the Android platform.

While Apple is reportedly fixing some of the worst problems with the App Store process, the Android world avoids most of them by giving people the freedom to use the platform as they want. Considering that people have been using this freedom relatively successfully with PCs for decades, it's a welcome opportunity in the world of handhelds.

Next: How to Pick the Right AT&T Android Phone

Page Break

How to Pick the Right AT&T Android Phone

Looking for an Android phone on AT&T? Check out this breakdown of the carrier's Android-based options and how they compare.

By J. R. Raphael, Computerworld

When it comes to Android, AT&T isn't exactly the carrier of choice. Okay, let me rephrase that: When it comes to any phone, AT&T isn't exactly the carrier of choice. But with Android in particular, the network is known for locking down its devices in a way that goes against the platform's open nature, making it a tough company to recommend for anyone seeking the full Android experience.

That said, factors like work and family can make it impossible for some people to jump from one carrier to another. The good news: If you're set on AT&T and are thinking about switching to Android, you do have a couple of decent options.

Here's a device-by-device breakdown of AT&T's Android phones and how they compare.

AT&T Android Phone #1: The Samsung Captivate AT&T's newest Android offering is without question its most powerful to date. The Samsung Captivate, part of Samsung's recently debuted Galaxy S line of devices, is built to compete with top-of-the-line Android phones like Sprint's HTC EVO 4G. And it's a fairly solid contender.

The Captivate, available for $200 with a two-year contract, boasts a 4-inch, 800-by-480 Super AMOLED display -- slightly smaller than the 4.3-inch screens you'll find on the EVO or the Motorola Droid X -- and runs on a speedy 1GHz processor. It has a 5-megapixel camera with 720p HD video capture. Unlike Sprint's take on the Galaxy S, however, the Samsung Captivate does not feature a secondary, front-facing camera for video chat purposes.

The Captivate ships with Android 2.1. It is expected to receive the Android 2.2 upgrade at some point in the future, though no specific date has been announced so far. • The bottom line: The Captivate's Galaxy S sister phones on other networks will give you the same performance with extra perks -- a front-facing camera and 4G access on Sprint, for example -- and without AT&T's Android-oriented restrictions. If you're going to get an Android device on AT&T, though, the Samsung Captivate is generally the best choice you can make.

AT&T Android Phone #2: The HTC Aria The HTC Aria isn't in the same league as the Captivate, but when it comes to midrange Android options, it's a reasonable enough device.

The Aria, available for $130 with a two-year contract, has a 3.2-inch, 480-by-320 HVGA display. That's noticeably smaller than the displays you'll find on many other Android devices -- even older models like the Motorola Droid, which has a 3.7-inch screen. But depending upon what you want, that may not necessarily be a bad thing.

Size aside, the HTC Aria is also somewhat slower than its Android contemporaries: It runs on a 600MHz processor, compared to the 1GHz chip found in most of the higher-end phones being released these days. The Aria has a single 5-megapixel camera.

As for software, the HTC Aria currently runs Android 2.1. Given its relatively recent release date, one would imagine it'll eventually be bumped up to Android 2.2 -- but thus far, neither AT&T nor HTC has officially confirmed any plans for an upgrade.

• The bottom line: If you want a smaller Android phone for AT&T, the Aria might be an okay fit for you. You'd get far more bang for your buck, however, by paying the extra 70 bones and springing for the Captivate instead.

AT&T Android Phone #3: The Motorola Backflip The unusual form of the Motorola Backflip, AT&T's first Android phone, has made it the butt of plenty of jokes. Even if you like its oddly positioned keyboard and backward-flipping display, the Backflip leaves a lot to be desired.

In terms of hardware, the Backflip has a 3.1-inch, 480-by-320 HVGA display -- similar to the Aria's, only slightly smaller. It runs on a 528MHz processor, also a step down from the Aria, and has a single 5-megapixel camera. The Backflip sells for $50 with a two-year contract.

Aside from AT&T's standard software restrictions, the Backflip is currently limited to running Android 1.5 as its operating system. Motorola says the phone is scheduled to receive the upgrade to Android 2.1 sometime in the third quarter of this year. Given the fact that the 2.1 upgrade is still pending, there's no telling if or when the Backflip will receive Android 2.2.

• The bottom line: The Backflip is miles behind other Android phones in almost every measure. Unless price is a major factor in your decision, there's really no reason to get this device.

AT&T's Android Future AT&T has made it clear that it plans to offer more Android phones in the months to come. Already, the carrier is preparing to launch the Dell Aero, billed as the "lightest Android smartphone ever." Other as-of-yet unannounced devices are likely in the hopper, too.

For now, you certainly won't find the most complete Android experience or the most compelling Android selection on AT&T -- but you can find something worth owning, at least relative to the network's other smartphone options. Plus, as an added bonus, you can always chuckle to yourself knowing that your carrier's CEO is a dead-ringer for Stephen Colbert.

Hey, that's gotta be worth something.