Silverlight, HTML5 and the state of RIAs

4 11 2010

So you’ve obviously heard about these statements regarding Silverlight – insinuating that Microsoft is going to abandon it in favour of HTML5 due to revelations at PDC2010. If you haven’t, here are the main links in this debacle:

One issue I have with this hype about MS abandoning Silverlight is that most of it is based on the following statement from MS, in an interview by ZDNet (see first link):

Silverlight will continue to be a cross-platform solution, working on a variety of operating system/browser platforms, going forward, he said. “But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.

Inferring from this that MS is pulling the plug on SL is pure hype. I daresay MS haven’t helped their cause by being more tight-lipped that usual over the issue, but PR has never been their strong suit.

Unfortunately, it tends to be people like MG (the TechCrunch article author) who jump on the sensationalist bandwagon. It may turn out that MS will eventually abandon Silverlight, but I seriously have my doubts. I honestly believe that they logically see their original goal of true “reach” severely hampered; what with iOS and Android now thrown into the mix since conception. Adobe haven’t done much differently – except that when they announce their HTML5 strategy (as they did last week at MAX), it’s to thunderous applause; they’re obviously much better at crowd-control.

Both of the big boys seem to understand that they cannot expect their platforms to be a presence on every single device, and they need a complementary strategy to remain viable to us developers – enter “HTML5”.

I can understand the apprehension amongst the RIA community – the religious connotations that permeate most of the Flex/Silverlight debate (RIA evangelists anyone?), would make one think we’re arguing about our very souls, rather than simply a career choice. Even if both Flash and Silverlight died tomorrow, we’d be in a pretty comfortable position to shift allegiances to any other rich client technology out there.

Let’s face it – RIAs are not going anywhere. The users have spoken.


Blogging on InsideRIA

25 06 2009

I’ve started blogging on InsideRIA recently, and I must say – I’m enjoying it.

Latest post is on Flash & Silverlight.

Speaking at the first InsideRIA Conference

4 06 2009

In August this year, O’Reilly and 360 Conferences are running the first InsideRIA Conference.

What appeals to me about this conference over so many others is:

a) It’s not about the fluff, it’s developer-to-developer; and 

b) It’s platform agnostic.

As such, the topic I’m speaking on is what the two main players in the RIA sphere are doing within their markup languages.

State of the Union: XAML and MXML in 2009

An honest and objective look at the two markup technologies dominating RIA development today. There is something for both Silverlight and Flex devs to learn from each other, and this is a discussion that is sorely lacking in the RIA industry at the moment. Topics covered include Styles, Resources, Databinding and Layout.


InsideRIA Speaker







Come along! I always enjoy a yarn about RIA. 

Silverlight for Flex developers: Part 1 – Basic Layout in Blend

31 03 2009

So, to put my money where my mouth is, I’ve finally starting to approach Silverlight from a Flex perspective.

Personally, I develop in both .NET and Flex/AIR. Last year, I saw this example  by Robby Ingebretsen and decided that there was more to Silverlight than meets the eye. 

Part One: Basic Layout in Blend 3

I’ve decided to start this series with layout and components. Now, I’m making a few guesses and assumptions as I go, so I encourage anyone who notices discrepancies to comment away.

First off, Download Expression Blend 3 Preview. It’s free until September 09, so go get it. (Blend is actually a WPF application).

Second, create a new Silverlight application.

Now, having a look inside Blend take a gander at the Layout containers:

Blend Layout Containers

Layout Containers

  • Grid – interesting component, seemingly very well used, not really comparable to Flex Grid as it is composed of invisible rows and columns and allows customisable anchoring and scaling within each cell.
  • Canvas – this is like the Canvas in Flex, an absolutely positioned layout container.
  • StackPanel – think Box. It’s the same idea. Layout by stacking children either vertically or horizontally. 
  • ScrollViewer – Scrolling is not something inherit to all containers like it is in Flex 3. It is something you add to a layout component if you choose. Flex 4 (Gumbo) seems to be going this way as well.
  • Border – As with scrolling, bordering isn’t native to containers. It needs to be added in also.

Collapsed Visibility

Something to note here too is collapsed visibility. A nice feature of XAML that Flex has yet to implement . Say you have a Flex VBox with 3 buttons and you wanna remove a button, you’d use either a ViewStack or a State, right? (or maybe actionscript if you were keen)  – in Silverlight, you can set visibility to Collapse to achieve the same thing.

