Поделиться через

Windows Store Development–Retrospectives (Part III)

  • Статья

Back to Part II

 

imageWhat About Skill and Code Reuse?

In order to help clarifying some myths and truths around code reuse from different technologies into Windows Store applications, I will layout some of the aspects of porting code to/from some of these platforms.

The table below depicts some of the aspects of porting code to/from some of these platforms: (I use Modern style and Windows Store interchangeably)

 

Platform

Technology

Reusability into Modern 0 (rewrite) to 5 (works as is)

Issues

Technology option for easier migration:

ASP.Net

HTML

3

Requires stripping/changing all the ASP.Net controls into pure HTML and JavaScript, taking code behind tags away. Not trivial.

Modern HTML5/JavaScript application

ASP.Net

JavaScript

3

Works well for validation and JQuery calls, less or no reuse for AJAX and navigation related tasks.

Modern HTML5/JavaScript application

ASP.Net

Session/Application state

0

The ASP.Net application model has little in common with Modern apps. ASP.Net works based on http requests and responses where Modern apps HTML is stateful.

N/A (No reuse achieved, therefore the choice is irrelevant in this context)

ASP.Net

Server side .Net code

4

Most of the issues are related to the eventing system (i.e. converting ASP.Net events into Modern style), references to controls and properties, navigation related statements and dependency on the http stack. It really depends on how well the tiers have been separated.

HTML5/JavaScript application

ASP.Net MVC

General ASP.Net MVC code

3

Similar to classic ASP.Net there are fundamentally different application architectures to be taken in consideration. Also, the inline server side code makes it yet more difficult, plus the new Razor syntax which has no corresponding element in Modern style applications

HTML5/JavaScript application

Windows Forms

Windows Forms UI

0

There’s little to no translation between Windows Forms UI and Modern style apps

N/A (No reuse achieved, therefore the choice is irrelevant in this context)

Windows Forms

Windows Forms UI related .Net code

1

Little translation between properties, validation and methods into Modern style. Even if there was an easier way to convert the UI into Modern style the outcome wouldn’t really be Modern app at all.

N/A (No reuse achieved, therefore the choice is irrelevant in this context)

Silverlight

General Silverlight code

4.5

Most of what is in Silverlight can be easily ported 1 to 1 to Modern style. The only question is whether the look and feel fits into the Windows Store design concepts.

Modern XAML/C#

Silverlight

Windows Phone 7 aps

4.5

The application certification guidelines for Windows Phone are not far from the ones likely in place for Windows 8 apps. The biggest impact would be at the UI layer, considering the differences around resolution and look and feel.

Modern XAML/C#

WPF

General WPF code

4.5

As it happens with Silverlight, most of WPF XAML can easily be translated to Modern style. The risk with WPF is if the application is making use of classes and APIs which might not be available within the Windows Store app model

Modern XAML/C#

XNA

Windows Phone 7 games

1

Although XNA can be ported to Windows, there is no Modern style Visual Studio template for XNA games. This would lead such an application to be built and deployed as a traditional Windows application rather than a Modern style app.

Windows XNA

   

Choosing between HTML and XAML

When discussing porting code to/from web applications and Modern HTML5/JavaScript projects, many aspects should be considered:

Modern applications can make use of several native API’s which are not available for web applications. Direct calls from JavaScript to .Net libraries, Win32 APIs, COM objects and the whole Win 8 application framework doesn’t work on web applications.

Also, the way Windows Store applications use JavaScript for doing data binding and rendering controls such as the grid is also likely going to be an issue on typical web applications. The reason is that the WinRT JavaScript files generated are drastically different than the common JavaScript files seen in standard web sites. Reusing a set of JQuery files can prove to be nearly impossible due to security and platform restrictions of the Modern app model. Of course there are common areas where reuse/migration from a standard web application into a Modern/HTML5 application can happen (i.e. CSS styles, many HTML elements and so on). But the main challenge on reuse/migration here is not so much on the libraries as it is on how the layers are structured in these applications.

