SoCal .NET Architecture Presentation

Just finished my presentation on designing enterprise applications for Windows Phone 7. Many thanks to Mike Vincent, David Wells, and everyone who attended. Here are the links to slides and source code of the sample application. Feel free to contact me if you need any help building the solution.

Mobile Enterprise Application. Step 3: Registering For Push Notifications

This is a third post in a series. Previous posts:
 - Step 1: General Architecture
 - Step 2: Authentication

I briefly defined Push Notification Service in the previous post. Here we will take a closer look at implementing notifications. PNS has cloud-based infrastructure maintained by Microsoft; phone application registers with it and assumes a unique endpoint address. That address is sent to the server portion of our system which uses it to forward messages to PNS infrastructure which, in turns, forwards it to the phone. There are three different types of alerts that can be sent:

1. Tile notifications. If an application is pinned to the start screen, its image (a.k.a. tile) can change in response to tile notification. We can either change the entire image or just display a number on the default tile.
2. Toast notifications. These are essentially short text messages that are briefly displayed on top of the phone screen. If user touches the message, associated application opens up.
3. Raw notifications. If previous two are used to communicate with the phone OS, this one is targeted at the phone application itself. Therefore, message contents and system response will be application-specific.

Check User Preferences

According to Microsoft certification requirements, users should be able to opt out of push notifications. The most straightforward approach is to store user preferences in the application setting.

   1:      public class AppSettings

   2:      {

   3:          private readonly IsolatedStorageSettings _isolatedStore;

   4:   

   5:          public bool CanUsePNS

   6:          {

   7:              get

   8:              {

   9:                  return GetValueOrDefault<bool>(Constants.Settings.CanUsePNSKey, Constants.Settings.CanUsePNSDefault);

  10:              }

  11:              set

  12:              {

  13:                  AddOrUpdateValue(Constants.Settings.CanUsePNSKey, value);

  14:                  Save();

  15:              }

  16:          }

  17:   

  18:          public AppSettings()

  19:          {

  20:              _isolatedStore = IsolatedStorageSettings.ApplicationSettings;

  21:          }

  22:   

  23:          public bool AddOrUpdateValue(string key, Object value)

  24:          {

  25:          }

  26:   

  27:          public TValueType GetValueOrDefault<TValueType>(string key, TValueType defaultValue)

  28:          {

  29:          }

  30:   

  31:          public void Save()

  32:          {

  33:              _isolatedStore.Save();

  34:          }

  35:      }

Register Push Channel.
This needs to be done when application starts and after user confirmed he or she wants to use PNS.

   1:          public void RegisterPushChannel()

   2:          {

   3:              if(!(new AppSettings()).CanUsePNS) return;

   4:   

   5:              _httpChannel = HttpNotificationChannel.Find(Constants.ChannelName);

   6:   

   7:              if (null != _httpChannel)

   8:              {

   9:                  SubscribeToChannelEvents();

  10:                  SubscribeToService();

  11:                  SubscribeToNotifications();

  12:              }

  13:              else

  14:              {

  15:                  _httpChannel = new HttpNotificationChannel(Constants.ChannelName, Constants.Channels.Service);

  16:                  SubscribeToChannelEvents();

  17:                  _httpChannel.Open();

  18:              }

  19:          }

Method SubscribeToChannelEvents simply adds application handlers to process various events raised by the HttpNotificationChannel object.

   1:          private static void SubscribeToChannelEvents()

   2:          {

   3:              // Register to UriUpdated event - occurs when channel successfully opens

   4:              _httpChannel.ChannelUriUpdated += new System.EventHandler<NotificationChannelUriEventArgs>(HttpChannelChannelUriUpdated);

   5:   

   6:              // Subscribe to raw notifications

   7:              _httpChannel.HttpNotificationReceived += new System.EventHandler<HttpNotificationEventArgs>(HttpChannelHttpNotificationReceived);

   8:   

   9:              // General error handling for push channel

  10:              _httpChannel.ErrorOccurred += new System.EventHandler<NotificationChannelErrorEventArgs>(HttpChannelErrorOccurred);

  11:   

  12:              // Subscribe to toast notifications

  13:              _httpChannel.ShellToastNotificationReceived += new System.EventHandler<NotificationEventArgs>(HttpChannelShellToastNotificationReceived);

  14:          }

Method SubscribeToNotifications binds channel notifications to Windows shell:

   1:          private static void SubscribeToNotifications()

   2:          {

   3:              if (!_httpChannel.IsShellToastBound)

   4:              {

   5:                  _httpChannel.BindToShellToast();

   6:              }

   7:              if (!_httpChannel.IsShellTileBound)

   8:              {

   9:                  _httpChannel.BindToShellTile();

  10:              }

  11:          }

Associate User and Channel URI
Method SubscribeToService needs to send unique endpoint URI (which can be accessed via _httpChannel.ChannelUri property) to the server portion of the system, e.g., by calling a web service. The service will associate the URI with the ID of the currently logged in user. This is an important consideration: since different users may be using the mobile application (or the same person may have different user accounts), but channel URI will always be the same. If we do not properly associate URI with the current user, he or she will be receiving other person's notifications. By the same rationale, when user logs off from the application, a web service call needs to be made to disassociate her from push notifications URI.

Mobile Enterprise Application. Step 2: Authentication

This is a second post in the series. Previous post:
 - Step 1: General Architecture

Authentication - as in supplying proper user credentials - is an essential part of any enterprise application. Consumer apps and games usually allow unauthenticated users to execute them, but enterprise systems have higher security requirements. So, your login page is likely to be set in WMAppManifest.xml as default task:

    <Tasks>
      <DefaultTask Name ="_default"
            NavigationPage="/Views/LoginPage.xaml"/>

    <Tasks>