Anchoring & Margins

Essentially, components can either use  a margin to determine how wide and high they are or use alignment + width and height. The latter must be placed in a Grid/ScrollViewer/Border and then using both the width/height and the HorizontalAlignment and VericalAlignment tools to lay them out.

If you opt for the Canvas container instead, you then use the typical top, left and z-index to layout the items.  

Attached Backgrounds

Another nice feature is how the background can be easily customised. For example, try out the Gradient tool and apply it to any container (or component for that matter – like shapes, text or buttons). 

Gradient Tool

See the XAML? (switch to Split view). See how applying the Gradient tool to a


  • Grid goes under <Grid.Background>
  • Button comes under <Button.Background>
  • TextBlock comes under <TextBlock.Foreground>

This is similar to accessing the graphics property of any UIComponent in Flex. However, the obvious advantage here is how easy Expression tooling makes applying gradients to any object.

Rich clients (Flex/AIR/Silverlight) & LINQ : data across the pipe

19 03 2009

I’ve blogged before about Flex & LINQ, but I’m always learning new things, and I wanted to share some of my most recent findings.

Note: this article focuses on Flex & LINQ, but it could as easily be applied to Silverlight & LINQ as well. Silverlight 3 is set to merge client & server with .NET 4.0, but I believe the issue of how much and when to send data between client & server will continue to be relevant.

First off, why LINQ?

  1. With LINQ on your server layer, you can avoid having to write your server value objects – LINQ to SQL will do that for you from your DB schema – allows you to quickly updates these objects if your schema ever changes (and let’s face it, it will). NOTE: unfortunately, there is no free & easy way to sync your LINQ to SQL context to your schema in VS2008).
  2. You can put all your SQL as strongly-typed code in your DAL rather than having to call the DB to do it via stored procs, which decouples your DB from your application, allowing you to switch databases if you ever wanted to, and keeps all your server code in one place. 
  3. Cleaner and shorter code – easier for you, easier for other developers to understand (as long as they understand LINQ 🙂 )

So, if you’ve decided to take the LINQ option and your a Flex or AIR developer, then there is good news. 

Products such as WebORB.NET and FluorineFx both support .NET 3.5 and will allow your Flex application to send Remote Objects back and forth between the two. Yes you could use Web Services to do communicate with the server, but I’m assuming you’ve read up on the performance benefits of remoting and AMF vs Web Services, and you’re opting for speed.

The question is however, how do you do it?

The LINQ to SQL tool (I’m not going to mention the ADO.NET Entities tool, which is more feature rich, but a touch more complicated) creates you a data context as you know. This remembers the actions you perform on your objects and will propagate the changes back to the DB when you “SubmitChanges()”. However, when you’re working on the Flex/.NET model, you’re now using LINQ on an middle-tier (or even an n-tier) application, and that changes things.

What changes is that the “context” will be a new instance between each request (unless you use session access to the RemoteObjects, which I won’t get into here). LINQ won’t know that you changed something outside this context, and so to Update an object in the database you will need to “Attach()” it back to the current context to save it, along with it’s original but from a new  context. (See examples below).

Now, there are plenty of articles out there on LINQ in the middle tier and LINQ with n-tier, so I won’t reinvent the wheel. What I will do is talk about strategies on how to leverage LINQ in your Flex app, and how to synchronise data.

Let’s take a think about possible methodologies for sending/receiving related object data from server to client:

  • Safety method: take a little save a little
  • Hungry method: take a little save lots
  • Greedy method: take everything save lots
  • Thrifty method: take everything save a little

I’ll use the following example to illustrate the different methods:

Example Schema


Safety Method

The safety method is a simple-to-follow, clear 1:1 system  – load an object when you need it, and load the associated objects as you need them. When you save data back, call the server with either one or a collection of single unrelated objects. You rely on your foreign keys to do all the loading.

All associations within the LINQ to SQL designer (DBML) need to have INTERNAL access, to prevent them being sent to the client, and so that you can still use them within the server code. 

For example: Your client wants the list of projects? It loads them simply via LINQ. Client wants the project’s list of Companies? Load them via the ProjectID. Need to save a Company, send the server the Company object with an associated ProjectID. 


Hungry Method

