Mobile Application Development Lessons Learned

• Download sample project - 54.1 KB

Introduction

This article discusses two lessons learned during the development of a mobile application. Overall, the development proceeded without serious impact with the exception of changes to the specification that required a background image and changed the printer attached to the mobile device. Both changes occurred midway in the project.

Background

The Application

The mobile application is a workflow application whose purpose is to guide street venders through the process of selling theatre tickets. It is intended to be executed by trained operators. Customers, who desire theatre tickets for a show can, through the application, determine available performances and seating locations. When the number of tickets is known for a specific performance and seating location, the device queries theater servers for the specific seats. When the customer agrees to a performance and seating (the combination of which defines the ticket price), the customer may pay using a credit card or cash. Upon card issuer acceptance, the tickets are reserved, and the tickets and a receipt are printed.

The Execution Environment

The mobile application executes on a Motorola MC65 device. In turn, the device is connected to an Intermec PB31 printer by Bluetooth and to theatre servers by a Virtual Private Network (VPN). The latter, in addition to providing connectivity, also provides a secure channel between the device and its servers. Web services are used to pass data to and from theatre servers. The device runs the Microsoft Windows 6.5 operating system. The VPN API and the card swipe API are provided by Motorola in the Symbol library.

The Development Environment

The project was developed as a Windows Application on a laptop using the Visual Studio 2008 IDE with the .NET 3.5 framework. The target platform is the Windows Mobile 6.5.3 Professional DTK. The Windows Mobile 6.5.3 Professional VGA Emulator was used to test the software before deployment.

The screen displays were implemented using the Microsoft Mobile Device Emulator as a plug-in to Visual Studio 2008. When a screen was implemented, it was given to internal quality assurance for review prior to being provided to the customer. If errors were found, they were repaired before the screen was given to the customer for review. Collecting customer comments early was important to insure that the development stayed close to what the customer had originally envisioned.

Lessons Learned

Background Image

During the mobile application development, a background image was not specified until midway through the project. This caused a disruption while each form, for which a background image was required, was modified. I would suggest including a background image for the project, whether or not a background image is required. The image need not be the final (if any) background image; rather it should be a placeholder.

For the purposes of this discussion, I will use the following Visual Studio directory structure:

The steps to take are:

1. Define a solid color JPG image. Use any familiar tool to create the temporary background image (e.g., Paint). Choose a color that will be close to the color that will be used in the controls that will appear on the form. For this example, the solid color is RGB ( 213, 229, 245 ). Make the image size large enough to cover the size of the device that is being targeted. The resulting image is:
   
   
   
   
2. Create a folder, named "Images", under the startup project (hereafter "LessonsLearned") and save the JPG in that folder, calling it something like "BackgroundImage.JPG".
   
   
3. Select LessonsLearned; click Refresh then Show All Files; right-click the Images folder; and click Include in Project. The folder will open, showing the BackgroundImage.JPG file.
   
   
4. Left click on the BackgroundImage.JPG file. In the Properties window, change the Build Action to Embedded Resource.
   
   
5. Right click on LessonsLearned and choose Properties. Open the resources tab. Select Images from the drop down. Left click on the BackgroundImage.JPG filename (in the LessonsLearned folder "Images") and drag it into the Resources Images area. Insure that the image resource name is BackgroundImage.
   
   
6. Add an interface (C# class) to LessonsLearned that contains:
   C#

   using System.Drawing;
   
   // http://blogs.commentor.dk/post/Transparent-Controls-in-NETCF.aspx
   
   namespace LessonsLearned
       {
   
       // ********************************** interface IControlBackground
   
       public interface IControlBackground
           {
   
           Image BackgroundImage { get; }
   
           } // interface IControlBackground
   
       } // namespace LessonsLearned

   This interface, as well as the base class that follows, were derived from Christian R. Helle's article Transparent Controls in .NETCF.
   
   
7. Add the base form (C# class) FormBase to LessonsLearned:
   C#

   using System.Drawing;
   using System.Windows.Forms;
   
   // http://blogs.commentor.dk/post/Transparent-Controls-in-NETCF.aspx
   
   namespace LessonsLearned
       {
   
       // ************************************************ class FormBase
   
       public class FormBase : Form, IControlBackground
           {
           private Bitmap background = null;
   
           // ************************************************** FormBase
   
           public FormBase ( )
               {
   
               if ( background == null )
                   {
                   background = new Bitmap ( LessonsLearned.
                                             Properties.
                                             Resources.
                                             BackgroundImage );
                   }
               }
   
           // *************************************************** OnPaint
   
           protected override void OnPaint ( PaintEventArgs e )
               {
   
               e.Graphics.DrawImage ( background, 0, 0 );
               }
   
           // ******************************************* BackgroundImage
   
           public Image BackgroundImage
               {
   
               get
                   {
                   return ( background );
                   }
               }
   
           } // class FormBase
   
       } // namespace LessonsLearned

We are now in a position to use the new background image. In each form of the mobile application that could have a background image, just inherit from the base class, FormBase, as in:

namespace LessonsLearned
    {

    // ***************************************** class Lessons_Learned

    public partial class Lessons_Learned : FormBase
        {
        public Lessons_Learned ( )
            {

            InitializeComponent ( );
            }

        } // class Lessons_Learned

    } // namespace LessonsLearned

When this project is executed, it will appear as:

Now suppose that a background image is specified. Say that it looks like:

All that is required to implement this new background image is to copy the new background image JPG to \Images\BackgroundImage.jpg. When this revised project is executed, it will appear as:

Intermec Printer

The mobile application printer is provided to allow printing of tickets and receipts. Both contain text and graphics that were to be strategically placed on the printed tickets or receipt. The customer's marketing organization was responsible for specifying the item placement.

At the beginning of the development effort, an Intermec PB21 mobile receipt printer (hereafter "PB21") was specified. The PB21 has a 1.8 maximum inch print width. The development team chose the Intermec Printer Language (IPL) to define the receipt and ticket templates. This choice was not optimal: IPL is a difficult language to learn; its maintenance costs are enormous. For example, to specify a boxed text string, the following commands are required:

Midway through the project, the Intermec PB31 mobile receipt printer (hereafter "PB31") was substituted for the PB21. The PB31 has a 2.8 maximum inch print width. Fortunately, when the change occurred, the choice of language that would be used to define labels could be revisited. The new language chosen was Intermec Fingerprint. From the Programmer's Reference Manual:

Intermec Fingerprint is a BASIC-inspired, printer-resident programming language.... Fingerprint is an easy-to-use intelligent programming tool for label formatting and printer customization.... Improvements or changes due to new demands can be implemented quickly and at minimal cost.

The objections to IPL were silenced by the choice of Fingerprint. Using the same example as above, the following commands are required (note coordinate are not the same):

There does not appear to be any advantage in using Intermec IPL; while using Intermec Fingerprint has the major advantages of ease of use (shallow learning curve) and improved readability (i.e., maintainability).

The lesson learned: choose third party languages with care; choose the easiest to learn and maintain.

Summary

I'm sure that many of my readers are already aware of these two possible pitfalls during mobile application development. I present them only because they caused disruption and extended project timelines.

History

• 08/13/2012 - Original article