Back to Part II
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)
Reusability into Modern 0 (rewrite) to 5 (works as is)
Technology option for easier migration:
Works well for validation and JQuery calls, less or no reuse for AJAX and navigation related tasks.
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)
Server side .Net code
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.
General ASP.Net MVC code
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
Windows Forms UI
There’s little to no translation between Windows Forms UI and Modern style apps
Windows Forms UI related .Net code
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.
General Silverlight code
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.
Windows Phone 7 aps
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.
General WPF code
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
Windows Phone 7 games
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.
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.
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.
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.
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 .
Update: Part IV
THE TOOLS DEPARTMENT free/trial tools for developers