2 - Building the Mobile Client

On this page:	Download:
Overview of the Mobile Client Application - You Will Learn | Goals and Requirements - Usability Goals, Non-Functional Goals, Development Process Goals | The Components of the Mobile Client Application | The Structure of the Tailspin Surveys Client Application - Dependency Injection, The TailSpin Solution, The Contents of the TailSpin.PhoneClient Project, The Contents of the TailSpin.PhoneClient.Adapters Project, The Contents of the TailSpin.PhoneServices Project

This chapter describes how the developers at Tailspin built the user interface (UI) components of the mobile client application. It begins by discussing some of the goals and requirements that Tailspin identified for the application before discussing, at a high level, the structure and key components of the application.

The chapter then discusses navigation and UI controls in more detail, and describes how and why Tailspin implemented the Model-View-ViewModel (MVVM) pattern. The chapter also gives an overview of the MVVM pattern itself.

The chapter includes discussions of the design Tailspin adopted for the application as well as detailed descriptions of the implementation.

Overview of the Mobile Client Application

You Will Learn

• The goals and requirements of the mobile client application.
• How the mobile client application is structured.
• How the Visual Studio solution for the mobile client application is organized.

This section provides an overview of the mobile client application to help you understand its overall structure before you examine the components that make up the application in more detail. Also, to help you understand some of the design decisions made by the developers at Tailspin, it describes some of the goals and requirements that Tailspin identified for the application.

Goals and Requirements

Windows® Phone OS 7.1 offers a wealth of features to developers and designers. The team at Tailspin wanted to ensure that their mobile client application makes the best possible use of the latest version of the platform and also plays by the rules. The application follows the recommended usability guidelines to ensure an optimal user experience and the "good citizen" best practices guidelines to ensure that the application makes efficient use of resources on the device in the context of the phone's functionality and other installed applications. They identified three sets of goals for the design and development of the application: usability goals, non-functional goals, and development process goals.

The Tailspin mobile client application follows usability and good citizen best practices.

Note

For more information about Windows Phone UI design guidelines, see User Experience Design Guidelines for Windows Phone on the MSDN® developer program website.

Usability Goals

The usability goals are designed to ensure that the user's experience of the application meets her expectations for applications on a Windows Phone device. The following table lists some examples.

Goal description	Example
Take advantage of the appearance and behavior of the Windows Phone platform.	The application accepts standard input gestures for users to enter data, uses the standard system colors, and includes icons designed to match the phone's theme. The application can update its appearance to blend with the phone's standard Light and Dark themes. For more information, see the ThemedResourceLocator class in the Resources folder.
Use the standard controls Windows Phone users are familiar with.	The application uses standard controls, including the ApplicationBar, and Pivot controls, to make the user feel at home and to minimize the learning curve. In addition, the application also uses controls from the Microsoft Silverlight® for Windows Phone Toolkit.
Follow other Windows Phone UI guidelines, such as those on the use of the hardware Back button and the behavior of the application when the user answers a call or switches to another application.	The Back button navigates backward in a way that matches the user's expectations. The application restores the UI to its previous state after the user finishes answering an incoming call.
Integrate with the phone capabilities.	The application uses the location services on the phone to establish its geographical location, and it uses the camera and microphone to collect data for some survey questions.
Handle changes in screen orientation.	The application automatically updates the display orientation when the user changes the phone's orientation.
Handle standard screen resolutions.	The application displays correctly in the standard screen resolutions for Windows Phone devices.
The application should always have a responsive UI.	The application performs long-running tasks, such as synchronizing with the Surveys service, asynchronously or by the background agent. The application remains responsive when it has a large number of surveys saved locally and when it is displaying a survey with a large number of questions.
Take advantage of the background agent feature of the Windows Phone platform.	The data being used and produced by the application could synchronize with the back end in the cloud, even if the application is not running or being used.

Christine Says:
	Users will prefer an application that fits well with the phone's UI design and theme. You will also have to comply with certain UI design guidelines if you want to distribute your application through Windows Marketplace.</td>

Non-Functional Goals

The non-functional goals describe expected behaviors for the application, including some good citizen behaviors that relate to the limited resources on the device. The following table lists some examples.

Goal description	Example
The application should continue to operate even when it is not connected to the back end in the cloud.	The application stores survey definitions and user responses in local storage, and it synchronizes with the cloud back-end store when connectivity is restored.
The application should not rely on specific network capabilities or assume a minimum available bandwidth.	The UI always interacts with local storage. The application uses an asynchronous call to synchronize with the Tailspin Surveys remote service and uses a store-and-forward pattern. Only the background agent, which uploads survey answers, requires a non-cellular connection and this is handled by the background agent itself.
The application should try to minimize the costs associated with using the network.	The application tries to minimize the amount of data transferred over the network by using JSON serialization instead of XML. The application does not compress the data because of the additional CPU overhead and battery consumption that this requires. In addition, the resource-intensive task, used by the background agent to upload survey answers, checks the current network interface type and only runs if a WiFi connection is available.
The application should proactively notify users of new information generated by the back end.	The back end uses the Microsoft Push Notification Service to notify users of new surveys available for their phones.
The application should use memory efficiently and, for performance, minimize memory allocations.	The sample application uses a dependency injection container to manage which objects are cached to improve performance and which objects are recreated whenever they are used.
As a "good citizen," the application should minimize its use of isolated storage—a shared resource on the phone.	The application removes completed surveys from isolated storage after the data successfully synchronizes with the Tailspin Surveys service. It also uses the JSON serializer when it saves data to isolated storage.

