In-Depth

Best Practices for Transitioning from ASP.NET to Windows 8 Development

One key change that will smooth your transition from ASP.NET to Windows 8 is to think like a designer from the outset.

• By Brandon Downing, Phillip Stewart
• 06/05/2013

Windows 8 is gaining traction in the marketplace and is forcing developers to adapt and evolve. Along with the adoption of new technology come lessons and steep learning curves.

Here, we seek to provide insight into best practices and issues to be aware of when making the shift to Windows 8. When developing Windows Store apps, language options include HTML5/CSS3, DirectX/C++ and XAML/C#. If you are a .NET Web Forms developer, the XAML/C# option usually makes the most sense, so that will be our focus. Let's get started.

Pre-Development
We'd like to preface this article by noting that the best coding practices stay the same regardless of what you're developing for. Strategies such as including a separation of data layer, business layer and UI are just as important in Windows 8 as they are in an ASP.NET framework. Such strategies should be kept in mind throughout the course of this article.

As a general rule, it's important to briefly research what features your application requires and how you can achieve these functionalities. This will add significant value to the development process.

We found the following tools to be of great use in our line-of-business (LOB) application: the MVVM Light Toolkit and SQLite.

Microsoft also has a great (and elaborate) guidelines page that you should definitely review to make things easy during and after development. Another good resource is from MSDN Magazine about the Model-View-ViewModel (MVVM) pattern in Windows 8.

During Development
The following key changes during the development lifecycle are worth noting.

• UX Change Implications: Let's discuss controlled versus evolving environments. In the controlled Windows 8 environment, gone are the days of Chrome tools, varying interpretations of styles across browsers and contained style resources. Simply put, Windows 8 requires you to backtrack.

One could argue this provides a much more reliable programming environment. Windows 8 uses style patterns, single-style approaches and layouts that resemble HTML table-based layouts from the early days of the Web. This requires you to think more like a designer than ever before. Microsoft's emphasis on "fast and fluid" design is relevant in every piece of an application's lifecycle, not just the design phase. You must understand how the presentation layer works and have a good handle on XAML. This requires learning the new application lifestyle and incorporating it into your development.

ASP.NET Web Forms Versus XAML: Anyone who's familiar with ASP.NET Web Forms will have no problem picking up the similar lifecycle of a Windows 8 page. However, one major difference worth noting is navigation. Web browsers rely on the Request/Response model to pass information between pages:

void BindCaseData()
{

  int caseId;
  
  if (!int.TryParse(Request.QueryString["CaseId"], out caseId))
  {
    // Do something about missing caseId
  }
  else
  {
    // Bind case information for the page
  }
  
}

The Windows 8 integrated LayoutAwarePage abstracts this communication, making page navigation simple: Specify the page and wait for the magic to happen. The page is then added to the top of the "stack" of pages. When you return to the previous page on the stack, you can reload any data saved in your page's Page State dictionary, as shown in Listing 1.

protected override void LoadState(object navigationParameter, Dictionary<string, object> pageState)
{
  int caseId;
  if (pageState != null && pageState["CaseId"] !=null)
  {
    // If Page State is not null then the page has 
    // already been initialized and data should be loaded 
    // from the Page State dictionary
  }
  else
  {
    // If Page State is null then this is the first 
    // time the use has gone to the page and the caseId
    // needs to be parsed from the navigation parameter
  }
  if (caseId !=0)
  {
    // Bind case information for the page
  }
  else
  {
    // Do something about missing caseId
  }
}

For those familiar with the Model-View-Controller (MVC) design pattern, the commonly used MVVM pattern in XAML applications will be of interest. MVVM encapsulates the basic ideas of MVC, but utilizes a view model (rather than a Controller) to assist in data binding. By using a view model and clever use of the two-way binding ability of XAML pages, you can instruct your converters to display data on the screen in a multitude of ways.

A basic example is that of a given DateTime object. In this example, by binding the object (called Date) and specifying a converter (called DateToDateStringConverter), you can see how these converters take in one object and return another in a loosely coupled fashion. The Date object binds to the TextBox but uses the DateToDateStringConverter to convert the DateTime to a readable string:

<TextBox Text="{Binding Date, 
  Converter={StaticResource DateToDateStringConverter}}" />

The converter takes in the DateTime object and returns it as a string value in a specified format:

public object Convert(object value, Type targetType, 
  object parameter, string language)
{
  var item = value as DateTime?;
  if (!item.HasValue)
    return string.Empty; 
    
  return item.Value.ToString("MM/dd/yyyy");
}

