Tuesday, December 6, 2011

Debugging Phonegap/Cordova Applications

When developing a mobile application with PhoneGap, there inevitably comes a point when things don't work as expected.

When this happens, I triage the application in the following order:

  1. Sanity Checks on the HTML and JavaScript
  2. Verify event binding
  3. Inspect variable values
  4. Wire protocol analysis

Sanity Checks

JavaScript is a Misunderstood Dynamic Language. Unfortunately, that rules out many compile-time sanity checks. The good news is that it doesn't rule them all out. JSLint is an excellent tool to add to your Eclipse environment to quickly look at your code for syntax errors. Personally, I turn off the options for whitespace checking and add a list of known, created classes and configure JSLint to inspect all javascript files in my project. This simplifies the checking of my own flaky code. The only downside is that other included libraries have to be cleared to remove "problems" in the output. JSLint can be very strict in what it considers acceptable JavaScript (=== versus == as an example). The easiest solution is to right click any 3rd party files such as the phonegap-1.2.0.js file and the jquerymobile/jquery javascript files and tell rockstarapps to clear javascript errors. This allows any errors in your own JavaScript files to show through in the Eclipse problems window.

Verify Event Binding

When verifying event binding, the easiest solution is a simple alert message. In many cases this is all that's needed. If you'd like to instrument your code further, you can use the console.log statement. This is visible in the IDE debugging window in many environments. console.log allows you to write out debugging messages that don't interfere with the flow of your application in the same way alert messages would. There are some notable exceptions where the device will not report the message. Most commonly, when running on a physical device (e.g. HTC Evo) console.log messages aren't logged in Eclipse. In these cases, you can turn to weinre (pronounced "winery"). This tool works by running a local server and communicating with this server from your PhoneGap Application. This is a fantastic bit of technology, but the setup can be a bit daunting. Fear not, the PhoneGap devs have provided a wonderful service at http://debug.phonegap.com/. This service allows you to enter a globally unique ID (I simply use my name). By inserting a javascript link with this guid, your mobile device can automatically route console.log information to the phonegap server where you can view the output. Communication is two-way, allowing you to highlight html elements and see the regions highlighted on the device. The latter feature is invaluable for identifying bits of dynamic content that didn't work out as planned.

Inspecting Variable Values

While developing applications, I tend to go through a large number of iterations simply in chrome. After developing the UI, I view it in chrome and use the inspect element feature to view details about the output. Using CTRL+SHIFT+I, I can bring up an environment that allows me to inspect CSS styles, step through javascript, and view the resulting HTML in the browser. The key to working well with this is isolating your user interface code from the device. As an example, I like to create javascript classes that have canned data in addition to the live server data. This allows me to eliminate data/network issues from the user interface. In the same way, I insulate the user interface from the physical device. This allows me to test my interface in a desktop browser without the overhead of an emulator (more iterations == faster development), and it allows me to rule out issues between PhoneGap and my own code (hint: it's always my code that's wrong).

Wire Protocol Analysis

If your user interface looks right with the data you're expecting, but you're not getting what you're expecting, it's time to rule out issues between the client and the server. In these cases, I like to use WireShark to capture the communication between the client and the server (again isolating the physical device as much as possible from the equation). Before selecting the network interface to capture on, I navigate in my application as far as possible before the issue in question. This reduces the junk I have to look through while debugging. You can definitely do this with filters in WireShark, but for the novice, it's easier to limit the incoming data.

Last Recourse

When none of these techniques solve my problems, I tend to post to the phonegap google group. I encourage all of you to do the same and please don't be shy if you have a possible solution to someone else's problem. Even if it isn't the perfect answer, it can set someone on the road to success.

Wednesday, October 26, 2011

SMSPlugin added to PhoneGap plugins repository