It's not difficult to put together a simple page with two text boxes and a button, then make a web service call to verify user credentials and return an object containing user context. However, there are a couple of things to consider.

Push Notifications Opt-In
Push Notification Service (PNS) is a powerful tool that allows your server application to initiate communication with the client even while the client isn't running. There is no equivalent functionality on the desktop or in web applications; it is one of the unique features of the mobile client. I'm sure any enterprise system could use PNS, and in my next post I will show how to implement it. Normally, you would register a user for push notifications as soon as he or she authenticates. However, according to Windows Phone 7 Application Certification Requirements, the application must ask the user for explicit permission to receive a toast notification. Once the opt-in is obtained from the user, it can be saved in isolated storage settings. Below is a code snippet that checks settings and redirects user accordingly:

   NavigationService.Navigate(
      IsolatedStorageSettings.ApplicationSettings.Contains(Constants.Settings.CanUsePNS)
         ? new Uri(Constants.Urls.LandingPage, UriKind.Relative)

: new Uri(Constants.Urls.PNSOptInPage, UriKind.Relative));


Session Management
Authentication usually implies a time-limited user session. Unlike ASP.NET, which is a server-side platform, Silverlight doesn't provide session management features out of the box. My recommended approach for mobile application is to implement a dual session management mechanism along these lines:

1. Client ask user for a preferred session duration (not to exceed a predefined system limit) before login
2. Client successfully authenticates, and server returns a unique session token (a GUID, for instance)
3. Client keeps session state in the isolated storage
4. Every time the application is activated, it checks if session length has exceeded timeout
5. Every time the client makes a webservice call, it includes the session token as a parameter. Server uses it to validate the session and optionally create an audit trail of user activity.

Restoring Session State On Activation

When application is running, session state is stored in a public static property of the App class (App.xaml.cs), for example:

   public static UserLogin CurrentUser { get; set; }

However, the value goes away when application becomes inactive (again, this is unique behavior of mobile clients) and we need to restore it as part of reactivation:

   1:  private void Application_Activated(object sender, ActivatedEventArgs e)

   2:  {

   3:      if (AppController.CurrentUser == null)

   4:      {

   5:          using (var store = IsolatedStorageFile.GetUserStoreForApplication())

   6:          {

   7:              if (store.FileExists(Constants.Files.UserLogin))

   8:              {

   9:                  using (var file = new IsolatedStorageFileStream(Constants.Files.UserLogin, FileMode.Open, store))

  10:                  {

  11:                      var serializer = new DataContractSerializer(typeof(UserLogin));

  12:                      AppController.CurrentUser = (UserLogin)serializer.ReadObject(file);

  13:                  }

  14:              }

  15:          }

  16:      }

  17:  }

(to be continued)

Mobile Enterprise Application. Step 1: General Architecture

I decided to follow up on my previous post and write a series of more practical articles to illustrate various decisions that are specific to mobile enterprise applications. Being is Microsoft platform developer, I am going to stick to Windows Phone 7 in this series. This first blog post discusses general architectural issues.

Choosing Client Technology
WinPhone 7 supports two development paradigms: Silverlight and XNA. The latter targets game developers, providing them with game loop, sprites, and stuff like that. Silverlight, on the other hand, is a subset of the traditional desktop UI platform (WPF). It has a rich set of controls plus the ability to do cool visual effects. Silverlight is a natural choice for a mobile enterprise application.

Relative Merits of MVVM
Model-View-ViewModel design pattern has a widespread adoption in the XAML world, including Silverlight. The question isn't whether or not MVVM can be used in WinPhone 7 applications (it can) but whether or not it should be used. On the negative side, MVVM makes your app larger and slower, which is no small thing on the mobile device. On the positive side, it provides the separation between user interface and logic which is extremely beneficial in two scenarios: unit testing and sharing projects with a designer.

Unit Testing
Generally, I am a big proponent of unit testing - I believe they are essential to building high-quality maintainable programs. However, WinPhone 7 unit testing is a little wobbly at the moment. Test framework built into Visual Studio doesn't support phone applications, so we are supposed to download Silverlight Unit Test framework, which is included into Silverlight Toolkit. Only problem is that latest version of the toolkit supports Silverlight 4, but not WinPhone 7... I'm sure eventually Microsoft will sort everything out, but for the time being it's probably best not to concentrate on unit tests.

Sharing Projects With Designer
If your project team has a dedicated designer who actually works with the same project as developers, MVVM provides a nice clean separation of concerns. If, on the other hand, you do not have a designer, or the one you have prefers exchanging images and screenshots with you over email, MVVM doesn't really give you much of an edge.

Choosing Server Technology
We should try to shift as much logic as possible to the server. This makes sense from several points of view. First of all, mobile client doesn't offer a lot of processing power while server side can be very scalable. Second, if you support more than one client platform, it helps to have as little code to port as possible. Third, your business logic is your intellectual property, and it is definitely more secure on the server.

SOAP or REST?
When it comes to building web services, WCF allows the choice between SOAP and REST. On the high level, SOAP is really a remote procedure call mechanism which can support sophisticated logic and advanced  security requirements. REST, on the other hand, operates with a simple set of HTTP verbs and is therefore better suited for simpler CRUD-type logic.

Secure Communication
Mobile clients communicate with web services over 3G or WiFi networks, which makes them vulnerable to security attacks (open public WiFi are especially fertile ground for packet sniffing - read more here). It is therefore essential to encrypt all messages, not just those related to authentication. Using SSL protocol for communication is a good start.

(to be continued)