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

Factoring of Useful Design and Debugging Information into Optional Components

Managed code can contain a great deal of information useful for developers debugging their frameworks, components, and applications. An example of this kind of value-adding data is the text descriptions of exceptions that can occur during code execution. It is one thing to get an error message such as "Unknown exception occurred" or "Exception System.IO.SomeRandomException was thrown" and quite another to get a detailed human-readable error message describing what went wrong and what the probable cause was. This data is helpful to have when testing and debugging, but storing all the error strings for a large programming framework such as the .NET Compact Framework can take up a large amount of space and be prohibitively expensive for mobile devices.

The desktop .NET Framework simply includes this kind of rich exception information along with other resources. Not only is this information available in English, it is localized into all the principal languages that Visual Studio is localized into; this means that end users can be presented rich diagnostic information in their own language when appropriate. To allow access to this information programmatically, each managed code exception has a .Message property that allows programmatic access to this text.

Having rich debug strings is certainly a benefit; however, this benefit comes at a size cost. By definition, verbose text descriptions take up space. Even more space is taken up when this text is localized. Hence a design constraint is raised; compact size and rich textual error information are conflicting design goals.

The .NET Compact Framework solves this problem by cleaving this information into separate satellite components that are not a core part of the .NET Compact Framework. These satellite components can be installed on top of .NET Compact Framework as needed or desired. The file containing this information is called System.SR.dll and it is about 91KB in size. Additional versions of this file exist for other localized languages. Presently 10 localized language versions of this file exist, amounting to more than 900KB of data, which is a sizable fraction of the .NET Compact Framework's size. Therefore, removing these strings from the .NET Compact Framework resulted in a significant size savings.

Devices with the .NET Compact Framework installed on them in RAM or ROM will typically not have these satellite files installed; instead, they are optionally installed as needed or desired. The Visual Studio .NET development environment will automatically install them at debug time because developers will almost always want these present.

At runtime when an exception is thrown the .NET Compact Framework looks to see whether the appropriate language-exception string file is present on the device. If it is, the file is accessed and the appropriate exception description is loaded. Failing this, the .NET Compact Framework looks to see whether a language-invariant (English) exception string resource file is present. If it is, the text is loaded. Failing this, default text is displayed that is not specific to the error (although the exception's programmatic name may give some idea as to what the error was).

Through the mechanism of using optional satellite components, a good balance was achieved in the .NET Compact Framework of needing to be as small as possible but still provide developers with rich debug information.

A similar design strategy is employed where components benefit from extra design-time information that is not needed at runtime. When building custom controls, it is possible to build separate design and runtime versions of the components with the design-time versions containing additional meta data that is interpreted by the development tool to provide a richer design-time experience.

For your designs, you might want to consider similar models of having optional resource files or having separate design-time versions of your components if significant size savings can be achieved.