AIRmobility / Retail Engagement Program

The AIRmobility and  Retail Engagement Program apps are a mobile workforce form/data/news app built and branded for multiple different companies. The combination of client applications and server programs, provide the client with a complete paperless form handling system.

My project involved an initial porting of a minimal Java/Android app to the Windows Phone platform followed by extensive development of new features and a port from the Windows Phone platform to the Windows Store platform. A web-based client app followed a few years after the initial port to Windows and Windows phone. More recently, a client app for iOS was written from scratch in Swift, and the Android app got extensive improvements.

Window Phone


Windows Phone App Main Page

The Windows Phone 8 app is written in C# and XAML and uses many of the phone’s features, some of which are:

  • Camera and Picture Library Access
  • GPS and Location Services
  • Bar Code Reading
  • Web Services Client

The app is multi-threaded, and uses web service posts requests to handle incoming content updates and outgoing form uploads.

image  image  image

Various Form Pages

In the images above, you can see two form pages with a variety of controls. There is also a picture of the verification page seen before any form is sent to the server. Forms can be configured on the server to have panorama/pivot sections. They can also be configured to have separate pages and utilize navigation buttons to move from one page to another. In addition to having a conditional visibility logic for pages, individual controls within a form can be conditionally displayed based on the data entered in other controls. For example, whole pages can be hidden if they don’t apply to the selection within an earlier list.

There are a variety of form controls available including, but not limited to controls for:

  • Date/Time
  • Text and Large Text
  • Numeric Data
  • Phone Number
  • Email Address
  • Email Address – used to send a copy of the form to someone upon submission
  • Photo
  • Checkbox, Yes/No Checkboxes, Yes/No Text Selection
  • Single Selection List
  • Multiple Selection List
  • List controls can display different sets of selections based on selections within earlier lists. One form can even affect the contents of another form that is opened at the same time.

Windows Store

The Windows Store app has a superset of the functionality available in the phone app, while displaying forms horizontally. It is designed for tablet devices but works fine on any Windows 8.1 computer.

In addition to all of the same form controls, the Windows Store app also provides a more useful interface for accessing data files that have been downloaded from the server. It also can display news items, thus providing more than a simple form entry platform.


Main Page


Form Page


Form Page with List

The pictures above show various pages in the app. The form pages, here and in the phone app, have content that is designed on the server. These are just a small example of the variety of controls and formatting available to administrators and users.

The app is written, like the phone app, in C# and XAML.

Windows App Programming

The Windows Phone and Windows Store environments present many interesting programming challenges. Both environments require that any manipulation of the user interface be done in an existing user interface thread. This adds significant complexity to the apps because many operations are performed asynchronously by the OS.

In addition to the complexity added by having only a single UI thread capable of UI manipulation, the Windows Store app environment provides all file system access asynchronously. Even in the context of a background thread, the code to open, read, write, or even close a file, cannot be blocked until completion. In the UI thread, a user could navigate away from a page while at the same time completing some I/O operation that relies on that page. These programming requirements enforce a responsive user interface but also then require large amounts of error handling to be added to the code.

Another interesting programming issue is the lack of built-in database support in Windows Store apps. The Windows phone provides SQL and Linq capabilities built-in, while Windows 8.1 does not. This causes there to be even larger amounts of C# code that is almost identical but not usable on both systems.


The web client app consists of a set of web pages, all created on-the-fly, and a web server to provide an interface to the non-web server. Since the other client apps all communicate with a server to send and retrieve data, and since the web client app uses a server to generate the web pages for the user and to accept HTML form data, an intermediate server was needed. There was no sensible way to add the web client processing to the data processing server and no way to build all of the app functionality into the web page using JavaScript.

A more detailed description of the architecture is this…

There is a Tomcat server that runs Java code to generate the web pages. After an initial logic, the intermediate server code passes a user ID to the main server and gets back a block of XML data. That XML data is saved for the specified user ID and a “session” is created to track the user interactions. The XML data is parsed and an initial home page is presented to the user. If the user selects a form to open and fill out, a request to open a form is sent to the intermediate server in the form of a Url with a specific query for the form ID. The client JavaScript code does this request using an iFrame that covers the entire browser window to make navigation simpler for the client app code. If the user is filling out a form and needs to open another form, it too is opened in a full window iFrame. The iFrames allow the JavaScript code to track which forms are open and to avoid any need to save a temporary copy of a form when opening another “on top of it.”

To pass data to the client JavaScript code with enough detail to allow the forms to have conditional logic (showing and hiding fields based on selections of other fields), a single JavaScript block is sent to the client inside of the HTML data and that JavaScript block contains essentially JSON-style data. The JavaScript object at the top of the hierarchy contains all of the data that the form needs to alter fields dynamically at runtime. Data like this is also used to restore a saved form.

The interface for the web client was designed to look like the interface for the Windows app. One large difference is that if the viewport/screen is too narrow for horizontal scrolling to work well, the web client dynamically changes to use a paged interface where the user uses Next and Previous buttons to navigate between pages. The placement of some other buttons and controls were changed because the Windows 10 style just didn’t work well for a web-based app.


The original Android app was written in Java by a different developer. My task was to update the user interface to fit a more modern style that is more consistent across the multiple platforms and to add features that were added to the Windows apps after their initial port.


The iOS app was written essentially from scratch in the Swift programming language. I call it “from scratch” because only a few lines of code here and there were copied and converted to Swift from the other app sources. The remainder of the code was designed and typed in without direct conversion from the other app code. Of course, there is a lot of non-user-interface code that ended up similar between the apps due to the feature specifications being the same.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.