Jana Says:
	You should always be aware of how your application consumes the limited resources on the phone, such as bandwidth, memory, and battery power. These factors are far more significant on the phone than on the desktop.</td>

Development Process Goals

Tailspin also identified a number of goals that relate to their own development processes. The following table lists some examples.

Goal description	Example
Tailspin wants to have highly testable code.	A significant advantage of the MVVM pattern is that it makes the code more testable.
Tailspin wants to able to support other mobile platforms in the future.	Using standards-based approaches to interact with the back end makes it easier to develop other clients for other platforms.
Tailspin wants to have an efficient development process.	Developers and designers can work in parallel. Designers can prototype and build the UI using Microsoft Expression Blend® design software while the developers focus on the application's logic.
Tailspin wants to be able to adapt the application to work with any new capabilities of future versions of the Windows Phone platform.	The application uses an abstract persistence model to "wrap" local isolated storage on the device. Tailspin could easily change this in future to use the local database that resides in the application’s isolated storage container.

Markus Says:
	The Windows Phone platform will continue to grow, so design your application so that you can easily modify it to use new features.</td>

The Components of the Mobile Client Application

Figure 1 shows the main components that comprise the Tailspin Surveys client application.

Figure 1

The Tailspin Surveys client application

The developers at Tailspin built three key components of the application: the UI, the storage sub-system, and the synchronization service. The application also uses some components of the Windows Phone platform; in particular, the GPS, camera, microphone, the notification services, and the network services that the application uses to communicate with the back-end web services.

The application uses a number of features offered by the Windows Phone platform.

This chapter focuses on the UI components and also describes how the application components are linked together through Tailspin's implementation of the MVVM pattern. Chapter 3, "Using Services on the Phone," will examine the storage and synchronization components, and Chapter 4, "Connecting with Services," will look at the notification process and the integration with the back end in more detail.

The Structure of the Tailspin Surveys Client Application

Figure 2 shows the structure of the Tailspin Surveys mobile client application in more detail. For clarity, the diagram does not show all the links between all the components. In particular, multiple links exist between the model components and the view model and the application services, but showing all of these would unnecessarily clutter the diagram.

Figure 2

Tailspin Surveys mobile client application structure

To understand how Tailspin built the UI components (such as the SurveyListView page and the AppSettingsView page), how the navigation between the pages work, and how the application determines which page to display to the user when the user launches the application, you should read the section, "The Design of the User Interface," later in this chapter.

To understand how and why Tailspin uses the MVVM pattern, you should read the section, "Using the Model-View-ViewModel Pattern," later in this chapter. This section explains the roles of the view, view model, and model components and how they are linked together, including the role of the ViewModelLocator class. This section also describes some data-binding scenarios in the application, including the way the application uses the Pivot control on the SurveyListView page and on the TakeSurveyView page.

To understand how the application manages its state when it's dormant or tombstoned, you should read the section, "Handling Activation and Deactivation," in Chapter 3, "Using Services on the Phone."

Note

An application is made dormant by the Windows Phone device when, for example, the user navigates to another application or answers a call while using the application. In this state, the application remains intact in memory but no processing takes place. If the application is reactivated from this state, it does not need to recreate any state because it has been preserved. Dormant applications may be tombstoned by the operating system in order to free up memory. A tombstoned application has been terminated, but information about its navigation state and state dictionaries are preserved for when the application is relaunched. A device will maintain tombstoning information for up to five applications at once. For more information see, "Execution Model Overview for Windows Phone," on MSDN.

To understand how the application manages persistent data on the phone, such as application settings and survey responses, you should read the section, "Using Isolated Storage on the Phone," in Chapter 3, "Using Services on the Phone."

To understand how the Tailspin Surveys cloud application can notify the mobile client of new surveys by using the push notification service, you should read Chapter 4, "Connecting with Services."

To understand how the application transfers survey data between the mobile client application and the cloud application, you should read Chapter 4, "Connecting with Services."

Dependency Injection

The developers at Tailspin use a dependency injection container to manage the instantiation of many of the classes, including the view model classes.

Markus Says:
	Dependency injection enables decoupling of concrete types from the code that depends on these types. It uses a container that holds a list of registrations and mappings between interfaces and abstract types and the concrete types that implement or extend these types.</td>

Tailspin uses the Funq dependency injection container instead of the Unity Application Block (Unity) because Unity is not available for the Windows Phone platform. The Funq dependency injection container is also lightweight and very fast.

