Running In the Field: How to Make Your Handheld Your Best Friend : Page 4

Retrieving Old Data
The form that retrieves old data has two goals: call the remote web service with (optionally) some user-entered filter values, and show data on the GUI.

The first task is quite trivial, and it's very similar to the data-inserting function that you saw in the preceding section. The second task is also quite trivial, because you just need to bind the list of Travelogue objects returned by the web service to a standard DataGrid (see Figure 4 and Figure 5). As you can see, the programming model is exactly same as writing a standard .NET desktop application.

Figure 4. Retrieving Existing Records: Users can browse through all the existing items, using this list of Travelogue records bound to a DataGrid.

Figure 5. Filtering Records: By entering some filter text in the "Title" field, users can retrieve only the records whose title matches the filter criteria.

Here's the code:

   Dim results As List(Of Travelogue.Travelogue)
   Try
      ' -- create the proxy to remote web server
      Dim remote As New Travelogue.TravelogueService
      ' -- make the remote call
      results = remote.GetTravelogues(txtTitle.Text).ToList
   Catch ex As Exception
      MessageBox.Show("Error during download" & vbCrLf & _
      ex.Message, "Error", MessageBoxButtons.OK, _
      MessageBoxIcon.Exclamation, _
      MessageBoxDefaultButton.Button1)
   End Try
   
   ' -- bind the result to GUI control
   dgResults.DataSource = results
   

From Example to Real World
In a real-world application you would need to add some additional features to create a truly useful application. For example, adding a client side cache would avoid multiple round trips to the server; using compression techniques to compact data transferred over the wireless network could improve application performance; and a security system to protect the data and both ends of the application would be required. However, adding these features won't require a change to the underlying architecture, which you can expand to fit any requirement.

Mobile devices are not expensive toys. They can be a mobile worker's best friend if he or she works in the field and needs a really portable, lightweight, yet powerful tool.

From an enterprise's prospective, it may be more cost effective to develop an integrated and focused application that runs on mobile devices and integrate that with a business-class central system than to buy laptops and run generic "datasheet" applications on them, or use Terminal Services or Citrix sessions that execute software on a remote server. The mobile applications require tightly-controlled project management, of course, but they can make everyday tasks easier and more palatable for users.

From a programmer's prospective, Microsoft has made a great effort to provide a development platform that is both powerful and easy to use. Developers familiar with .NET can start developing mobile applications using .NET CF without learning a new development environment or language. As usual, knowing a programming language or a development tool doesn't necessarily mean that new mobile developers will be able to create production-level business applications immediately; moving to mobile development isn't trivial. In particular, connected applications require architectural knowledge that can impact the application, not just programming. However, Microsoft has opened the door to the mobile development world, and now is a good time to enter.

Previous Page