26.2 Creating a Smart Device Solution

You want to create a new solution that targets mobile devices.

Technique

When you open the New Project dialog in Visual Studio .NET, you see two project templates specifically designed for Smart Device Applications. The one we're interested in for this recipe is the Smart Device Application template. When you create the project, the first screen you see is the Smart Device Application Wizard. This wizard allows you to choose which type of Smart Device Application to create, given four choices. For a graphics Windows-Form “based application, select the Windows Application project type. The Class Library project allows you to create DLL assemblies containing custom data types, and it is similar to the class library project created in the .NET Framework. The next project type is the Nongraphical Application. This type of project is specific to the .NET Framework (although creating a similar type of application in .NET is trivial). Mobile devices do not have a console, as does the Windows operating system, which means EXE-based applications use Windows Forms or run in the background. The last project type is an Empty Project. This type simply creates the necessary project properties for a Smart Device Application, allowing you to add source code as necessary.

Comments

If you're thinking that you will never target a mobile device because you don't have the necessary hardware such as a Pocket PC, you'll find it comforting to know that you don't have to. Ever since the first mobile SDK for Windows CE, Microsoft has shipped with it an emulator that runs within a window on your desktop system. For most applications, ensuring that your application runs within the emulator gets you pretty close to making it work on a real device. We're not saying that you should just create an entire application and ship it once it's finished and working within an emulator. Sometimes, the behavior from the emulator is not quite the same as that from a real device. Additionally, not all devices use the same processor chip, which means you can encounter different behavior when the intermediate language (IL) is generated to machine code. For instance, MIPS processors do not support the full range of values necessary for floating-point precision. While you are running the emulator, the IL is generated to x86 machine code where floating point behaves as expected. Once you place the application on a device with a MIPS processor, you'll find out the floating-point emulation is not a supported feature in the .NET Compact Framework for those devices. So in short, become good friends with that guy holding the iPaq you see on the bus.