Typically on web applications there is little separation between JavaScript, HTML and CSS. JavaScript is seen as a UI helper and often is mixed with HTML/CSS up to the same line of code. It is quite common to see JavaScript with HTML tags inline as string variables for building HTML elements as well as HTML with JavaScript inline to assist with the page functionality. Implementations like this can easily make the code more difficult to read and maintain but still are widely common in web applications.

But in HTML5/JavaScript Modern style apps, JavaScript is promoted from a UI helper programing language into the main application programing language. There is no “code behind”. There are no “server pages” because there’s no intrinsic http request/response model so nothing is processed on the server. Yes, web services can be created on a server layer and be called from there but there’s nothing even remotely similar to an ASP.Net execution model where the client executes a request, has server pages being processed on the server rendering HTML and returning that back in a HTTP response. The JavaScript which calls .Net libraries is sitting on the client with all the remaining code with it. So now we have JavaScript doing HTML rendering, validation, server side calls and potentially even local file access, business rules and many other roles that usually JavaScript doesn’t execute.

This raises a few questions: Was JavaScript designed for that? Will developers be able to differentiate that when structuring their applications? Will they clearly separate business rules, controllers, and UI helper functions from each other? This often isn’t an issue today because JavaScript hasn’t often been used that way, but this changes with Windows Store apps. And experience tell us that when JavaScript is used, typically layers are mixed (i.e. Web Service calls mixed with UI rendering code, validation and partial business rules all together).

By looking at these questions we can easily identify a risk, where the skills and background knowledge being reapplied between these two platforms might generate very mixed architectures, code difficult to read/maintain and prone to a few security risks. These are not necessarily new challenges but in consumer focused scenarios with small sized applications there is typically less architecture effort in separating layers which potentially increases this risk.

On the tooling side there will also be a few issues on the Modern style JavaScript/HTML applications. First, as JavaScript is an interpreted language, therefore typos are more likely going to cause problems at runtime that were not anticipated during build. IntelliSense will be limited and refactoring functionality (i.e. automatically find the definition of a method) will also be constrained. So Visual Studio will not run a very deep analysis during the build (compared to .Net). Areas like code coverage in tests is not be possible with JavaScript.

In Windows Store applications, visual animations become a more important feature. One of the “8 traits of great Windows Store apps” is being “fast and fluid” and most examples show transition animations, which greatly contributes to the visual experience. Although there should be plenty of references online for HTML5, building animations today is a much simpler task to perform on XAML. The tools for building animations on XAML have been there for longer and are in a more mature state. Will this change in the near future? Unlikely, but as the adoption on the HTML5 increases over time, tools will evolve with it.

As there is a significant market share of browsers which don’t fully support HTML5, web applications will have to be built with an if-then-else approach, delivering HTML5 functionality only if the clients support that. This contradicts the logical assumption that with better standards compliant browsers supporting HTML5, developers could finally be able to write once and run web pages, which used to be the topmost complaint on HTML 4/DHTML by developers.

All the points raised above are not to suggest that developers should avoid HTML/JavaScript Modern style apps but embrace it with a pragmatic approach. Some of the best practices that apply to ASP.Net MVC will likely apply to Modern style HTML5/JavaScript applications. For example, just as inline code should be kept to a minimum on ASP.Net MVC and JavaScript is not used for server side code, in Modern Style apps JavaScript should not be used for building the entire app but only to assist with the UI. Database access, business logic and everything else should probably stay as .Net, LINQ, Entity Framework and all the great technologies developers approve and have been using for years.

The decision then stays at the UI layer only, whether XAML or HTML will have the best fit. The code reuse table shown earlier in this document helps address this decision, as do the knowledge/skills of your team.

What About Starting Fresh?  

When code migration/portability from/to Windows Store apps and any other platform (i.e. web applications, Windows Phone 7, etc.) isn’t a concern, the decision remains mostly on the skills of the team. Developers should choose the platform they feel more comfortable with But that’s for Part IV Smile.

Update: Part IV

THE TOOLS DEPARTMENT
free/trial tools for developers

image

  • Think blue sky with Azure free trial

image

image

image