The hungry method involves retrieving just the data objects you require at the time and building up the object model on the client side, eventually sending back an object with related objects. This means you don’t have an excessive number of save calls back to the server, and you don’t rely on the foreign key, you rely on the attached object.

For example:   You may want to load all Projects within the system via LINQ, but don’t want the associated Companies, Employees or Suburbs. You then want to create a new Project and create Companies, Employees. You then call one Save() method to save the new Project, and let LINQ create the entire collection of Company and Employee records.

Now, by default, LINQ will try to send you all the related Companies, Employees and related Suburbs when you ask for the list of Projects.  You have two main options to avoid this:

  1. Change the ACCESS of the association(s) between parent and child within the DBML (LINQ to SQL) editor to INTERNAL. This means only inside the DLL could you access this property.
  2. In your server DLL, NULL any related properties before returning the data to the client. (Literally: project.Companies = null).    

Do you see the problem? Option 1 is the obvious choice but then it means you couldn’t actually send the data back to .NET because if you tried to send a Project back with Companies attached, .NET would say that Project doesn’t have the Companies property as the association as it is internal (and the exception happens during unmarshalling on the server, handled by either the WebORB or FluorineFx DLL).

The Hungry method starts to become a real issue with visibility, and unfortunately, the easiest is to follow option 2 above, which is not a good solution in my opinion.

NOTE: When saving back to the server, do NOT send back both an associated object and an associated foreign key. This will cause .NET to except. EG: If you were to save a Company with an attached Project, you couldn’t also send back Company’s ProjectID (the FK), .NET wouldn’t know which association to use. 

So, in your client code, either remove the Foreign Keys completely from the value object, or use a property getter only to get the foreign key from the association object.


Greedy Method

The greedy method is expensive. You are always sending and receiving all (or a lot) of the data in a single call. The advantage is, less trips between the client and server, and minimal client & server code (one Save method to do everything!).

As you can imagine, debugging the Save method can be a headache – as debugging LINQ usually is 🙂 

Now, to Update an object under the greedy method is tricky yet fun. You need to Attach() this new object to the context, along with it’s original from yet another context. 

For example: You want to load all Employees and their Suburb plus their Company and it’s Project. If you wanted to save it back, you’d need to attach it back in. 

Employee SaveEmployee(Employee e) 
  DataClassesDataContext context = new DataClassesDataContext();

  //if is Update
  if (e.EmployeeID > 0) 
     //need to attach Employee with a NEW INSTANCE of the DataContext
     Employee oldEmployee = new DataClassesDataContext().Employees.Single( p => p.EmployeeID == e.EmployeeID);

     //now attach it
     context.Attach(e, oldEmployee);
  return e;


This can get even tricker when you’re attaching objects with children which already exist. It can require going through the children and testing their Primary Keys using the method above.


Thrify Method

The thrifty method involves receiving all the required data, and just sending back the minimal amount of objects back to the server for a successful save. 

To prevent data being sent back to the server once it is already in the Flex client, requires the use of the Flex metatag: [Transient]. To use Thrifty, we need to rely on Foreign Key associations as LINQ will use the FK on the insert  (just like saving in the Safety method). The advantage is that you have complete control over anything being saved into your database, which can be a real advantage in a intricate & lengthy project. 

Generally using this method, you would need to recall all of your data again, as some associations have been modified. You can try an sychronise these on the client, but it can get VERY tricky. At the very least, you’ll need to return your saved object to get it’s ID if it was just inserted.

For example: You want to load all Projects from the system, but when you save a Project, you don’t t send back it’s Companies, this property is Transient on the client and doesn’t get send back to the server. If you wanted to save a Company, you’d send back a Company object without the associated Project object, but WITH the ProjectID Foreign Key.


I personally use a combination of the Thrifty and the Greedy method, deciding when I want to send all the data back, and when I just want to send back an individual object. It still means however, that I need to reload ALL of my data again after a successful save of some object. 

The most important things to remember is attaching to a new context, and not sending both a foreign key and a related foreign object back to the server simultaneously – this upsets LINQ. 

More examples and further investigation to come…

Silverlight vs Flex

16 02 2009

The Silverlight vs Flex argument is hillarious!

We’ve got a statement from Adobe’s CFO here on Silverlight. Personally I think that the CFO wasn’t the best person to comment on Silverlight, but hey, maybe we got an insight into Adobe’s non-censored attitude to Silverlight. 

