|
VSLive! Speaker Interview—Oshoma Momoh on Mobilizing .NET with the Compact Framework
Microsoft’s providing more than one mobile development solution, isn’t it? We’re trying to make it part of the VS.NET experience that any VS developer can become a mobile device developer. We’re taking two architectural approaches—Web UI and smart client. For the Web UI approach we’re offering a set of ASP.NET mobile controls. This shipped with VS.NET early this year. Originally it was called the Mobile Internet Tool Kit. The controls make it easy to auto-format output for target devices with different form factors and screen resolutions. They also let you make an application smart about what kinds of browsers are being used. That includes the Blackberry, the Palm, and many more. There are more than 140 browsers and devices today. For example, in Europe and Japan a lot of work has been done with WAP phones, and in Japan by NTT DoCoMo Imode phones using Compact HTML. DoCoMo has thousands of developers building apps for Imode phones today. The Japanese have a highly connected telco infrastructure. It’s more successful than WAP in Europe. Certainly the Japanese mobile phone infrastructure has better data rates than anywhere else in the world, and they’ve done a great job with making their technology available to developers. They’ve given ISVs a way to make their apps discoverable, then bill customers through DoCoMo, which has built up a successful community around their phones and HTML. Microsoft’s approach with ASP.NET mobile controls provides an abstraction layer that lets you stay above markup languages. HTML is a great markup language for mobile devices but the space is quite fragmented. The controls take care of rendering in a particular language. The second approach is about the smart client, about taking mobile app development onto richer devices to the next level. We’re getting the compact version of the .NET Framework out there. That’s my role. We’ve been working on it for several years. It will be out later this year. Apps using it will run on a smart client with local code, be able to access data remotely and cache the data locally. So the apps won’t have to deal with Web round trips, network latency and such. Those two approaches are what we’re doing. We want all VS.NET programmers to be able to buy into this mobile revolution and make it part of the regular development process. We haven’t seen much interest in MMIT. There’s strong interest in Europe and Japan for the Mobile Internet Toolkit—just not here in America. How can America become more competitive in its mobile infrastructure? The US needs to get advances in the networking protocols used for phones. We’ve had TDMA and similar technologies that give you 9600 bps on the wire. Data rates in Japan and Europe are four to ten times faster. But because the US is so geographically dispersed it’s going to take time. And certainly the difficult economic times telcos are facing today doesn’t help things. The other side is getting the developer piece of the cycle going. I think developers are looking for easy ways to write apps for these devices, and to extend existing apps. Until devices become capable of running real apps and the platforms get to be powerful enough it’s going to take a while for them to get going. It’s still quite fragmented. Let’s talk about the Compact Framework. Smart clients mean rich clients mean plump clients. How about size? The footprint is 1.5MB for the whole platform, including execution engine, JIT compiler, and class libraries. It’s much more comprehensive than anything we’ve had in the past. How much Windows Forms functionality is there? Quite a significant subset. The CF also supports the Windows Forms Designer. You can use Visual Studio today for drag and drop UI design with the CF. It is a subset of course. We had to remove a lot of helper functions; five ways to do things got shrunk to one to save space. When we released the beta in April we had a chance to get great feedback from developers. One thing people wanted were more controls, such as tree view, date/time selection, and a data grid control—they said loud and clear that it was not OK to take them out. Which languages does the CF support? C# and VB.NET in the first version of the CF. Also, we’ve been working with language researchers and tool vendors. For example. Borland recently announced ’support for the CF with Delphi. Fujitsu will support it with COBOL. And more are on the way. One other obvious question is C++. The CF won’t be supporting it in version 1, but we have embedded C++ today in CE, and C++ will be integrated into CF over the next year or so. How hard is it to migrate projects to the CF? It’s not straightforward from older languages. It’s disjoint from the past. We do have tools for going from VB to VB.NET, and they apply to the CF as well as to the desktop. We’re making the standard set of investments in the developer community: an active newsgroup, sample code, best practices, all coming to help developers bootstrap. How about migrating from previous CE-based development
environments? So mobile app dev is finally ready for VB developers. However, as you touched on earlier, the business market for these devices is going to be more difficult than imagined previously. It will have to involve solid applications, not just employee “perks.” I agree—real apps are important. Looking at the market as a whole, ’both on the hardware side and the development side, we’re getting close to the point of seeing a new cycle kick in. Pocket PC devices have become powerful enough to run real apps. And as we augment the toolset and add .NET, we’ve got a lot of pieces falling in place that will cause enterprises to gravitate towards mobile apps. Companies buy devices to get the apps they want. The Blackberry provides a good example of that. In the ISV space it’s more a question of what’s the biggest addressable market for my app and the best user experience I can get. If the screen has only 100 pixels you can’t do a lot. But a lot of these devices are close to being able to break through that problem. What are the primary apps corporate developers are building today that CF could help with? The first set centers around being able to take enterprise data offline, view and manipulate the data, then come back and sync up. The second class of apps is about accessing Web services as enterprises deploy those over mobile networks such as GPRS. We’ve already seen strong uptake on both. The third set is about manipulation of structured data with XML. And that’s baked into the CF platform. What are the new apps they aren’t building yet that you see them doing with CF? I think a lot will center around network connectivity, using Web services as a way to get to data that they couldn’t reach before. And new messaging type apps. Earlier this year we showed someone using a Pocket PC Phone Edition device for conferencing. Instead of everyone calling into a central number, this app looked in the calendar and at the appropriate time rang up people’s phone numbers, initiating the calls through a mobile operator. That demo was fun to do. We had a number of telco carriers present at the conference. It represents additional data/voice traffic, after all. And developers are excited about ways to plug in new services, about messaging becoming an integral part of apps. Also consider location services. Where am I right now? Show me a map. Where are my friends? Can I drive to them? Carriers have the capability today to tell you where you are and tie that in to MapPoint. Location is one thing, and there are nine or ten different ones. We’ve been working on this for half a year, with messaging, SMS, a lot of different things. Watch some of the bigger names, such as Vodaphone, Orange, and AT&T Wireless—they’re demoing these kinds of things today. One other point that gets the carriers excited is making their existing world of mobile phones more useful, tapping into desktop PCs to use messaging in a carrier network. That’s pretty compelling to them, and we’re on the verge of having new apps come out that do this. We’re also working with carriers to do experiments with voice-enabled apps. What kinds of apps can developers build with the Compact Framework that can’t be built with older Microsoft embedded languages (eVB and eC++) or Java? Web services, richer data access. There are also some aspects that are visible but don’t change how you code, such as garbage collection. GC keeps apps from running too slowly. We use a JIT compiler to get around the resource limitations of mobile apps. Also when we ship the CF we’ll support existing PPC 2000, PPC 2002 devices including phone edition devices, along with Windows CE.NET 4.1 and higher. We can take advantage of both new devices and ones that are out there today. However, we’ve done a better job on some of our platforms and tools than on others. It’s something I’m pretty conscious of. How has the garbage collector been modified to work on low memory devices? How will this affect developers in building their applications, and what should they know about the GC tuning that has been implemented? From the developer perspective it’s transparent. You don’t have to worry about GC. We went about it pretty carefully in terms of architecting the GC internally to consume much less memory, to keep RAM consumption low. All memory allocations come from a single pool or heap, so if the device runs low on memory it’s easy to free some up. A JIT process can apply pressure to the pool and release memory from it and keep the app running. We also do some tricks. For example, when you switch an app into the background we free up all garbage objects, JITting code to make room for the foreground app. The background apps are still runnable but mostly they become quiet. We take advantage of that. The semantics are exactly the same as the desktop version but we’ve optimized for lower RAM usage instead of speed and scalability. What kind of support do you envision for COM interop with this framework? We actually have good support today for interop between managed code and native code. We use PInvoke to drill down to any native API you want. We don’t have the .NET Framework’s full range of COM Interop support, in part due to space/RAM resource constraints. But there isn’t a lot of demand for native API drilldown on devices today. We target things like the Pocket Outlook application, which has a COM object model—that’s a common developer request: C#/VB.NET access to the Pocket Outlook object model. So we’ll keep providing rifle-shot interop solutions where we see a strong demand, and keep improving support for managed code-unmanaged code interop. On the other hand, clearly you don’t want interop at the price of robustness. So we provide type safety built in. This lets you do strongly typed manipulation of data. We’ve also done lot of work on robustness and manageability of code. There’s mobile data access support through
SQL Server CE, Remote Data Access scenarios with SQL Server
2000, and Web services in the Compact Framework. Which of
these is going to have the most impact for developers? How
necessary is SQL Server CE in an XML-driven world these days? Much has been made of the performance improvements in the Compact Framework from the technical preview up until the present time. How do you feel about the performance at this time, and is the performance of the product meeting or exceeding the expectations of the developers you’’ve talked to? We did a technology preview last fall, then got the beta in April. During that time we improved performance incrementally across the board; in some cases by as much as a factor of 10. Now we’re often close to native apps in speed. Doing JIT compilation definitely has been a good choice for us in getting close to native speed. What are the other key differences between the Compact Framework and the full .NET Framework that developers need to consider? Where will the product be headed beyond version 1.0? In VS, Intellisense shows you what is/isn’t supported. But it’s too early for details. We’ll go towards some obvious things we wanted in Version One—especially native managed interop performance. And we’re responding to key customer requests. Is the CF going to follow the backwards compatibility rules Windows follows, or will it break old apps, as every new version CE has done? The CF is a layer on top of the OS that doesn’t affect the compatibility of existing apps. Why should developers care about the Compact Framework when there is no established base of devices yet? Is anyone shipping a device with the Compact Framework installed? The CF doesn’t have to be deployed in ROM. It can work on existing devices, including PPC and CE.NET devices. So we do have a pretty large addressable market already. Are mobile device sales increasing? I’ve heard they’re actually slowing, at least in some areas, with few device wins for the Microsoft Smart Phone edition, and not many enterprise apps running on the Palm PCs. We’re not seeing that. With PPC we have more than 30 manufacturers signed on. On the PPC side it’s up by about 40% over the course of the last year, which is good in an overall down mkt. We also are seeing it on the developer side. We have about 5,000 people in our mobile solutions partner program, and more than 10,000 ISV apps. We’re also seeing carriers step up to the plate, with recent announcements from Cingular, Memo2, and Sprint around various mobile devices. I see good momentum in general. A number of devices are nearing an inflection point where the mobile hardware is good enough to run these apps. Check out the www.handango.com site. It’s he biggest online retailer for mobile apps in general, including PPC, CE, and Palm. If you browse their site you get a pretty good idea about the kinds of apps being built and what’s being targeted. Does the Compact Framework run on HPCs? Handheld PCs use a specific form factor devices that preceded PPCs. They have a ider keyboard. Unfortunatelye don’t go that far back. Our first version just supports current and new devices. Won’t the new Tablet PC eliminate many of the reasons to develop enterprise applications on the Compact Framework? Many apps require a user to be standing up, which makes a tablet PC much more user-friendly than a laptop that needs to be placed on a surface to type on. I hear that NEC is getting a lot more calls about the Tablet PC lately and almost none about Windows CE OS-based devices. Tablet PCs may rejuvenate the laptop market, and there may be apps people want to do on a tablet PC instead of a pocket PC. But I think it’ll just help drive the whole thing. ’It will be as easy to write a Table PC app as a PPC app. There’s no friction there for developers. For enterprises that have built apps for the Windows CE devices in the past, why would they move to the Compact Framework? If you do an app in eVC++, why would you rewrite that app in C#? And, wouldn’t you resent the 1MB you lose by putting the Compact Framework’s runtime on your machine?) It’s more a question of how you choose to write new code. There you’ll see a substantial increase in developer productivity, ability to use XML Web services, and generally the best of VS.NET. Since Palm still has a majority of the installed base of handheld PCs, aren’t developers choosing solutions that will let them build apps for both Palm and PocketPC platforms? \Some people may want to but if you look at Handango.com, you’ll see that ISVs are generally choosing to target one device or the other for its feature set. : It’s a Venn diagram with some overlap, and there’s a space around the enterprise that the PPC is going gangbusters in—especially high performance apps that require real horsepower. That does drive choice. When will the Compact Framework take full advantage
of the new XScale Processor?
Oshoma Momoh |
