Since more and more people show interest for this topic/posts and I just discovered a question on Stackoverflow mentioning this blog there is no more room for excuses – I owe you a second part. So I will just start and see how far I can come this time…
Last time, I showed you that XAML which is rendered into beautiful UIs is just a XML dialect and that we can use this knowledge to transform it into another XML representation: (X)HTML.
There was just one problem: our browser does not know about any WPF tags but instead speaks div, span, etc… But with Polymer to the rescue we were able to teach our browser how to read, simulate and render XAML. This allowed us to reuse our existing Desktop UI and display it in a modern browser.
But this was just a cool side effect and not what we really wanted. I promised you more: write code once and run it everywhere (smartphone, web, mac, linux)
So where are we now? We have an application that is written in C# and a UI written in WPF. We know, that we can translate the UI into XHTML and render it in a browser with WPF.polymer.
We are here:
So the next question that we might want to ask is: how do we get the C# code onto multiple platforms? And there is an easy answer for this: with a virtual machine that runs on every platform. And this virtual machine is provided by the Mono project.
The stated purpose of Mono is not only to be able to run Microsoft .NET applications cross-platform […]. Mono can be run on many software systems including Android, most Linux distributions, BSD, OS X, Windows, Solaris, and even some game consoles such as PlayStation 3, Wii, and Xbox 360.
And even better news is, that recently, Microsoft declared that they want to move cross platform and want to open source code of their .NET framework!!
Why do we open source .NET Core?
There are two big reasons why we decided to open source .NET Core:
- Lay the foundation for a cross platform .NET
- Build and leverage a stronger ecosystem
Cross Platform Reality
Ok great! So then we are all set, right? Unfortunately not.
If you compare diagram 1 & 2 you will recognize some changes in color. That is because I wanted to make one thing clear: in order to run on multiple devices, both generated codes need a virtual machine. For the C# code it’s Mono and for the Web UI it’s a browser. So both parts are running in their own(!) encapsulated environment. What’s missing is the communication.
And this is not the only problem. In fact, it would be a bad idea to try starting a browser, then navigate on a page that displays the generated UI and start the code that drives the page in its own vm context. And for this reason, we need a way to merge both worlds first…
The Chromium Embedded Framework (CEF)
First things first, what is CEF?
The Chromium Embedded Framework (CEF) is an open source framework for embedding a web browser engine based on Chromium. It is a convenient way to add web browser control and implement an HTML5 based GUI in a desktop application […]
I want to repeat: “HTML5 based GUI in a desktop application” doesn’t that sound like a perfect fit for us? 😉
We are getting closer!
That was a lot of preparation work. And I wish I could tell you now “you’re good to go” but the tricky part has just started.
We need to find a cut in our architecture. And the reason for this is, that our UI is actually broken:
<!-- Play button. -->
<Button Content="Play" Click="OnMouseDownPlayMedia" Margin="5" />
<!-- Pause button. -->
<Button Content="Pause" Click="OnMouseDownPauseMedia" Margin="5" />
<!-- Stop button. -->
<Button Content="Stop" Click="OnMouseDownStopMedia" Margin="5" />
Chances are good that you have something in your UI code that looks like the markup in above listing. As you can see, UI often contains things like click events or commands. Without them, we only have a static mask. Interaction through event is what brings live into our GUI.
The code-behind file defines the UI behavior. Users can modify the state of the View with certain actions. Changes in state lead to changes in appearance of our View. And there are some patterns, guidelines and frameworks that even say that code-behind files should ideally be empty. All in all, there is not one right way to create GUIs. GUIs are damn complex. And Visual C# has some advanced mechanisms, running behind the curtain, that are hiding how markup and code-behind are wired up. It just works in our IDE. And this is the big problem now.
Because when we translate the XAML to HTML there aren’t these cool mechanisms. All the click events and commands are becoming attribute garbage. And even if it would be possible to keep the events and forward them to our C# backend we would end up with a weird architecture, huge latency issues and other problems.
Next time I will show you my C# to JS cross compiler and guide you through the steps, needed to reproduce my proof of concept. Moreover, I will go into more detail on how to cut your architecture and the role of MVVM.