We’ve got a response from Tim Sneath, a Silverlight evangilist from Microsoft.

We’ve got a debate with an MS evangilist vs an Adobe evangilist. (To be fair to Silverlight, the MS guy seems like he’s a fish out of water. He starts off with a great argument about competition making us better developers, and ends up floundering).

If you ask me, Adobe needs to fix the perception that most developers have that Flash simply sux. 

The problem is, that for years, the Flash platform was only accessible to those freaks who understood and lived in the four dimensional world of Flash. Trying to code on multiple layers with inherited objects in respect to time and still understanding  scope was, and still is, a nightmare

 I think many web developers have poked their noses into Flash – and many developed a natural distaste for it. Those that tended towards design sometimes learned to love it (and we learned to hate them for polluting the web with horrendous Flash websites that were inaccessible and useless). Then came Flex, at a time when web apps and Web 2.0 was the wave of the future. Macromedia released an SDK that finally made the power of Flash available  (“leveragable” in biz speak) to developers who wanted to use it.

Microsoft, on the other hand, have wowed developers ever since they took Java made .NET.  Managed code – with the ever evolving C# – allows us  developers to write pure object oriented code from web sites to windows applications. And thank god. I mean, I don’t have much interest in OS programming or the kernel. I’ll let others specialise in that. I’m interested in engaging, interactive applications, in whichever form they take.

Let’s get back to basics. Adobe specialises in cross platform solutions. Microsoft have a vested interest in Windows. 

Adobe has flash advocates (I’m using this term from now on) who were pre Flex (ewww), and post Flex (like me). Microsoft has .NET evangilists. Actually, I’m a good example, cause I’m both. I trained in Computer Science at university. I worked mainly with Java on Solaris machines. When I finished uni, I wanted to write software that people would use. I started with the web because of it’s reach, and have been focused on it ever since.  So now I write Flex and AIR apps that interface with .NET, and I’m happy to look at other RIA technologies as long as they

  • Compile (I’m sorry, but I like the portability of compiled code); 
  • Allow for OO programming (Yes, AS3 is OO – close enough anyhow); and
  • Are portable; and
  • Are accessible.

I think the issue between Flash & Silverlight is all this use of “Company X” evangilist business. Too many religious connotations. No wonder there’s so much passion in this argument. Everyone’s drawing lines in the sand. WTF? Anyone heard of software architecture? The goal is to understand as many technologies as possible to create the best solution for the client – whoever they may be. The platform is just a means to an end. We’ve got to constantly weigh up the options from all sides to create the right system at the right time.  

I’m giving myself a task. Over the coming months, I’m going to investigate Silverlight further, now that v2 allows me to code the frontend in C#, and because .NET 4.0 is looking to integrate the client and server within the single code base. As I go through it, I’m going to post my findings here, for those who want the quasi-objective truth.

Silverlight Client to Server Remoting

11 02 2009

Being the Flex/AIR to .NET developer that I am, I find Silverlight curious to say the least.

Initially I had assumed that Silverlight 2, as it was deployed inside an ASP.NET side, would automatically handle remote objects from the client to the server. This would alliviate the developer from having to write two classes for her value objects (one on the client and one on the server). Moreover, it would minimise the amount of setup time to get going.

Turns out, it doesn’t. Not in .NET 3.5. You’ve got the options of using Web Services or solutions like WebORB .NET for Silverlight (using AMF).

Posing the question on Twitter today, I was sent the following link from Tim Heuer from the Silverlight team:

So, it seems the future of Silverlight, within .NET 4.0 and Visual Studio 2010 is a seamless integration from server to client via the one code base.

Something Mr. Cool (the speaker from said video) didn’t mention in whether or not the server would require the “Dublin” addition to IIS. This seems to be the way .NET 4.0 is achieving the communication from Client to Server. I think I need to test drive VS2010 to be sure.

The code to get the communication between the client and server is fairly bloaty – and seems a bit hackish at this stage. I get the impression MS are trying to quickly increase the functionality of Silverlight before too many people invest in the Flex Framework. MS are down in the fight as Silverlight currently can’t escape the browser unlike AIR  (WPF can too but it’s Windows dependant). I guess they want to entice the developers via integration rather than the software architects by reach.