Note that much of the source code has been withheld as an effort to preserve client confidentiality, but please do not hesitate to contact me if you would like to find out more about the development process. Thanks.
Tsunami’s SafetyLine service is intended to monitor the safety of people working on their own and they have an easily accessible web interface that allows for users to check-in to their service (similar to Foursquare when say visiting restaurants or retail stores) through the web. They also have working apps for Android, BlackBerry, iOS (iPhone), and previous generations of Windows Mobile, but with Microsoft’s latest addition of Windows 8 and app-centric operating environment for PCs as well as tablets – the company wanted something to be tailored for this new platform.

As a result, the desires of the client lie within developing an app for the latest version of Windows and eventually have it readily available on the Windows Store catalog. To make connections to their SafetyLine service, calls made to their REST-based API were required. In addition, commands sent and received from the server were either sequentially encoded or decoded accordingly. Following Figure 1.1 illustrates the general user interaction with the server.

Block Diagram

Figure 1.1 – General block diagram of event flow

Design and Layout

Since UI and UX design was not a strong area of specialization, some rough layouts were formulated to determine how the app will generally appear. This was in the best interest and attempt to conform to best practices. There were no blueprints or drafts with only initial ideas coming from the client, so their existing Android and web applications were referenced to. Working from the ground up, some wire framing and measurements were made in Blend – the design planner that is bundled with Visual Studio.

Below is a preview of early planning done in the program and displayed on a mock tablet device canvas. Refer to the Appendix (Design and Layout Screenshots subsection 9.1) for additional images.

Design Wireframe

Image 2.1 – Preview of the early stage layout for the app in Blend

As seen above (Image 1.1), a mix of measurement units were used including “px” and “fr” and they are both pixel and fractional unit respectively. Pixels are a more common form of unit most people are familiar with, while fractional units are the remaining space left in the element.

Drawing closer to the end of the initial design work, various components (or Assets) were being utilized and they cover the app bar (hidden menu), buttons, as well as the login flyout. When placing and rearranging the items, the respective HTML and CSS files are generated with the appropriate source code. This, however, is simply an “outer shell” that bares no real logic in terms of functionality and is required to be implemented. Below is a preview (Image 5.0.2) with more of the necessary elements tied into the app.

Late Design

Image 2.2 – Preview of the late stage layout for the app in Blend

The HTML and CSS files work similarly to webpages in the case of Windows Store apps, but the CSS resources provide more than standard styling and allow for different formatting options depending on the orientation or view of the app. Four main views include Landscape, Filled, Snapped (see Image 5.0.3 below), and Portrait – each having a section in the style sheet for different values or options.

Main Snapped

Image 2.3 – Preview of the early stage layout (Snapped view) with buttons, display area in Blend

Functionality Analysis

After planning out most of the visual layout of the app came determining what happens behind the scenes when input is taken in from users. One of the first things that need to take place is logging in and these meant credentials were to be passed to the server with a response that is then returned. Knowing that the company uses a REST based service, XML would be involved and following is the diagram of a user login scenario formulated that is also based on some of the steps indicated from their API.

All the main functions of the application cover the following:

  • User Login (manual)
  • Auto-Login
  • Sending OK, End, or Emergency statuses
  • Setting the next report time
  • Sending GPS location coordinates
Below (Figure 3.1) are the series of steps that take place when the user connects normally by manually entering their login information.


Figure 3.1 – Diagram of user logging in to the service normally

Implementation Process

The more intricate aspect of this project was passing data to the server and handling the response, since it was not simply handling plain text (this being obvious for security reasons). The best way to get a better idea of this concept is to present the process visually with the following diagram (Figure 4.1).

Implementation Login State

Figure 4.1 – Diagram of user pressing login (Submit) button

Final Product Screenshots

Set Next Function Custom

Image 5.1 – Set Next Report success with custom time setting

GPS Function

Image 5.2 – GPS location report and map display