My SMS Plugin has been added to the phonegap-plugins repository (https://github.com/phonegap/phonegap-plugins/tree/master/Android/SMSPlugin). Glad to be able to contribute. Thanks to Simon Mac Donald for his assistance with the process.

Wednesday, September 14, 2011

Creating a Plugin with PhoneGap 1.0

PhoneGap allows developers to access many native phone features from Javascript/HTML5 pages running in a local web browser.  Unfortunately, not every feature has been implemented.  So what do you do when you need something that's not provided by PhoneGap?  You roll up your sleeves and write a plugin.

This guide is specifically for PhoneGap 1.0.  Earlier versions used a slightly different model.

One native feature that would be convenient to have available is the ability to send text messages from our app.

Let's start with a vanilla page

<!DOCTYPE html>
        <script src="jquery-1.6.min.js" type= "text/javascript">
        <script src="jquery.mobile-1.0b3.min.js" type="text/javascript">
        <script src="phonegap-1.0.0.js" type="text/javascript">
        <script type="text/javascript">             
        function onDeviceReady () {
   $('#send').bind('click', function () {
    alert('This will send a text message'); 
        document.addEventListener("deviceready", onDeviceReady, false);
        <link rel="stylesheet" type="text/css" href= "jquery.mobile-1.0b3.min.css">
        <meta name="viewport" content= "width=device-width; height=device-height; user-scalable=no">             
  <div id="startPage" data-role="page" data-theme="a">
   <div data-role="header">
    <h1>SMS Demo</h1>
   <div data-role="content">
    <label for="phone">Recipient Number:</label>
    <input type="tel" id="phone" name="phone" placeholder="SMS Number"/>
    <label for="message">Message:</label>
    <textarea id="message" name="message">
    <a href="#" id="send" data-role="button">Send</a>  

The bridge between our javascript and PhoneGap is a custom javascript object

var DemoPlugin = function () {

DemoPlugin.prototype.sendSMS = function (successCallback, failureCallback, phone, message) { 
 return PhoneGap.exec(successCallback, failureCallback, 'DemoPlugin', "SendSMS", [phone, message]);

Add this to your HTML with

<Script src="demoplugin.js" type="text/javascript" />

In order to create our plugin, we'll create a new Plugin class in Java, and configure it in the plugins.xml file.  Right click on your package name in Eclipse and select New->Class.  Inherit from PhoneGap's Plugin class and implement inherited methods..

The general pattern for a PhoneGap plugin is to define an Action String that will be passed to the plugin describing what the user wants to do.  The arguments to the function are passed in a JSONArray.  After processing the plugin exec call, the function returns a PluginResult which can indicate success or failure (and even return variables.  This result will call either the successCallback or the failureCallback supplied by your javascript.

package net.practicaldeveloper.demo;

import org.json.JSONArray;
import org.json.JSONException;

import android.app.PendingIntent;
import android.content.Intent;
import android.telephony.SmsManager;

import com.phonegap.api.Plugin;
import com.phonegap.api.PluginResult;
import com.phonegap.api.PluginResult.Status;

public class DemoPlugin extends Plugin {
 public final String ACTION_SEND_SMS = "SendSMS";
 public PluginResult execute(String action, JSONArray arg1, String callbackId) {
  PluginResult result = new PluginResult(Status.INVALID_ACTION);
  if (action.equals(ACTION_SEND_SMS)) {
   try {
    String phoneNumber = arg1.getString(0);
    String message = arg1.getString(1);
    sendSMS(phoneNumber, message);
    result = new PluginResult(Status.OK);
   catch (JSONException ex) {
    result = new PluginResult(Status.ERROR, ex.getMessage());
  return result;

 private void sendSMS(String phoneNumber, String message) {
  SmsManager manager = SmsManager.getDefault();
        PendingIntent sentIntent = PendingIntent.getActivity(this.ctx, 0, new Intent(), 0);  
  manager.sendTextMessage(phoneNumber, null, message, sentIntent, null);

In order to register this plugin with PhoneGap, add a single line to the res/plugins.xml file:
<plugin name="DemoPlugin" value="net.practicaldeveloper.demo.DemoPlugin"/>
Don't forget to add the permissions your app needs to the manifest
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    <uses-sdk android:minSdkVersion="7" />

 <uses-permission android:name="android.permission.SEND_SMS"/>
 <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
 <uses-permission android:name="android.permission.INTERNET" />
    <application android:icon="@drawable/icon" android:label="@string/app_name">
        <activity android:name=".PluginExampleActivity"
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />


Finally, you can modify your javascript to call the plugin asynchronously.
function onDeviceReady () {
     * Updated based on a comment from Simon 
     * Mac Donald.  This is the recommended
     * syntax for integrating plugins 
    PhoneGap.addConstructor(function() {
        PhoneGap.addPlugin("demo", new DemoPlugin());

    $('#send').bind('click', function () {        
        //var plugin = new DemoPlugin();
        window.plugins.demo.sendSMS(function () { 
           alert('Message sent successfully'); 
        function (e) {
            alert('Message Failed:' + e);

Friday, August 26, 2011

Facebook integration with Android and PhoneGap

Part of my current project involves posting to Facebook when a user completes an action.  Conveniently there's a plugin and an excellent article on how to use it  Unfortunately, when I tried to call the authorize function, I found that the Facebook page would load, and then quickly close without performing the authorization.  Looking at the console output in DDMS showed that the error was :Login Failed:  invalid_key.

When you create an android application that integrates with Facebook, you need to tell Facebook what your application key is using the following statement:

keytool -exportcert -alias androiddebugkey \
        -keystore ~/.android/debug.keystore | openssl sha1 -binary \
| openssl base64

Great.  Unfortunately what I wasn't aware of was that if you use the wrong password when prompted, the keytool silently returns a garbage string that is NOT your key.  Thanks to some quick research on stackOverflow and I found that the default password for the keystore is 'android'.  Providing the correct key to Facebook allowed the plugin to correctly authorize me.  Hopefully, this will be helpful to someone else!

Monday, July 25, 2011

If at first you don't succeed, plug it in

I had created a WCF service to accept some data and had been testing it.  One method was succeeding and the second was failing with a 500 Internal Server Error.  I circled around and around trying to find the solution.  I rebuilt my local proxy, I verified that the methods were in there.  Still no luck.  I then enabled message logging in WCF on the server side.  What was odd was that the first method was logged successfully, but there was no record of the second method call.  I started thinking I was going to need to capture packets with Wireshark and analyse things at the wire level.

You know what I did wrong?  My code was configured to use one endpoint, but allowed the user to change the server for testing purposes.  I was never assigning the new server to client.ChannelFactory.Endpoint.Address.  It's not the complex problems that slow you down, it's always the little things.

Thursday, June 30, 2011

Monday, May 23, 2011

Starting a Project with Phonegap in Eclipse

Recently, a colleague was asking for assistance setting up a development environment.  The good news is that there are a number of tutorials that go in to detail about how to get started.  The bad news (which is good news too) is that because PhoneGap is advancing rapidly and gaining developer mind-share, these tutorials are getting outdated quickly.For the record, the one that I recommend at the moment is located at: http://wiki.phonegap.com/w/page/30862722/phonegap-android-eclipse-quickstart.  This howto doesn't require developers to set up git and ruby, and works with the latest build of PhoneGap.

Walking my colleague through these steps, it occurred to me that it would be much easier if someone created an Eclipse Plugin.    The good news is that someone did.  The installation is, with a minor exception, pretty straight forward.  

  1. Under the Help menu in Eclipse Helios,select "install new software"
  2. Enter the address:  https://svn.codespot.com/a/eclipselabs.org/mobile-web-development-with-phonegap/tags/r1.2/download in the Work With combo and click add.
  3. Give it a meaningful name such as MDS PhoneGap for Android Plug-In
  4. Here's where I ran into an issue.  The plug-in wants to install the JavaScript Development Tools (JSDT) and it was failing to install.  Unclicking this particular component allowed the installation to complete.

After completing the installation, you'll be able to start a new PhoneGap project by selecting File->New->Other->PhoneGap for Android Project.  The wizard allows you to specify local, web, internal, or git repository locations for the PhoneGap bits.  As a bonus, you can also opt to include the JQueryMobile or Sencha Touch in the project and build the sample application.  It's never been easier to get started with mobile development.

Monday, May 16, 2011

Use Android Open Accessory Without Android Programming

I have to admit, I find the Android / Arduino intersection to be the nexus of nerdliness.  I mean that in the best possible way.

For those unfamiliar with the Arduino, it's a micro-controller platform based on an Atmel chip that simplifies the process of processing input from a wide array of sensor input and controlling a similarly broad range of output devices ranging from lights and servos, to sound, etc.  Yes, there are more capable platforms and less expensive platforms, but the Arduino at around $30 is an incredible gateway to that larger world.  It allows folks like myself to skip the minutiae and get  right to the fun parts of physical computing.  I had a few years of college level electronics and had forgotten it all before I graduated.  Getting an Arduino and programming it to control the color of an RGB LED or respond to varying resistance from a flex sensor scratches a very geeky itch.

The fact that Google selected Arduino as the base platform for their accessory kit says a lot about the momentum of this micro controller platform.  It's unfortunate that they chose to make their android accessory kit less than 100% compatible with basic Arduinos, and bewildering why it costs $400.  The good news is that because of the broad range of support the Arduino has in the wild, many developers have already begun to hook up your vanilla boards to Android handsets.

Make magazine has been a great resource for all things Arduino and shared this link for an Android app that can communicate with your Arduino and vice-versa.  There's more great coverage on the significance of all of this at Make Magazine

Thursday, May 5, 2011

Enabling ADB (Android Debug Bridge) over USB to a Nook Color under Linux

I've replaced the stock software on my Nook Color with CyanogenMod7.  This is a modified Android 2.3 (gingerbread) image.  This has a number of advantages over the original distribution and even over the updated Barnes and Noble 2.2 distribution.  Notably it provides Bluetooth and a real Android market.

I wanted to enable ADB support so that I would be able to run applications directly from Eclipse on the Nook Color.

Before you do anything else:

  • Enable USB debugging on the device by using the Menu -> Settings -> Applications -> Development ->  USB Debugging.  If you don't do this, you won't even see the device listed under adb.  Note the vendor ID that's shown when you execute lsusb.

After doing this, I followed the instructions from http://nookdevs.com/NookColor_USB_ADB

The following command tells android that the nook color is an android device.  See the same vendor ID?

mkdir -p ~/.android && echo 0x2080 > ~/.android/adb_usb.ini && adb kill-server && adb devices
Now here's the tricky part for me....after executing adb devices, the nook color was showing as ??????? no permissions.  There were a number of workarounds for this, but I found that they were all running into similar issues.  Either they had the wrong vendor ID or they were using the wrong attribute name, or they were executing too early and were being replaced by the default udev rules.  In the end, I had to edit the udev rules as follows:

sudo vi /etc/udev/rules.d/90-android.rules
add the following text:

SUBSYSTEM=="usb", ATTRS{idVendor}=="2080", MODE="0666"
restart udev with

sudo service udev stop && sudo service udev start
restart adb from the platform-tools directory using

./adb kill-server && ./adb start-server

when you execute adb devices again, you should see your B&N Nook Color serial number and you'll be able to debug directly from Eclipse!

Wednesday, May 4, 2011

Free eBooks on iPhone / Android development with PhoneGap

Jonathan Stark has released books on developing mobile applications for iOS and Android.  These books are free to read for a limited time on the O'Reilly Open Feedback System.

Monday, May 2, 2011

Utilizing Hybrid Toolkits for mobile development

In my previous posts, I touched on the fact that Mobile Web applications have a wide reach across a range of devices, but fail to benefit from the mobile device capabilities.  This is contrasted with application development using native SDKs which have full access to the mobile device, but are restricted to a single platform.

Hybrid toolkits find that sweet spot in the Venn diagram where the device capabilities and device independence meet.  Two such toolkits are PhoneGap and Appcelerator Titanium.  Each of these tools allows you to access the sensors and work with the device capabilities of Android and iOS devices.  In addition, PhoneGap has support for BlackBerry, WebOS, and Symbian with beta support for Windows Mobile.  Appcelerator is currently in beta on their Blackberry Support.

Each of these tools allow you to develop mobile applications with JavaScript.  PhoneGap applications are hosted in a Webkit browser.  Appcelerator applications benefit from compiling down to native controls for the destination platform.  Both tools allow developers to interact with the mobile devices including:  SQLLite databases, local storage, sound recording and playback, location (network/GPS), camera, orientation, vibrate, and accelerometers.

Both tools are supported by Android Market and Apple's App Store.  Both tools are free and open source.  This means that you can download them BOTH and try them out to see what you like.  Both toolkits have similar feature support on Android and iOS.  PhoneGap gets a nod for widest device support and Appcelerator gets a nod for native control support.  Right now, I've found that the PhoneGap documentation seems more complete and well written, but I think both tools have a tremendous amount of potential.

I'm working on some demo applications right now and hope to post some details soon!

Saturday, April 30, 2011

Interesting commentary on why Android is beating iOS on Phones, but not Tablets

I just saw this article on how Android is beating iOS on phone handsets, but still lagging behind on Tablets.  I think the problem is that no one, even Motorola has released what the public wants from an Android tablet. 

The author posits 5 theories on why that is:
  1. The iPad2 is just that good.  Even those with fanatical aversion to Apple products can't avoid it
  2. Users are waiting for a viable choice.  Right now the XOOM is the only (legitimate) Android tablet option.
  3. Apple's cornered the market on components, forcing competitors to charge more for similar capability.
  4. Would-be Android tablet owners are just slower to adopt the new technology.
  5. Android Tablet owners aren't competing with the iPad, but with Netbooks and Laptops.
Personally, I don't give much weight to the first and last options.  There's nothing magical about the iPad2.  The iTunes lock-in and flash lock-out turn me off from the iPad2.  I think that #4 is more of an effect than a cause.  That leaves the choice of a viable tablet at the right price.

I've been conditioned over the years to see Apple products as having inflated prices when compared to their PC counterparts.  After years of this, I expect that when Apple releases a tablet that costs $500, that someone else should be able to release an Android version with similar capabilities for half of that.  Unfortunately, we're not seeing that. 

The first batch of low-cost Android tablets had resistive touch screens and were only running Android 1.6 without an Android Market or upgrade options.  The Motorola XOOM, has the specs for the most part, but benchmarks place it below the iPad in terms of performance.  With no cost savings to be had, would you buy the iPad2 or a pale imitation?

I personally opted for a Nook Color reader when I heard that you could load a full version of Android on it.  I know it's not an iPad and it's not even officially an Android tablet, but it does what I want it to do.  For me, it replaced a Nokia n800.  I can email, browse the web, watch youtube videos, and with the CM7 mod on it, I have access to flash sites.  I have the full Android market.  I already pay for a data connection on my HTC Evo, so I didn't want a device that forced me into another data plan.  The screen size is just right for carrying around without being too cumbersome. 

So why do you think that Android tablets have failed to gain traction?

Friday, April 29, 2011

Mobile Development with Native SDKs

Mobile Web Applications work on a wide range of devices but lack the ability to access handset features.  Specialized tools like Google App Inventor provide access to those features, but have their own limitations.  Contrast this with native SDK development for mobile platforms.

Utilizing the SDK for iOS or Android gives you complete control over the application you build.  Unfortunately, that control comes at a cost.  At the risk of offending faithful loyalists to one platform or another, both iOS and Android are very similar in how they manage applications and make the most of the resources of the phone.  The devices using these operating systems are also comparable, providing common features like location data and cameras.  Despite this commonality, when you write an application with a native SDK, you tie the resulting output to a particular platform.

Setting up an iOS development environment involves getting XCode from Apple.  XCode 3 is a free download from developer.apple.com.  XCode4 is available for purchase from the App Store or is a free download for members of the iOS Developer Program.  You're likely going to want XCode4 since you won't be able to run your iPhone or iPad application on a physical device without paying the $99 annual fee for the iOS developer program.  All of this is restricted to a Apple hardware.  You're going to need a Mac of some type in order to build and test your app as well.  There is another option for building iOS apps in the cloud, but that's another post.....

Setting up an Android environment on the other hand can be done on Linux, Windows, and Mac platforms.  The Eclipse IDE is the development tool of choice and the Android Developer Toolkit plugs right into it.  The Android SDK rounds out the development environment.  Full instructions for various platforms can be found on the Android developers portal.

The Android SDK and Eclipse provide an environment where you can design, build, and test your application, using emulators that support various flavors of Android with varying screen sizes.

Native SDKs provide full access to platform capabilities, but the price of that access is that you need deeper knowledge of the platform that your developing on.  Each tool uses a different language and has a different API for access to the device features.

In the next post, I'll discuss how you can get the best of both worlds by using a Hybrid toolkit.

Using Google App Inventor to Create Android applications

Google App Inventor is a clever application that allows point-and-click creation of simple Android applications. Itself built using the Google App Engine, App Inventor is a web application that communicates with some local Java components to build and deploy to your connected phone or an emulator

In order to work with app inventor, you'll need to make sure you have Java running and download the the software for your platform (Linux, Mac, and Windows are all supported).  Once you start the software and connect to appinventor.google.com, you can create a project.  Within the design environment, you can place controls on a drawing surface and configure their basic properties.

The control available include the basic input and interaction controls you would expect, but in addition, there are controls for animation, and media playback as well as controls for sensor input.  One of the more interesting control types is the LEGO MINSTORMS group of controls.  These controls allow you to interact remotely with sensors and motors and open the door to some intriguing physical computing opportunities.

Opening the blocks editor, allows you to connect the components with logic by dragging and dropping blocks of logic and connecting them with corresponding snap-ins.

To test your application, you can connect your phone or start the emulator and click the connect to device button.

Google App Inventor is a clever bit of programming and opens up avenues for simple application development, but it does have it's limitations.  Currently, app inventor apps are restricted to a single screen and the connectivity to remote servers is limited to the TinyWebDB component.  The good news is that even with its limitations, the app inventor gives would-be developers a great deal of access to the capabilities of their Android devices.

Next Up: Using native SDKs

Mobile Development Approaches for iOS and Android

There are a number of different approaches when developing mobile applications, each having a unique set of strengths and weaknesses.
  • Mobile Web Applications
  • Specialized Tools
  • Native SDK Programming
  • Hybrid Toolkits
Mobile Web Applications are attractive because they support the widest array of devices and because many of us are already familiar with the web development model.  The transition to building HTML/CSS/AJAX applications that execute on a mobile device is relatively painless and in many cases developers can reuse existing content or back-end logic.  

Of course, the drawback to pure mobile web applications is that we lose access to all of those interesting sensors that the device has.

Web applications executing on a mobile device have a different set of constraints when compared with their desktop counterparts.  These constraints include, but aren't limited to, reduced bandwidth, smaller display, cramped input mechanisms, and cookie restrictions.  In order to avoid common pitfalls, developers would be wise to review the W3C guidelines for mobile web applications before going down this road.  While you're there, it makes sense to familiarize yourself with the HTML5 and CSS3 standards as well.  Standards-based web applications will be more portable across a range of devices.

Another useful piece of advice when developing a web application that will service mobile devices and desktop browsers is to develop the more restrictive UI first.  Performance gains made while optimizing for mobile devices may benefit your desktop users as well.  CSS3 has some nifty features for applications on different devices.  CSS media queries allow you to define styles that gracefully scale down on less powerful devices while providing a richer experience to more capable platforms.  An example of this would be to perhaps provide a text-only link for a smaller browser instead of a larger image button.  

When developing iPhone Web Applications, JQTouch, a jQuery plugin, can provide style and animations that give your application the appropriate look and feel.  JQTouch is MIT licensed, allowing you to freely distribute your proprietary application code as long as you include the license.

Why you should develop for Apple's iOS platform

Now that you know what the Android Platform has going for it, why should you develop iOS apps?  Creating apps for iOS isn't free, you'll need to pay a $99 annual fee to Apple to register as a developer and even then you have to have your application approved before it can be put in the App Store.  Yet even with this hurdle, the App Store has more apps than the Android Market.  That number was 4-1 in Apple's favor, and it's dropping a bit, but the App Store is where people buy apps.  This unified shopping experience allows you to publish your app to one place.  Contrast this with the fragmentation of competing markets for Android apps from Google, Amazon, and now Barnes and Noble.

iOS has another thing in its favor:  unified experience.  You know  the device that your application will be run on.  Questions about resolution and device capabilities can largely be ignored.  An Android application could be running on a Nook or on an HTC EVO, each with dramatically different capabilities.

Although Android has one set of numbers in their favor, Apple has another.  Andy Zaky reports in Fortune that:

Google will probably report about $6.5 billion in total revenue when it releases its first quarter results later this week. Apple's iPhone alone will very likely eclipse $11 billion for the March quarter. For 2011, Google is expected to report about $27 billion on the top line compared to the iPhone's expected $48.2 billion in revenue. The iPhone as a business is nearly twice the size of Google's entire operation. This is a financial reality rarely illuminated in these so-called "platform market share" articles where Apple investors are supposed to be "deathly afraid" of the Android operating system that doesn't even create a fraction of the revenue Apple generates from the iPhone.
With that kind of money involved, you'd be a fool to think that Apple's going away any time soon.

Next Up: Mobile Development Options

Why you should develop for the Android Platform

In my previous post, I discussed why you should be writing mobile applications today.  I also mentioned that the two major players are Android (Google) and iOS (Apple).  There are other contenders, but their representation is tiny in comparison.  So why should you develop for the Android platform?

The numbers say that you'll be reaching the broadest market if you develop Android applications.  With 50+% of the market, the Android OS has more eyeballs than Apple's iOS.  The numbers aren't the only thing going for Android.  The fact that it's free (free as in freedom and free as in free beer) goes a long way towards enamoring it to the developer community.  Anyone can download the Android SDK, developer tools, and Eclipse and start writing Android applications without having to pay anyone.  Those applications can run on physical devices without requiring licensing, permission, or voiding the warranty on your handset.

The fact that Android is free allows it to go places and in directions that weren't planned.  The port of Android 2.3 and 3.0 to the Barnes and Noble Nook reader shows that the developer community likes what it sees.

Next Up: Why you should develop for the iOS platform

Introduction to Mobile Development for Android and iOS

Mobile Development is a hot topic today.  There are a number of very good reasons for this.  First of all, mobile devices provide unique forms of input via sensors:  accelerometers, cameras, sound recording, and GPS location to name a few.  Secondly, the number of these devices is expanding rapidly.  Some analysts predict that mobile devices will exceed the number of desktops by as early as 2013.  The end result is that if you're not developing mobile applications, your competitors certainly are.

Those are the benefits, but there are pitfalls as well.  The mobile space is currently a battlefield and there will be winners and losers.  As each competitor attempts to outshine it's rivals, APIs will rise and be replaced quickly.  And finally, even if you were to choose a single OS to support, you have the possibility of internal fragmentation (iPhone3 vs iPhone4 vs iPad vs iPad2).  One writer goes so far as to say:

An AT&T “Android” phone is not an Android phone, but an AT&T one. A Samsung “Android” phone is not an Android phone but a Samsung one. If you get a Samsung phone from AT&T you get one thing, if you get the same phone from Verizon you get something else.

In the mobile space today, there are two major players Android (Google) and iOS (Apple) with Android leading at 51% and iPhone behind at 33%.  Based on a recent survey by Business Insider, the other contenders (Blackberry, Windows Mobile, WebOS) combined don't even add up to Apple's share.

So what platform do you choose and why?

Next: Why you should develop for the Android Platform