Sharing code: Writing code that applies to both mobile and desktop applications

In the past few years, although developers have been building microsoft®.net Framework client applications for Windows®, many people are unaware that they can also use the same skills and toolset to create applications for Windows mobile®. But Windows Mobile was not widely used in the enterprise at the time, so the need to write custom applications for mobile devices was not significant. Today, to meet a lot of demand, many desktop developers are starting to dabble in mobile development. Unfortunately, although it is fairly easy to share. NET code across platforms, many of these opportunities are not exploited.

Whether the original application is written for Windows or Windows Mobile, there are many reasons why you might be able to share business logic across both platforms. You can migrate to another platform from either platform. If your application is currently running on a portable computer on the ground, running on a mobile device may be a good choice, and vice versa. If your product is similar to a competitor's product, you can take advantage of the competition by extending it to a new platform. An additional benefit is that by writing code that executes on the desktop, you can take advantage of developer tools that cannot be used in smart device projects.

You can use the techniques and principles that are described in this article when you are writing a cross-device code application for a Windows device with different styling (different screen sizes, orientations, touch screens, and so on).

Platform Differences

When I think of the. NET Framework, I think of tools, languages, libraries, and Run-time engines. The differences in these four elements affect the goal of writing Cross-platform code. Fortunately, we are using the same tools for desktop and mobile applications: Visual studio®. For each version of Visual Studio, the Visual Studio for Devices team continues to add new features for device development and ensures that important new desktop development features are also available for mobile device development. (For device development, you need to use Visual Studio version Standard or later.) ）

From a syntactic standpoint, both platforms fully support Visual basic® and C #. But if you plan to use Visual Basic, we need to remind you that Microsoft.VisualBasic.Compatibility assemblies and implicit late binding are not supported. The former is the assembly used for desktop projects migrated from Visual Basic 6.0, and if you follow best practices by enabling Option Strict on in the Visual Basic project, the latter is not an issue. Also realize that managed C + + is not supported (although the same IDE is available for native device projects). Third-party languages can add support for the. NET Compact Framework by referencing the correct assembly and ensuring that its compilers do not generate IL opcode that is not supported by the. NET Compact Framework common Language Runtime (CLR). The IL opcode for the conflict include: JMP, calli, Refanyval, Refanytype, Mkrefany, arglist, Localloc, unaligned, and tail.

It is important to note that although the implementation of the garbage collector and the Just-in-time (JIT) compiler differs from the. NET Framework in the. NET Compact Framework, they still play the same role and provide the same services for managed code.

As with any major programming framework, the. NET Framework comes with a large number of class libraries. The. NET Compact Framework, which consumes only 20% of the resources, implements the 80%-related functionality in the. NET Framework. The main areas that are not included in the. NET Framework are the ASP.net, CLR hosts, code access Security (CAS), binary serialization, Reflection.Emit, and CodeDOM, as compared to the. NET Framework.

Windows Presentation Foundation and Windows Workflow Foundation will soon be unsupported, but Windows Communicati will be available in version 3.5 of the. NET Compact Framework On Foundation's lite version. In version 3.5, LINQ to Objects, LINQ to XML, and LINQ to Datasets will also be supported, but no other LINQ types are supported.

In most cases, however, the problem is not caused by the lack of these large aspects. Typically, the problem is that some of the supported namespaces do not have all the classes you need, and, more importantly, some classes do not have all the members you need. Later, I'll explain some of the workaround.

The opposite is true. That is to say, the. NET Compact Framework is not strictly a subset of the. NET Framework; It actually adds some of its own members. There are four device-specific assemblies: System.Data.SqlServerCe, System.Net.IrDA, Microsoft.WindowsMobile.DirectX, and Microsoft.WindowsCE.Forms.

SqlServerCe contains classes for processing memory databases on devices; IrDA contains classes for infrared programming, directx® for rich graphics, mainly for game programming; Forms has a large number of device-specific GUI classes. In addition to these device-specific assemblies, there are device-specific Windows Mobile APIs that are available for Windows Mobile 5.0 and later, along with the Mobile platform. Later, I'll show you how to deal with classes that exist in one framework that do not exist in another framework.

Of course, the input methods on the desktop and mobile devices are different, so you don't have to worry about keyboard shortcuts, tooltips, etc. on your mobile device. In addition, mobile forms cannot be resized and are always full-screen, which can also affect how you navigate between forms in your application. Finally, the most obvious difference is that the device has a much smaller screen size. To eliminate this impact, it is best not to share the application's UI layer between the two platforms, but rather to create a platform-specific user interface that shares only the business logic.