VSLive! Speaker Interview—Ed Kaim

Right now the Java world seems to have a head start when it comes to programming for mobile devices. So it seems reasonable to ask Microsoft what it's doing for Visual Studio developers who want to work with mobile applications. Ed Kaim, Microsoft's Mobile Application Product Manager will give VSLive! New York attendees a first hand look in his keynote on June 17.
As a preview, check out how Ed answered some of the questions with Visual Studio Magazine editor in chief Patrick Meader . If what Ed says pans out, Visual Studio developers hold the future in their hands—so to speak.

Every developer is familiar with this model. What we've done is to bring that to the devices world. The Mobile Internet Toolkit (MIT) is our server-side development story. It's ASP.NET, and it's our way of scaling mobile applications to mobile devices.

The Compact Framework is the client-side version. It's just like the .NET Framework that would be running on a desktop application. The Compact Framework enables the rich-client applications with great user experiences that you'd expect from a Windows application. You get integration with assets on the operating system, whether it's the ability to make phone calls directly inside your applications or integrating with PocketPC assets, such as SQL Server CE and Pocket Outlook. You also get the ability to have rich offline experiences because the code actually lives on the device.

Are there scenarios where you'd use both in tandem?
There are definitely situations where you could have complementary stories. If you're connected and want a broad-reach scenario for your customers, you might want to have a Mobile Internet Toolkit of something. Whereas inside your company, if you need richer and more flexible functionality, you might require a Compact Framework application that uses Web services. But there's kind of a line in the middle. Generally, you wouldn't use a CF application to talk to a Mobile Internet Toolkit Application. In the best of both worlds scenario, it's kind of one or the other, but we cover both ends. You have to draw the line somewhere, to make sure you get the best experience on both sides.

In n-tier applications, you'd have elements that reside on the PDA, but then you'd also have information elements that go up and down. Would you use the compact framework for all of that? Or would you use the Compact Framework to write the PDA-based code, then use MIT for the information that goes up and down.
Here's a common scenario where you could use the Compact Framework for everything. Say you have somebody working in a factory where they have to move some boxes around. If it's an elaborate setup, they might use a barcode system to keep track of what boxes belong where. And they might have direct connectivity, or they might not. So if they're walking around this warehouse, and the connection is intermittent, they might have information going up and down between the PDA and a server somewhere. You can't rely on something server-based, so you need to allow for an offline user experience.

As I've said, in that kind of situation you can do everything you want on the Compact Framework. You have the offline development scenario. Then, for the up-and-down side, when you connect to a server, you can use XML Web services or ADO.NET—or really anything you'd use in the desktop model. As for the development paradigm, the majority of classes and structures you'd expect for desktop development are available in the Compact Framework.

That leads to my next question: What are some of the major differences between programming with .NET for the desktop and .NET for a portable device?
There are two sides to that—the Mobile Internet Toolkit server-side development model and the .NET Compact Framework client-side model. They both have slight differences. For the server model in the MIT, there are no limitations on what a developer can do versus a desktop Web application, except in the presentation layer—i.e., the targeted device's browser might not have as much richness as a desktop machine's browser.

In such scenarios you have access to everything on the server and everything in the .NET framework. So, really, the development model is exactly the same when it comes to data access, to Web services, to everything you might want to use in the way of server-side assets. When you go to scale down to the device, though, you could see some limitations.

On the client-side model with the .NET Compact Framework, it's almost the exact same practice as on the desktop. VS.NET developers (using VB.NET or C#) will be able to use their desktop skills to build CF applications. The only real limitations stem from the fact that the devices themselves support a subset of the basic Windows functionality a developer might be used to. You have resource constraints and size constraints on a device. Also, we carved some things out of the desktop framework when we built the CF, such as a Web server. Generally, you're not likely to have a Web server on your PocketPC.

Let's talk about functionality. What can't I do on a PocketPC that I might expect to do on a desktop machine?
At this point, when it comes down to the majority of client applications you'd build, you might have the same thing on a portable device—that includes Web services, consumers of data, and consumers of other assets such as an email system. When you ask about things you can't do, the limitations on building a consumer application from a client perspective really aren't there, unless you're talking about things affected by the device's limited processing power. For example, OpenGL on a portable device is not a high priority at this point.

What sort of data support will the next generation of PocketPC's include?
ADO.NET is part of the compact framework. So you're able to use the same ADO.NET development practices. Here your desktop skills port straight across to the CF.

And will there be a version of SQL Server CE?
Yes. The best use of this database is for offline scenarios, to persist data for an application when you don't have connectivity to the master database. In this case, you can persist the app's information on the device to this lightweight engine, then synch up at the end of the day. A lot of this happens on the SQL Server side because many of the connectivity issues involve connecting to the on-device database. And the synching between device database and master database is handled on the engine side, so that doesn't require extra work on the part of developers.

One of the dangers with a PDA is that it's a pretty easy device to lose. What sort of security features exist to protect the data on a PDA in case it's lost or stolen?
I'm not an expert in terms of what's built into the PocketPC directly. But as for Compact Framework, if you're building a device application and there's a chance that the device could be lost or stolen, it might be a good practice for developers to have some sort of log-in method or security built into the app. As far as I'm aware, there isn't any built-in way to turn it off remotely or remove functionality from the device. It's one of those things where it's a risk either way.

