A new mobile SDK from Intel is designed to help you solve the occasionally connected computing problem. The Intel® Mobile Platform Software Development Kit v. 1.1 addresses a lot of the implementation problems at the coding level, with a number of calls that let you detect (and in some cases modify) the exact configuration that your software is running on. Yes, there are operating system APIs that do this – but they’re often obscure, and they’re not portable.

The Intel Mobile Platform SDK is portable, supporting many flavors of Windows* 2000/XP, Windows CE and Linux*. More importantly, it goes beyond C++ (which is typically where such low-level APIs are accessed), and can be used from Visual Basic, C# and – amazingly – Java.

That’s good, as far as it goes. But the biggest part of the occasionally connected computing problem is that most developers and product managers don’t know they have it – and wouldn’t care about it, even if they did know. With a little bit of help, Intel could possibly address that problem too. Let me explain.

Applications have to work properly in an ever-changing world of mobility, where you can’t just sniff the hardware and network, and know what you can do. The hardware can change in the middle of a session – and so can the display, the connectivity, the security, the input device, the power state, available storage and a whole lot more.

How can you handle that? Most developers don’t. They make a particular set of assumptions about how their application will be behave, and define the application’s behavior based on that. If those assumptions are wrong – if a Web 2.0 browser application finds itself without a network link – something bad happens. The application fails, the user loses data, and the computer flies out a convenient window.

I’ve been preaching the gospel of occasionally connected computing for a couple of years (See “ Mobile Applications Developer FAQ ” and “ Designing a Better Mobile Application – Think About Different Use Cases ” ), but have consistently run into three problems with the occasionally connected computing message that architects and developers need to do a better job planning for and accommodating mobility.

1. They simply can’t see where to mobilize the software – that is, they can’t visualize how use cases change depending on the users’ location, power source and connectivity.
2. They can see the user cases, but can’t see why spending the time and effort to accommodate them will make good business sense.
3. They’re convinced that accommodating mobility makes good business sense, but are stymied about how to accomplish it on an architectural or coding basis.

Unfortunately, far too many people I know can’t get past the first part of the occasionally connected computing problem – or even worse, haven’t even thought about it at all. The point I want to focus on here, however, is the third issue: how to actually mobilize the software.

This is hard – it always has been, and to be honest, despite the programming tools on the market, it remains complicated. Many of these issues involve tricky programming, including using device-specific APIs or obscure operating system calls that aren’t well understood, very reliable or (most importantly) very portable. Learning those calls, and realizing that they have to be adapted for different devices and peripherals, can make mobilization a non-starter except when it’s truly mission-critical or business-critical.

Now, to the Intel Mobile SDK itself. Is it perfect? Alas, not yet. The big problem for me is the large 6.5MB installer download that’s required for the runtime components. That’s fine if you’re using a high-powered device on a LAN, or if you’re installing the Intel Mobile SDK from a CD-ROM or local file server, but it’s a heck of a big download for WiFi or dial-up users, handheld devices, or for systems with constrained storage and processing power. If Intel can find ways of getting mobile device OEMs or major Independent Software Vendors (ISVs) to bundle the SDK with their products, that would be great. Once installed, the footprint is fairly small. But as it is, that’s a bit of a problem.

Another issue building awareness – and making the SDK ubiquitous. There are two ways that Intel is missing the boat. The first is that they’re charging something like $1,500 per developer seat to license the SDK -- this includes permission to redistribute the runtime along with the application. I can understand that Intel wants to recoup some of its investment, but its goal should be evangelization, not revenue. If there are intellectual property issues, put the SDK out there for free – require a license, if the lawyers insist, but reduce any possible cost barrier. If there aren’t IP issues, then Intel should release it to the public domain, including a project on a site like SourceForge.com , to get more enthusiasts onboard.

The second issue is seeding the technology, the runtime technology, with consumers. Look at what Macromedia did with Flash*, and what Adobe did with the Acrobat Reader* (now just Adobe Reader). Intel should get some of their bright developers to write some compelling applications that leverage the Intel Mobile SDK – and give them away. Games, calculators, stuff like that. Maybe run a contest on a platform like TopCoder . (Intel is currently running a threading competition on TopCoder right now, so that should be easy.)

Seeding the marketplace with a contest and free applications would serve three goals. First, it would increase consumer awareness of the issue, so that consumers would demand mobile-aware applications from their ISVs and software providers. (Hmm, do I detect a “Intel Mobile SDK Inside” logo?) Second, it would inspire some programmers to play with the technology. And third, of course, consumers would then install the runtime on their client machines, increasing its installed base in the marketplace.

I guess I’ve climbed back up on that soapbox again.

Alan Zeichick is principal analyst at Camden Associates, where he specializes in networking, software development and software security. Reach him at zeichick@camdenassociates.com