Share your code across Windows 8 and Windows Phone 8 Apps

I believe whenever developers embark in a new development project, they have a natural inclination towards trying to find a way to minimize the amount of code and mitigate the duplication of efforts. I certainly share this inclination and with this mindset I starter to work on my APIMASH Starter Kit,  and quickly gravitated towards the Portable Class Library (PCL) project template (included in the multi-platform versions of Visual Studio), as a mean to create a common platform for my Starter Kit that will work for Windows 8 and Windows Phone 8.  Using the PCL project template you can implement assemblies that will run cross-platform (in my case Windows 8 and Windows Phone 8) without any modification.

 

Picking the PCL template was certainly, a good starting point but in addition, I needed an overall architectural approach to help me frame the implementation. I have a preference for the MVVM architectural pattern, so this was an easy choice to make, especially considering that I was going to be using C#/XAML and wanted to leverage the robust data binding infrastructure that XAML provides.

 

With the goal of providing the proper context, let me step back and discuss the intent of my APIMASH Starter Kit.  In short, the APIMASH Starter Kit is a working sample of a Windows 8 and Windows Phone 8 App that showcases the use of a public API as a data source – a REST API in most cases.  In my particular case, I am using the Eventbrite API

 

In my Starter Kit, in addition to the use of MVVM pattern and Portable Class Libraries, I wanted to demonstrate the use of some of the components in the Windows Phone Toolkit, Geolocation API as well as the use of Dynamic Objects as Data Transfer Objects.  I will discuss the details of these and other related topics in subsequent blog posts.

 

With this context in mind, let’s now summarize the functional behavior of the application.  The following diagram depicts this behavior, at a high level.

 

clip_image001

 

API Invocation: This is the part of the data loading process where the App will perform an API call to the REST endpoint using the networking stack.  The response body is expected to be in JSON format.

 

Deserialization: Once the App receives a response from the API, the App needs to convert the JSON response to a CLR object instance. This process is called deserialization. I refer to this object as Data Transfer Object (DTO).

Please note that in the MVVM world, the term DTO is not often used, instead you will find references to models, entities or domain objects. These objects typically represent the fundamental data model of an application that is then mapped or projected into a View Model.  In the case of my APIMASH Starter Kit, I am using an small subset of the data model that the API endpoint provides and given that I don’t intent to propagate much of the semantics of a third party data model in my app, I just needed a container to aggregate the data from the API call, in this context the term DTO felt, in my opinion, a better descriptor for this type of object.

View Model Mapping: A View Model is a representation of the data model in a structure that facilitates the binding to the UI. In the specific case of the Starter Kit, as part of the data loading process the App will create a View Model and perform the mapping process from the DTO to the View Model.

 

View Binding: Here the App will set the DataContext of the UI elements representing the View, to the appropriate View Model.

 

You probably noticed that as I described the functional steps, I did not mention any specifics in regards to the platform. The reason behind this, is that the functional behavior is almost the same for both platforms.  The only differences is that the Views will likely be platform specific and you might need to control the data loading process taking into consideration the resources of the target platform – I will provide more insights about this in my subsequent posts. 

 

From this you can also see that functionally, the data loading process is the same for both platforms; which makes this process a great candidate for an implementation as portable libraries. And this is precisely what I pursued in my Starter Kit.  

 

You can download the APIMASH Eventbrite API Starter Kit from here

 

Eventbrite API APIMASH Starter Kit Solution Structure

The Starter Kit consist of a single Visual Studio solution containing four projects.

 

image

 

The following table provides an overview of each project.

 

Project Name Description Project Type

APIMASH_Core

This is core a library containing the base classes for the View Models, and the networking implementation. This project is generic and does not contain any API specific implementation. Portable Class Library

APIMASH_EventBrite_Core

This is a core library for the Eventbrite API containing concrete implementations of APISMASH_Core base View Models for the APIMASH Eventbrite API Starter Kit. This is where the actual API calls are invoked. Portable Class Library

APIMASH_EventBrite_WP8

This is the sample Windows Phone 8 App using both portable libraries. Platform specific implementation. Windows Phone App

APIMASH_EventBrite_Win8

This is the sample Windows 8 App using both portable libraries. Platform specific implementation. Windows 8 App (C#/XAML)

 

In my next blog posts, I will go into details of the implementation.

 

Stay tuned!


No Comments

Post Reply