Development | .NET Compact Framework

Interview with Microsoft's .NET Compact Framework Technical Evangelist
Written by Robert Levy  [author's bio]  [read 32662 times]
Edited by Derek

      

Page 1  Page 2 

Robert Levy: First off, I'd like to thank you for taking the time to speak with us and participate in this interview. As the ".NET Compact Framework Technical Evangelist" what exactly is your role within Microsoft? What services are you able to provide to software developers?

Kent Sharkey: The Technical Evangelist role is always good for a smile. There aren't too many companies willing to call people that. Basically, our role is to go forth into the community to introduce developers to technologies that aren't shipping yet. We are the advance scouts, if you will, preparing people for changes to come.

RL: In your own words, how would you define the goals and strategy Microsoft is using to merge existing (and future) mobile technology with the larger concept of ".NET"?

KS: Good one. If you think of the overall goal of .NET as helping programs (and people) to communicate better it becomes clearer. Today, and in the past, this has been fairly difficult in the mobile space. People needed to be mobile experts, and used primitive tools to craft apps for Pocket PC or phones. Microsoft is attempting to make this easier for developers, and to enable new forms of applications by doing this.

RL: More specifically, how would you define the .NET Compact Framework and Microsoft's goals in developing it?

KS: The .NET Compact Framework is a lightweight version of the .NET Framework, designed to work well with resource constrained devices. The execution engine and garbage collection has been tightened up, to help with devices where overall memory is still measured in MB. In addition, our support for important standards on the device, such as XML and SOAP support, as well as strong database support with SQL CE are a first in the industry. (well, maybe not the strong database support, but hopefully you're with me) What the .NET Compact Framework is doing is giving developers a set of tools that span devices through servers with a single, consistent programming model.

RL: The .NET Compact Framework and Mobile Internet Toolkit are 2 opposing Microsoft technologies that can be used to develop mobile applications with .NET. Generally speaking, what types of applications do you see as best suited for each of these? What are the key differences between them in terms of development tools, programming techniques, development costs, deployment procedures, and end-user experiences.

KS: I wouldn't say that they were opposing, but complementary. Think of them as the device analogs of Windows Forms (.NET Compact Framework) and Web Forms (MMIT). They both have their place, and optimal usage model. In the case of MMIT, the idea is really reach -- MMIT is great for moving your web applications out to a wide variety of devices, phones, etc. It is a great extension to the ASP.NET model. It's problem is the types of devices it typically targets -- cell phones. They typically have poor data entry capabilities. As such, I would say that MMIT is best for apps that don't require a good deal of data entry, and where the amount of data displayed is relatively small (again, due to phone limitations). Finally, MMIT is best suited for always online applications. .NET Compact Framework, on the other hand, brings a few neat items to the table. First up, through either the larger memory on the device and/or SQL CE, it has data storage capabilities. Therefore, .NET Compact Framework is great for applications that spend part of 'their life' disconnected. SQL CE replication allows you to merge your data back into SQL Server as needed (when connected). Second, .NET Compact Framework gives you the richer capabilities of the device UI. You can use controls such as TreeView, ListView and (soon), DataGrid in your applications without having to struggle with a cross platform DHTML solution. The application could also be faster, as no return time is required to retrieve data. Finally, the development model of .NET Compact Framework is just the same as that of desktop Windows Forms, allowing a developer to move freely and easily between developing for the device and the desktop. MMIT has a somewhat different programming model, possibly confusing some.

RL: As a "Technical Evangelist" you recruit developers to use emerging technology. When doing this, who is your target audience? In other words, what types of organizations do you see as being the best candidates for quickly adopting the .NET Compact Framework? Who do you predict will be (or currently are) the early adopters of this technology?

KS: I look at the target audience as being in two main groups. First, there are those groups doing device development today. .NET Compact Framework gives this group a rich set of tools and consistency with the desktop that will help their move forward. Second, there are those who have never done device development. This is the very exciting group, as .NET Compact Framework means that they can now extend their existing applications to the device easily. They no longer have to learn a new programming environment, with new tools and languages.

RL: Through your interactions with the developer community, what have you found to be the most compelling reasons given for adopting the .NET Compact Framework? Conversely, what reasons have been given for NOT adopting the technology?

KS: The most compelling reason for me is that it uses the same tool and programming model as you develop on the desktop. The consistency between .NET and the .NET Compact Framework means that you already know how to do most things on the device. You build both in Visual Studio .NET. As for reasons for NOT adopting the technology, well, I'm just the wrong person to ask that. There isn't any.

More seriously, some of the companies I've spoken with have decided not to move to .NET Compact Framework because they are already working with (and happy with) Embedded Visual C++ or Embedded Visual Basic. Particularly for small developer shops, that have already scaled the learning curve to get their code on the device 'the hard way', the added training time does not make economic sense.

RL: What advice can offer for developers who have already created and deployed applications for the Windows CE platform using Embedded Visual Basic and/or Embedded Visual C++? What factors should be considered when deciding between maintaining existing code or rewriting applications with the .NET Compact Framework?

KS: The answer is easier for the Embedded Visual Basic people, so I'll start there.

Many of the eVB customers that I've spoken to have been happy with the product. Others, however, feel that there is a 'glass ceiling' to the product. If you try to do applications that go beyond this barrier, it becomes quite difficult. In addition, the fact that it was limited to VBScript was quite limiting. For these developers, we have only good news. Now, they have the full VB .NET language, with the Compact Framework of classes to create their applications with.

Embedded Visual C++ developers, on the other hand do have a choice to make. If they need absolute control of the device, and they're happy developing with eVC, I often encourage them to continue. Those that want to create Web Services, or otherwise take advantage of the functionality available with the .NET Compact Framework, however, should do more than look at .NET Compact Framework. They will find that C# is an amazingly easy language to learn, and the framework does make doing a lot of stuff very easy.

Next Page 

Back to .NET Compact Framework | [Article Index]