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

The Managed-Code Libraries

The managed-code libraries of the .NET Compact Framework are the programmatic part that developers interact with. As with the desktop .NET Framework, the .NET Compact Framework libraries are factored into a series of DLL files. The libraries are present at design time on desktop computers and also installed on the target devices for runtime use. These DLLs have design time filenames such as System.DLL, System.Windows.Forms.DLL, and System.Xml.DLL. The on-device filenames may differ due to naming and versioning needs on the target devices. During compilation, the managed-code libraries are used the same way header files are used by C/C++ or type libraries are used by older (VB6 and earlier) Visual Basic code to give knowledge of the interfaces and types being used by the code being compiled. The fact that these files share the same *.DLL file extension as C/C++ native code libraries is for familiar file-naming purposes only; the binary content is very different, and they could just as easily be named with other file extensions. The fact that the .NET Compact Framework filenames also generally match the filenames of desktop .NET Framework assemblies is also for the user's convenience only. In fact they could be refactored into more files or combined into a single file if necessary. A future implementation on a non-Windows platform may choose to do this if it is beneficial to do so. Your application generally does not need to worry about this implementation detail because it is the runtime's task to find, load, and manage common libraries present on a device.

From a programmatic perspective, each of these DLLs exposes a set of hierarchical namespaces to the developer containing classes and types. Example namespaces containing classes and types are System.*, System.Xml.*, System.Data.*, System.Drawing.*, and so on. There is a many-to-many relationship between DLLs and namespaces; a DLL can contribute to multiple namespaces (for example, Foo.DLL can contain types in both MyNamespace.* and SomeOtherNameSpace.SomethingElse.* if it wants), and multiple DLLs can contribute to the same namespaces (for example, Foo.DLL and Bar.DLL can both contribute types to MyNamespace.* and SomeOtherNameSpace.SomethingElse.* if they want). When an application is compiled, the compiler is told the set of files it should look into to find classes and types the user is trying to use in his application; these are commonly known as references. If a type/method/property is not found in the developer's code or the referenced libraries, a compilation error is generated. Additionally, if multiple versions of types are found in different DLLs, an ambiguous type compilation error is generated.

Other than at compile time when the compiler is given a list of files to look into for referenced classes, developers need not worry about which classes reside in which files. Instead, developers should think only of the logical hierarchy of namespaces they are using and generally not worry about which of the referenced files contains any specific type.

The Base Class Libraries

The base classes are the nuts and bolts of programming. They include the common types and functionality that developers use to implement most data-processing algorithms. The base classes include the following:

All the core types such as integers, strings, floating point, date/time, arrays and collections.

File I/O, streams, sockets networking.

The capability to look up and bind to the types, methods, properties in assemblies at runtime. This is known as reflection.

The capability to work with culture/locale-specific information. This is known as globalization.

The functionality above along with additional base classes is encapsulated in the following hierarchical namespaces:

System.*

System.Collections.*

System.ComponentModel.*

System.Diagnostics.Globalization.*

System.IO.*

System.Net.Sockets.*

System.Security.*

System.Text.*

System.Threading.*

User Interface Libraries

The user interface libraries were created with two goals in mind: (1) to enable developers to build rich enterprise applications using modern high-level user interface controls such as Buttons, PictureBoxes, ListViews, TreeViews, TabControls, and so on; and (2) to enable developers to perform low-level drawing operations on mobile devices using rich bitmap operations with the ability to draw two-dimensional objects such as lines, polygons, text, and images.

This functionality is offered in two hierarchical namespaces:

System.Drawing.*
Two-dimensional drawing capability

System.Windows.*
User interface controls and supporting functionality

Web Services Client Libraries

Web services are a standards-based way to communicate between applications running on different platforms. In a nutshell, a Web service server is a Web server that exposes programmatic interfaces to applications that can be accessed using XML as the language of conversation. The syntax of this XML conversation is SOAP, which stands for Simple Object Access Protocol. A Web service client is an application that can call to make SOAP requests of Web service servers and interpret the SOAP responses sent back. To describe the interfaces being exposed, Web service servers return WSDL documents on request. WSDL stands for Web Service Description Language, and like SOAP it is a syntax built on top of XML. WSDL describes the programmatic interface the Web service exposes; SOAP is used to make requests of those interfaces.

A key feature of the desktop and server .NET Framework as well as the Visual Studio .NET development tool is the easy ability to create and consume Web services. Visual Studio .NET is capable of parsing a server-generated WSDL document and generating a set of easy-to-use client proxy classes that enable developers to access the Web service. Because of these proxy classes, calling a Web service is conceptually as easy as creating an object and calling a method on it.

