Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Designing the .NET Compact Framework

Every successful engineering effort needs an underlying set of goals to guide its design. It would be pleasing but incorrect to say that the design goals of the .NET Compact Framework sprung out of one mind complete from the start. The design goals for the .NET Compact Framework evolved through the spirited arguments and passionately held beliefs of the core members of the tools and runtime team. Some held that achieving absolute minimum size was the most important. Some thought cross-platform capability sat at the top of the list. Some thought building enterprise data-centric applications for the Pocket PC was the key to success in the marketplace. These ideas were explored and weighed against one another and as early as possible tried out with a target audience of developers through a series of early hands-on labs. With external developers building real mobile applications on our early bits in these labs, we learned an incredible amount about what was important, compelling, and necessary for mobile device runtimes. This feedback guided us through the first half of our multiyear development process, and we are grateful for the invaluable real-world input that our early adopters gave us. Using this feedback we were able to refine, iterate, and distill the design principals that were to guide the project to completion. The goals agreed upon, the second half of the development process was about putting these into practice, refining them when necessary, and iterating on the product to balance the competing design requirements of size, performance, and features. The end result, the .NET Compact Framework v1.1, we feel very good about. This process of iterative design is extremely important for mobile devices for the simple reason that devices represent a less-understood domain than either desktop or server development does. Mobile devices as flexible application platforms are relatively new, and people are feeling their way around in the early light of a new day; iteration guided by feedback is essential. The subject of how to adopt an iterative design process is a recurrent theme throughout this book.

In approximate order of importance, the following were the key goals in the design of the first version of the .NET Compact Framework:

To be a binary compatible, standards-implementing, subset of the desktop and server .NET Framework.
A great deal of engineering effort went into design of the desktop and server .NET Framework, and it would be foolish to not leverage these efforts. In addition, the core of this work has been submitted to and approved by standards bodies (ECMA-334 and ECMA-335, ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI), and ISO/IEC 23272), including the binary format for compiled applications (IL), the C# programming language, and the base class libraries of the programming framework. It was an explicit goal of the .NET Compact Framework to implement these standards and with that make use of the existing .NET language compilers. The ability to use the highly tested and already proven C# and VB.NET compilers to build applications for the .NET Compact Framework as well as the ability to leverage a large number of design, testing, and debugging tools already available for desktop and server development was a significant engineering efficiency and reliability improvement above building a new and custom implementation of these.

Cross-platform capability.
Although the first implementations of the .NET Compact Framework are for Pocket PC, Windows CE, and the Microsoft Smartphone operating systems, the .NET Compact Framework itself was designed to be able to be ported to other platforms if and when a compelling case exists to do so. One example of the practical implications of this design decision is the fact that all calls from the .NET Compact Framework that touch the underlying operating system are made through a single interface known as "the PAL" (platform abstraction layer). Doing so ensured a clear design understanding of underlying operating system dependencies and makes porting the runtime and libraries to another operating system a well-understood task. This is not to say that porting to any operating system would be trivial, only that this was thought of in the design of the .NET Compact Framework. For example, some operating systems may not inherently support operating system functionality that the PAL maps to, requiring the PAL for that platform to implement things such as threading, memory management, graphics, or other functionality missing from the target operating system. This can be a significant task, but it is a well-understood and tested process that was accounted for in the design process of the .NET Compact Framework.

Rich client capability, including support for drawing and forms, being a Web services client, and having a rich data-access model.
We came to the conclusion that to be compelling a device runtime had to meet a few key criteria for application builders: It had to allow the building of rich user interfaces with the modern controls that developers expect (for example, grids, list views, and tree views). It had to allow applications to consume Web services as easily as desktop .NET applications could (that is, trivially). It had to provide a rich, modern, and extensible model for dealing with database data (ADO.NET). Support for all of these was implemented in the object library of the .NET Compact Framework.

Small on-device memory and storage footprint.
Our on-device footprint had to be smaller than 2MB of storage in order to become a practical option for getting into mass-market devices' ROM images. Being adopted into the common ROM image of mass-market devices was seen as important to being an integral part of the mobile devices' platform. To aid in adoption, it was also important to be able to be installed into the RAM file systems of existing devices while leaving plenty of room for applications and data. Both goals required a sub-2MB footprint on devices. In addition, the .NET Compact Framework needed to be able to operate in highly RAM-constrained environments. These goals are significantly different from the desktop and server .NET Framework, which runs in a comparatively unconstrained environment and prioritizes the goal of maximum total performance throughput higher than absolute size efficiency.

Prove support for at least two .NET languages, C# and Visual Basic .NET.
Although in theory any programming language that targeted the .NET Compact Framework's (ECMA and ISO) standardized subset of IL byte codes and set of programming libraries should be able to compile to run on the .NET Compact Framework, this needed to be proven by an actual multilanguage implementation. We chose C# and Visual Basic .NET because they are the most popular .NET languages. As with the desktop/server implementation, this meant including a version of the Microsoft.VisualBasic.DLL runtime library in the .NET Compact Framework.

Be a suitable replacement for native code for most kinds of business, scientific, productivity, and entertainment applications.
It was important that desktop and server developers felt comfortable and syntactically unconstrained when developing on the .NET Compact Framework. If this goal was not achieved, the platform would not attract the large number of desktop and server developers to the platform that we hoped to. This lesson had been learned from previous device runtime efforts that had not achieved "critical mass." Both Microsoft's Embedded Visual Basic and others' efforts historically fell short because they lacked key features developers commonly use when building desktop and sever software or use in native code development for devices. We believed any successful successor to native code development needed support for the following:

Floating-point mathematics, trigonometric, and transcendental functions
Coming from a desktop and server perspective, these seem like obvious things to include, but from a device perspective it was by no means clear at the outset. For size, cost, and power-consumption reasons, many mobile device processors do not have built-in support for floating-point mathematics. Instead, this functionality is provided by software libraries running on top of the processors. We came to the conclusion that although most algorithms are integer based, for applications of any real-world complexity there are almost always cases where some kind of decimal mathematics is required. Looking at what was required to do financial calculations (for example, interest payments or drawing graphs), scientific calculations, or even calculations in games led us to the belief that floating-point math support was a requirement for building a successful mobile device managed-code successor to native code.

All of the basic mechanics of the programming languages and commonly used programming libraries
We could not remove any modern object-oriented language features such as inheritance or structured exception handling nor could we do without commonly used low-level libraries such as those for file I/O streams. Developers simply expected these to be there as part of the core programming experience, and if they were not there the experience of programming felt hamstrung. Developers needed to feel comfortable and empowered.

Allow access to underlying operating system when necessary.
We realized that as much as cross-platform portability was an important goal, developers should not be limited to only the features we thought to include. We would strive to provide a suitable subset of the desktop .NET Framework to build the kinds of applications developers said they wanted, but there were inevitably going to be cases where developers would need to go outside the bounds of the functionality we provided. It was no good enabling developers to build 90 percent of their mobile device application in managed code if they were stuck because a critical 10 percent was missing. Therefore a suitable way to allow calls into native code was deemed essential to allow developers to work around functionality that was missing in the .NET Compact Framework. Four examples: Presently the explicit management of network connections, the ability to dial the phone, the playing of sounds, and the accessing of cryptography APIs require calls to native code (or calls to third-party libraries that wrap calls to native code); not everyone needs this functionality, but those who do would sorely miss it if they could not call into native code to get to it.