Navigation services simplify switching between views while using the MVVM pattern by keeping track of stack information and allowing loose coupling for view models. You can pass data between two view models during navigation a number of ways, but our preference is through messaging: If you set up your new view model to initialize after receiving navigation data, you can begin to initialize the view model. After initialization, the view model's bindings will kick into effect and your view will be populated with data.

For example, the MVVM Light Toolkit comes with a lot of built-in functionality. However, for our purposes, we overrode the ViewModelBase into an Abstract PageViewModelBase. The PageViewModelBase abstraction acts as the DataContext for the views. As you can see in Listing 2, there are only a few slight modifications to the constructor to allow the view model to register itself to receive a message, as well as an abstract method InitializeViewModel to receive any navigation parameters through the message.

/// <summary>
/// Base Constructor to initialize services 
/// </summary>
/// <param name="dataService"></param>
/// <param name="navigationService"></param>
protected PageViewModelBase(IDataService dataService, 
  IPageNavigationService navigationService)
{
  Messenger.Default.Register<object>(this, this.GetType(), 
    true, InitializeViewModel);
  
  DataService = dataService;
  PageNavigationService = navigationService; 
}
/// <summary>
/// Method that gets called when the view model 
/// receives the parameter message
/// </summary>
public abstract void InitializeViewModel(object navigationParameter);

Post-Development
The following post-development changes require extra attention compared to the traditional Web application format.

Offline Syncing: Internet applications are either available or not available. However, with Windows 8, this isn't the case. Windows Store apps need to be available 24x7 to allow users the ability to continue working on processes regardless of their Internet connection. Functionality is key, as are offline capabilities.

Offline capabilities bring you into a new world of data synchronization with which you previously may not have had to deal. With local storage for data, synchronization with databases and offline syncing, your development methods need to accommodate every possible scenario.

Many Windows Store apps mirror their Web application counterparts, but LOB applications also demand the need to work in an offline environment. When storing a large amount of data, libraries such as SQLite come in handy, as do background tasks to determine when the user has come back online. This helps sync up the database environments.

Side Loading Versus the Windows Store: Deploying Windows Store apps differs from deploying Web applications. With Web applications, you can configure IIS and use config files for application-level settings. As soon as IIS is pointed to the code directory, it can be live. In Windows 8, you have two options for distributing your app to users: Side loading (primarily used for LOB apps) and the Windows Store. There are some similarities between the two to declare capabilities and modify settings; these include Web services that point from development URLs to their production equivalents in Visual Studio before deployment.

There are tangible benefits to deploying a side-loaded LOB app compared to a Windows Store consumer-facing application. Deployment is often more streamlined because it doesn't involve certain requirements from the app store or approval processes.

But what happens when you have no choice but to deal with the Windows Store certification process?

In this case, we suggest that you schedule a consultation with a Microsoft representative at any point during or after development. The representative can provide you with feedback and insight into issues you might run into when submitting your application. Just setting up your Windows Store account and figuring out how to submit your first application will take time, and the actual submission process once in the Windows Store can easily take a week -- and that's assuming your app passes certification on the first try.

Application Updates: With Web applications, once all the QA is performed and the changes are ready to be deployed, you should stop the app pool and push the latest changes live. In an extreme situation, this may require an IIS reset (this makes any update to the application current for all clients).

With Windows 8, you need to account for the fact that updates are not as easy as pushing changes live. If you plan on side loading an application, your organization's IT team will need to configure policy to deploy "trusted" applications to end users. If you're working on a Windows Store app, any update will be scrutinized in the same manner as the initial release. This is different from Web application updates because it's up to the user to update the application. You'll therefore need to account for the fact that there may be users who are still working with an older version of your application.

Key Takeaways in Transitioning from ASP.NET to Windows 8

1. Developers need to act more like designers than ever before. "Fast and fluid" requires attention throughout the development lifecycle. You need to be wary of how items present themselves.
2. MVVM development is replacing Web Forms-based site design. Anyone who has used the MVVM or MVC pattern will tell you the standard ASP.NET Web Form is a dying art. Using strategies learned from Windows 8 development and porting them back to ASP.NET will help show you not to rely on tightly coupled objects, and teach you to force abstraction to ensure a unified and testable work area.
3. Local storage is a necessity for usability. The user should never be able to tell if an application is online or offline. A smooth transition between the two is the difference between the age of Web applications and the paradigm shift of tablet applications for business.
4. Bindings help eliminate tightly coupled data bindings. Anyone unfamiliar with the XAML syntax of bindings might disregard them as something unnecessary. However, with the power of the binding keyword, you rarely even touch the codebehind, as your objects do all the work for you.