It was a specific design goal of the .NET Compact Framework to support a rich enough set of classes, properties, and methods to compile these Visual Studio .NET autogenerated client proxy classes. This goal was successfully met, and mobile device applications can just as easily be Web service clients as their desktop and server counterparts.

This functionality is present in the System.Net.* namespace.

XML Libraries

Why is XML so important? To understand this, it is necessary to understand the pros and cons of the two basic ways to exchange data between applications, namely via binary formats and via text formats.

Binary data exchange demands a strict contract between all parties on how to format and interpret data. Binary formats require careful planning for their version management by all parties using the formats. This reduces flexibility; a change to a binary format that all parties do not agree to will break applications that use that data. In compensation for this drawback, binary data offers the potential for the most compact representation. This brings with it savings in size and increased processing speed.

Text files have traditionally offered the opposite proposition: interoperability through a looser contract and more verbose encoding format. For many uses, XML has replaced the traditional text file as the way to store and exchange simple data. XML files are text files but they are text files that include some definition of their structure. This allows them to be easily processed in standard ways and allows for better reuse. Developers choose text formats because they are easier to work withthey allow the exchange of data in a format that is more forgiving to schema changes and versioning needs. XML takes text storage to a new level.

XML offers a useful middle ground between too much structure and too little. This semistructured storage is a substantial improvement over generic text files. Data is stored in a hierarchical text format using tags to provide hints as to the data contained. For example, font information may be stored via the text <Font> xxx </Font>, which allows an application interpreting the text to easily discern what this data item is about. Applications working with XML data can choose only the text portions they are interested in or understand. XML is thus an important incremental improvement over previous text formats such as *.INI files, PropertyBags, an138 text because it provides both increased structure and flexibility.

Because XML has become such a popular medium of information exchange, XML support is important for any modern programming framework. Without it each developer would be left to write his or her own set of functions for parsing text files and extracting or writing the data he or she needs. This solution is fraught with inefficiency and has great potential for introducing unneeded bugs into applications. Because most developers are building applications and not XML parsers, a custom implementation will usually do only what is minimally required and is almost always not tested exhaustively. Moreover, a custom implementation will almost always trade off maximum performance for lower development time. In summary, custom implementations tend to be less reliable and less efficient than a well-engineered solution intended for broad reuse.

It is therefore highly preferable to use prebuilt and rigorously tested XML libraries for reading and writing XML data. These have the benefit of being designed, built, and tested by a group of people whose main goal was to build the fastest and most reliable XML engine they knew how to.

The .NET Compact Framework offers a two-layered approach for working with XML:

Forward only XML readers and writers
The XmlReader and XmlWriter classes serve the need for maximum performance, forward only, noncached XML reading and writing. The goal of these readers and writers is to maintain as little state as necessary while reading or writing XML from and to streams. For developers working with larger-sized XML documents and needing the maximum performance, these will be the option of choice.

XML DOM (Document Object Model)
The XmlDocument class is used to represent an in-memory tree of objects describing an XML document. The XmlDocument and its associated classes represent a Document Object Model intended to allow easy access to members of the represented XML tree. XML is read in by the forward-only XmlReader discussed above and used to build a representative XML tree in memory. Similarly, an XML tree can be written out to a stream; this uses the XmlWriter to accomplish the task. Developers working with small to moderate-size XML documents or wanting minimum complexity when working with XML will choose the XmlDocument class.

Conceptually, this functionality can be thought of as being present in the System.Xml.* namespace.

Data Libraries

Modern databases store data in sets of related tables. The .NET Framework offers an object model called ADO.NET to work with this kind of relational data. ADO.NET gives the developer classes to manage a set of related relational tables in memory along with classes to provide views onto this data. Data managed using ADO.NET is referred to as being in a DataSet.

Developers work with relational DataSets in memory and can do a number of things with that data, including the following:

Persist changes to databases
A DataAdapter class exists to interface between ADO.NET DataSets and databases. DataAdapter classes take the list of additions, updates, and deletes made to a DataSet and apply the appropriate logic to propagate them to the underlying database. Typically this is done by executing SQL statements or calling stored procedures that work on the database.

Persist as XML
DataSets can serialize themselves into XML to be stored to a file and later reloaded.

Send to another tier
Because DataSets, including information about the changes made to them, can easily be persisted as XML, they can easily be passed between computing tiers via Web service calls.

Local use
DataSets can be used as a powerful abstraction for working with relational data in memory. If this data is treated as read-only, changes made to it locally are not propagated back to any server or long-term storage.