An even more serious issue is the notion of hackers intercepting information beaming up from or down to a device. Is there anything built into the MIT or CF to make mobile transmissions safer or more secure for those who depend on them?
From the CF side, we have encryption libraries on the device, so you can use RSA and other encryption standards to enable safe data transport to or from a device. As for the MIT, it depends on the target device. Every device has its own capabilities regarding encryption support. Since it's a server-side model, it's not difficult to build applications that use server-side secure sockets, for example, but we're really at the mercy of the devices that are out there. As hardware manufacturers improve the security of their devices, we'll definitely include support for that in the MIT.

What is the current status of the MIT?
The MIT released with VS.NET. However, it wasn't part of the box, but is rather a separate download. Just go to the MSDN Web site at msdn.microsoft.com/vstudio/device. This page includes a link to download the MIT. As we move forward, it will be part of the VS.NET installation. The difference between desktop, server, and device applications will be completely transparent.

Similarly, what is the current status of the CF?
There are two sides to the CF. There's the .NET CF, which is a platform. And then there are the Smart Device Extensions to VS.NET. They all ship as part of the same package. We went into beta a few weeks ago. One installation puts the CF on your desktop development machine. The Smart Device Extensions add in project types for smart devices for VB.NET or C#. That includes support for libraries that are available on the device, so you can develop against them. It also has awareness of the CF, so it warns you if you try to add a reference that isn't available. It also comes with an emulation mode so you can build applications for a device without having the device actually present.

What role does XML play in either the MIT or the CF?
Microsoft has built everything around an XML core. XML is built into ADO.NET and our Web services model. Broad XML support is found throughout our products. In the case of the CF, you can build XML-rich apps, whether through flat XML files, XML-based ADO access, or XML Web services. There's no extra work required for using XML on the CF. There's even a black box scenario where you don't have to understand how XML works or what it does in order to use it in every application.

It is now possible to build Web apps in Windows with VS.NET that target other platforms through a browser, using a combination of ASP, XML, and HTML. How far are we from seeing similar capabilities for targeting portable devices?
It's here now with the MIT. We currently support around 140 devices. You can build apps requiring connectivity with a cell phone or PDA or custom device, as long as this device supports HTML, CHTML, WML, or a similar standard. You can send information to such devices with the MIT. This is our broad-reach, all-encompassing effort to make sure every device out there can be targeted with VS.NET.

When can we expect to see PocketPC devices that ship with the .NET runtime?
The CF will be released later this year. It's not that far down the road. I don't know how long it will take from the release date to when we can get the runtime on devices, but it's going to be a fast turnaround. We've got vendors chomping at the bit. The answer that we're going to ship it when it's ready isn't good enough for some of these guys. We answer to developers—that's what it comes down to. We work hard to make sure the vendors are happy, but when it comes down to it, the more successful we make developers, the better it is for us.

Correct me if I'm wrong, but SmartPhone cell phone will ship with the .NET runtime included, right?
In the first release, version 1, SmartPhone will not have the compact framework. We really want to get the devices out there, and we don't want to compromise the quality of our CF build to get it included in the timeframe of the first SmartPhones ship date. We're going to have the phones out there before we have the CF available. However, the 1.1 release of SmartPhones should involve the CF.

There appears to be a lot of momentum for Java-enabling cell phones. For example, Nokkia, Sony-Ericsson, Siemens, and Motorola have all announced Java-based cell phones. Why should developers use Microsoft's SmartPhone/MIT technology instead? Are there even devices or a market for Visual Studio developers to target?
One of the advantages of using VS.NET with the MIT is that we're not really tied to anything on the device. Everything is server-side, projected to the device. There's no runtime to worry about. On the other side, in many cases there's a difference between specification and implementation. For example, Java Web services aren't really part of the specification.

I'm not trying to say they don't have Web services because there are vendors out there in Java who are pushing Web services. But it's kind of fragmented at this point, because there's no standard for them, and different vendors are following their own path.

Right now, building rich-client device applications is a gamble for a lot developers. I mean, who's to say what the final Java Web services standard is going to be? You're building applications today that may not be what's going to be used a year down the road. You might have to redeploy all these applications to all these millions of phones that are supposed to be out there. At this point, as I understand it, there's been some exaggeration in numbers, but that's neither here nor there.

What we're looking to provide with the MIT is an extensible model on the server side that projects a UI to the devices. Building an app with the MIT enables you to build an application once, now; it then renders adaptively at runtime to adapt to whatever browser/device combination makes the request. We have a real advantage here because the MIT runtime lives on the server. Companies that are out there building applications can continue to install our device packs as we release them. And as more and more devices come out, companies won't have to go back and recode their apps to be compatible with the new devices that become available.

Ed Kaim
Ed Kaim is the Mobility Product Manager in the .NET Developer Solutions division at Microsoft. As Product Manager, Ed is responsible for driving the feature development and evangelism of the Smart Device Extensions, the Mobile Internet Toolkit, and the Microsoft .NET Platform at large. Prior to joining Microsoft, Ed founded SharpLogic Software