Chapter 43
Figure 43-8
Selecting one of the Pocket PC 2003 emulators either launches the emulator in a separate window, or, if an instance of that emulator is already running, simply connects to that one. The first time you run your application, you can expect to wait up to 10 minutes for the .NET Compact Framework to be deployed and installed on the device. Don’t be put off, as this only happens once, and the next time you run your application it will be much faster. Between developer sessions you can preserve the state of the emulator by electing to Save State and Exit.
When the emulator loads up, it will appear similar to what is shown in Figure 43-9. The emulators are very similar to the design skins that have been incorporated into Visual Studio 2005. They have a series of functioning buttons and can be rotated to test portrait-to-landscape application resizing. In addition, various options can be configured, such as the size of the RAM and which serial ports are available. It is also possible to share a folder from the host computer so files can easily be transferred between the emulator and the host. These options are all available from the Configure item on the File menu, although some options cannot be configured when the emulator is running.
Device
As mentioned previously, although emulators are a good alternative for a large portion of mobile application development, they are not a complete substitute. In addition to being a more realistic test of how the application will behave, debugging using a real device is much quicker than debugging via the emulator.
Prior to deploying a mobile application, it is essential that you test your application on one or more devices. Ideally you would test your application on every device on the market. This is clearly not a feasible option due to the time and expense involved. A minimum alternative is to identify a single device for each operating system you are planning to support. For example, if you are targeting devices running Windows Mobile 2003 SE and later, then you should test on devices that are running both this operating system and Windows Mobile 5.
Building Device Applications
Figure 43-9
Device Emulator Manager
In the previous version of Visual Studio, building device applications was still quite painful. If you didn’t have your computer set up exactly right, Visual Studio would refuse to talk to the emulator. Unlike debugging on a real device, which made use of ActiveSync, debugging on an emulator used its own communication layer, which was very unreliable. This has been addressed in Visual Studio 2005 with the inclusion of the Device Emulator Manager.
The Device Emulator Manager gives you much better control over the state of emulators installed on your computer. Figure 43-10 shows the Device Emulator Manager with the Pocket PC 2003 SE Emulator running, which is evident from the green play symbol next to the emulator (although the green isn’t visible in the book, of course).
Chapter 43
Figure 43-10
When you run your application from Visual Studio and select to use an emulator, the Device Emulator Manager (DEM) is also started. If you try to close the DEM using the close button it will actually minimize itself into the system tray, as it is useful to have open while you work with the emulators.
Connecting
If an emulator is not currently active (i.e., it appears without an icon beside it), you can start it by selecting Connect from the right-click context menu for that item in the tree. Once the emulator has been started using the emulator, Visual Studio 2005 will use that emulator when you begin to debug your application.
After connecting to a device, the DEM can be used to shut down, reset, or even clear the saved state of the device. Clearing the saved state restores the device to the default state and requires Visual Studio to reinstall the .NET Compact Framework prior to you debugging your application again. However, this might be necessary if you get your device into an invalid state.
Cradling
The only remaining difference between running your application on a real device versus on the emulator is the communication layer involved. As mentioned previously, real devices use ActiveSync to connect to the desktop. The communication layer provided by ActiveSync is not only used by Visual Studio 2005 to debug your application, it can also be the primary channel through which you synchronize data.
The ideal scenario is to have Visual Studio 2005 debug the emulator via the ActiveSync layer. This has been achieved in the latest version of ActiveSync combined with the DEM. From the right-click context menu for a running emulator, you can elect to cradle the device. This launches ActiveSync, which may prompt you to set up a partnership between the device and the host computer. You can either set this up (if you are going to be doing a lot of debugging using the emulator) or just select the guest partnership. Once the partnership has been established, ActiveSync will appear as shown in Figure 43-11, indicating that the device is connected.
Remember that once you have cradled the emulator, it is as if it were a real device at the end of the ActiveSync communication layer. The host cannot tell the difference. As such, when you select which device you want to debug on, you need to select the Pocket PC 2003 device, rather than any of the emulators.
Building Device Applications
Figure 43-11
Project Settings
As you would imagine, there are additional project settings that pertain specifically to device projects. There are only a few, and they mainly pertain to setting additional debugging settings required for device applications. Figure 43-12 shows the Devices tab of the Project Settings window for a device project.
The Target Device field is used to specify the default device when your application is run from within Visual Studio 2005. You can also nominate the output file folder and whether the latest version of the
.NET Compact Framework should be installed as part of the debugging process.
Figure 43-12
Chapter 43
The last part of this tab enables you to sign your application so it can be installed on a provisioned device. Essentially, the provisioning of a device entails installing digital certificates onto the device. This can be used to limit which applications can be installed or run, or even which resources an application can use. Applications that have been signed with one of these certificates will be permitted to run on a provisioned device.
Device Options
It was mentioned earlier in this chapter that some device options can be configured via the Options window, accessible from the Tools menu. There are three nodes under the Device Tools node in the Options window, as shown in Figure 43-13. The General tab controls whether the design skins are applied to forms by default in the designer, and whether you’re prompted with the device selector dialog when debugging an application.
Figure 43-13
Figure 43-13 shows the list of devices available for debugging. To extend this list you need to install either new emulators or an SDK, such as the Windows Mobile 5.0 SDK, which is discussed in the next chapter.
Clicking the Properties button brings up the dialog shown in Figure 43-14, which enables you to finetune the debugging process. For example, you can elect to use either the default DMA Transport layer or the TCP Connect Transport layer that was used previously. In most cases you will not have to modify these settings, as the DMA Transport layer is much quicker to use while debugging your application. However, sometimes you have to connect to an older device that may not support the DMA Transport layer. In these cases you will need to select the TCP Connect Transport option. Alternatively, you may want to provision the emulator to simulate the target devices more closely by providing an XML provisioning file for the Device Emulation Startup Provider to use.
Building Device Applications
Figure 43-14
Summar y
This chapter introduced you to building device applications using Visual Studio 2005. Desktop developers will feel right at home with a familiar environment and all the tools at hand to rapidly build, test, and deploy a mobile application.
The next chapter extends this discussion by looking at some of the new functionality introduced with Windows Mobile 5.0 and describing how you can deploy your application using CAB files and MSI installers.
Advanced Device
Application Programming
Programming for mobile applications is all about optimizing the small form factor, the mobility, and the unique functionality offered by these devices. The previous chapter examined the support available within Visual Studio 2005 for building device applications. This chapter looks at some more advanced techniques for building and deploying mobile applications, including rich support for building data applications, new functionality offered by Windows Mobile 5.0, and deploying your application using CAB files and installers.
Data Source
Support for building data-bound applications in Visual Studio 2005 has been improved across the board. This includes building mobile applications where it is useful to have a portable database that resides on the device. As with other project types, to add a Data Source to your application, select Add New Data Source from the Data Sources window. Select Database as the Data Source Type and you will be prompted to select the database connection to use.
Mobile applications can connect directly to a SQL Server database using the same classes as desktop or web applications. However, this can limit the mobility of such a device, as it will require connectivity to the database to function. A better solution is to right-click on the New Connection button and change the database connection type to point to a SQL Mobile database. By default, this displays the Add Connection dialog for a SQL Server connection. Selecting Change next to the Data Source label enables you to change the connection type to use SQL Server Mobile Edition, as shown in Figure 44-1.
Figure 44-1
Accepting this change prompts you to select the parameters for the SQL Mobile database to connect to. Here you can select either an existing database, as shown in Figure 44-2 (where the Northwind database that ships with Visual Studio 2005 has been selected), or create a new database. If you have an existing database on your mobile device, that can also be selected.
Figure 44-2
If you select a database that is not in the project folder, upon accepting the connection properties you are asked if you want a copy to be made and included in your solution. This is a good idea, as it ensures that you can easily deploy your application without verifying whether the database already exists on the device. For debugging purposes, you can define when the database is deployed with your application. Select the database file that has been added to your solution and use the Copy to Output Directory property to specify whether the database is always copied, never copied, or copied if newer than what is on the device.
Advanced Device Application Programming
When the Data Source is added to the solution, it is added both to the Data Sources window and the Solution Explorer as an XSD file. Other files are also added to the project to support strongly typed access to the data via a DataSet. These are created by the custom tool, MSDataSetGenerator, which is specified in the property grid for the XSD file. Later in this chapter you will look at an alternative tool that generates a SQLCeResultSet instead of a DataSet.
DataSet
Once the Data Source has been added to the project, the Data Sources window can be used to add databound controls to the design surface for the device. This is the same process described earlier in the book when you were working with DataSets for a desktop application. This section shows you how easily you can build a user interface to not only view the data, but also add and edit records. For this purpose, consider a limited scenario that works with the Northwind sample database that ships with Visual Studio 2005. This database is located in the SmartDevices SDK folder (C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SQL Server\Mobile\v3.0\Northwind.sdf), and can be added to the project as outlined in the previous section.
The scenario is to provide an interface for managing Customers and Orders. When adding the Northwind Data Source, you need to include these two tables, plus the Employees table for selecting the employee who took the order. This adds them to the Northwind DataSet and ensures that you have appropriate table adapters for retrieving and updating information in the database. The Northwind Data Source appears in the Data Sources window and has nodes for Customers, Orders, and Employees. Because there is a relationship between these tables when you expand the Customers node, you will see a subnode for Orders.
For this scenario, add a new form to the project to lay out Customer information. From the Data Sources window, select the Customers node and ensure that the drop-down field is set to DataGrid. You also want to prevent the Customer ID from being added to the DataGrid, so select None from the Display Type drop-down for this field. Now drag the Customers node onto the form. This adds a DataGrid to the form, along with a NorthwindDataSet, a CustomersBindingSource, and a CustomersTableAdapter to the nonvisual area of the designer, as shown in Figure 44-3.