The ContainerLocator class shows how the application creates the registrations and mappings in the Funq dependency injection container. In the Tailspin mobile client application, the ViewModelLocator instantiates the ContainerLocator object and is the only class in the application that holds a reference to a ContainerLocator object.

By default, the Funq dependency injection container registers instances as shared components. This means that the container will cache the instance on behalf of the application, with the lifetime of the instance then being tied to the lifetime of the container.

Jana Says:
	You should consider carefully which objects you should cache and which you should instantiate on demand. Caching objects improves the application's performance at the expense of memory utilization.</td>

The TailSpin Solution

The TailSpin.PhoneOnly solution organizes the source code and other resources into projects. The following table outlines the main projects that make up the Surveys mobile client application.

Project	Description
TailSpin.Phone.Adapters	This project contains interfaces, adapters, and facades for Windows Phone API functionality.
TailSpin.PhoneAgent	This project contains a background agent implementation that launches a periodic and a resource-intensive task.
TailSpin.PhoneClient	This project contains the views and view models for the Surveys mobile client application, along with supporting classes and resources.
TailSpin.PhoneClient.Adapters	This project contains interfaces, adapters, and facades for Windows Phone API functionality that is not supported by background agents. Creation of this project was necessary in order to pass the capability validation performed as part of the Windows Phone Marketplace application submission process. This is because the set of APIs not supported by background agents must reside in a project not referenced by the TailSpin.PhoneAgent project. For more information, see "Unsupported APIs for Background Agents for Windows Phone," on MSDN.
TailSpin.PhoneServices	This project contains web service client implementations that interact with the Tailspin Surveys service in the cloud.

The Contents of the TailSpin.PhoneClient Project

The TailSpin.PhoneClient project organizes the source code and other resources into folders. The following table outlines what is contained in each folder and provides references to where this guide describes the content in more detail.

Project folder	Description
Root	In the root folder of the project, you'll find the App.xaml file that every Microsoft Silverlight® project must include. This defines some of the startup behavior of the application. The root folder also contains some image files that all Windows Phone applications must include.
Properties	In this folder, you'll find two manifest files and the AssemblyInfo.cs file. The WMAppManifest.xml file describes the capabilities of the application and specifies the initial screen to display when the user launches the application. In addition, it also contains the details of the background agent used by the application.
Resources	This folder holds various image files that the application uses and a utility class that performs conversions to types that are used in UI.
Views	This folder contains the views that define the screens in the application. The section "Using the Model-View-ViewModel Pattern" in this chapter describes the role of views in this pattern and highlights the fact that there should be little or no code in the code-behind files.
ViewModels	This folder contains the view models. The section "Using the Model-View-ViewModel Pattern" in this chapter describes the role of view models in this pattern. You will find more view models than views because individual user controls may also have their own view models.
Themes	The XAML file in this folder contains style definitions.
Services	This folder contains the ContainerLocator class, which creates the registrations and mappings in the Funq dependency injection container. The folder also contains the ScheduledActionClient class that uses the ScheduledActionService class from the Windows Phone API.
Services/RegistrationService	This folder contains client implementations that interact with the Tailspin Surveys service in the cloud. Chapter 4, "Connecting with Services," describes the web service clients in this folder.
Infrastructure	This folder contains utility code required by the application. The section "Using XNA Interop to Record Audio" in Chapter 3, "Using Services on the Phone," describes how some of the classes in this folder are used.

The Contents of the TailSpin.PhoneClient.Adapters Project

This project contains interfaces that mirror functionality in several classes in the Windows Phone 7.1 SDK, including ICameraCaptureTask, IShellTile, and INavigationService.

This project also includes adapter implementations of these interfaces that simply pass parameters to and return values from the underlying instances of the SDK classes. These interfaces and adapters are used in the mobile client application to increase testability. For more information see Appendix A, "Unit Testing Windows Phone Applications."

This project is similar to the TailSpin.Phone.Adapters project. Both projects have interfaces and adapters that "wrap" functionality in the Windows Phone 7.1 SDK. These two projects are separated because the set of APIs not supported by background agents must reside in a project not referenced by the TailSpin.PhoneAgent project. The TailSpin.PhoneAgent project utilizes the adapters in the TailSpin.Phone.Adapters project but not the TailSpin.PhoneClient.Adapters project.

The Contents of the TailSpin.PhoneServices Project

The TailSpin.PhoneServices project organizes the source code into folders. The following table outlines what is contained in each folder and provides references to where this guide describes the content in more detail.

Project folder	Description
Models	This folder contains the models. The section “Using the Model-View-ViewModel Pattern” in this chapter describes the role of the models.
Services/Clients	This folder contains the HttpClient class that makes asynchronous web requests. Chapter 4, “Connecting with Services,” describes this class.
Services/RegistrationService Services/SurveysService	These folders contain client implementations that interact with the Tailspin Surveys service in the cloud. Chapter 4, “Connecting with Services,” describes the web service clients in this folder.
Services/Stores	This folder contains classes for persisting application settings and survey data to and from isolated storage. Chapter 3, “Using Services on the Phone,” describes these stores.

Next Topic | Previous Topic | Home

Last built: May 25, 2012