Joel Varty : Silverlight

Silverlight Databinding – The Observable Collection

joelvarty — Mon, 17 Nov 2008 23:19:22 GMT

If you’re coming from the ASP.Net world and you want to start building silverlight controls, databinding is one those things that works somewhat the same, yet somewhat differently from the standard DataSource, DataBind() world that you may be used to.

For one thing, databinding in ASP.Net is done in a stateless way – once that binding operation is completed, it’s a done deal and if you want to change anything, now you have to manipulate the underlying controls that were created as a result of the data binding, or else change the underlying data objects and call DataBind() again.

That’s what we are used to – but it’s certainly not ideal. Enter Silverlight and the ObservableCollection<T>. This is a generic list type that allows you to put any object into it. This list implements INotifyCollectionChanged, such that it specifies and event that automatically notifys an underlying container when anything in the list has changed.

So that’s step 1 – use the ObservableCollection for you business object collection. Take note that by default, a WCF service proxy class in Silverlight will use this type of collection by default.

Then, in your actual data object classes, you need to implement the INotifyPropertyChanged on your data objects – this will allow you to raise the PropertyChanged event whenever the state of you object changes to the point where you want to notify the underlying collection or container that the state has changed.

Remember too, that this stuff isn’t really “Silverlight” specific – it was originally designed for databinding in Xaml for WPF, but since Silverlight using Xaml and a subset of WPF, this is really just following along the same paradigm.

What does all this really mean?

It means that once you have set up your data collections and underlying types, you can now follow the normal databinding rules, but once you change the underlying data objects themselves, either by modifying the collection or a property of an item in the collection, then the UI object will be updated too. This will only happen when the BindingMode is done using OneWay (the default), or TwoWay. The OneTime binding mode ignores any changes to the underlying collections so you can safely change them later without worrying about your UI going all wonky (or which thread you are operating from).

Threading will become very important when you are updating in item in an ObservableCollection – you need to be aware of what thread you are currently running in and possible use the Dispatcher to make that change – since the Notifier events will bubble up to the UI synchronously from the call you are in. Luckily we can trigger the dispatch from an anonymous delegate, so we don’t need to make extraneous methods for these any more.

So that’s the basics of the underpinnings of data binding in Silverlight (and thus, in Xaml). I like that it follows a similar front-end markup/code behind model to ASP.Net, but allows us to take advantage of a stateful environment – especially for calling web service and REST APIs asynchronously.

More later – joel.

Silverlight 2 - Finally a version that can change the world!

joelvarty — Wed, 15 Oct 2008 13:10:12 GMT

Yes, folks - that title is not a joke. Silverlight can completely change how we think about the web.

We're not writing activeX controls anymore, we're not coding "ActionScript" on a "Timeline" - we're talking about something revolutionary here.

If you look at the underlying premises of Asp.Net - Markup with Code-behind, and how well it has been received by the developer community, then the same paradigm in the WFP world has been waiting for Silverlight 2 to explode onto the scene.

Why will it succeed? We've had 1.0 for awhile now, and it hasn't "changed the world." What gives?

This version brings "everything else" that 1.0 forgot.

We have actual layout managers

like StackPanel and Grid - we won't talk about how the Grid layout manager is compared to table, but is really quite a different of a table than HTML.
and a ton of Controls to work with and extend.

We have real language support -

C#, boys and girls. Go play.
And some other languages too. Whatever.

Cross Domain Network requests use the same policy file as Flash

Here's where being just like Flash actually matters - since so many people have this policy file in place to allow for cross-domain requests, using it in Silverlight really makes sense.
These networks requests can be truly asynchronous. Not "fake" asynchronous like JavaScript.
This doesn't compete with AJAX - it is just way better.

LINQ support.

This is becoming a staple of .Net development. I have stopped bothering to follow ActionScript, but I am fairly sure it can't do LINQ. If you are a Flash developer, and you want to do "real" developer, look long and hard at Silverlight 2.
This is demonstrated by Scott Guthrie in his blog tutorial on Silverlight 2.

We have actual TOOL SUPPORT (I'm getting more excited as I write this - calm down, man. Calm down.)

The Visual Studio 2008 add-in works like a charm. No problems reported from me except for a few Intellisense quirks. This is a far cry from the crashy crappiness that saw me flounder around with the 1.0 tools for about an hour before I decided to wait for 2.0 to get serious about Silverlight development.

The designer tools allow designers to be designers and developers to be.... developers

The code-behind model is supplemented with the style-templating mechansim that is not too dissimilar to Asp.Net skins, except it allow more declarative control over how and when certain properties (whether they be style related or Content related) can be set.

Download the add-on for Visual Studio 2008 here - you need SP1 for this, so get that first.

Scott's tutorial post series is here. Read this first. Then read it again and think about what it all MEANS.

My final thoughts:

This is the big chance for WPF development to finally supplant Windows Forms and take us out of the Visual Basic style of UI forever.

This means that all of the crappy-looking corporate apps that people argue bring so much legacy value to desktop, can finally be re-written in a way that doesn't stink, and in a way that doesn't exclude non-Windows machines.

We can "sort of" share code between Silverlight and WPF Applications.

Make this easier, Microsoft.
Go back in time and do this yesterday, then tell me how I missed this in the documentation.

Don't follow the examples when you see declarative event binding

This is my worst pet peave of Asp.Net and I have started seeing it in virtually every XAML demo app out there.
Declare your events in the code-behind, not the XAML markup, folks. Think about how hard it will be maintain code that has a ton of this event bindings - you'll insane with the ctrl-F to locate where your events are referencing, and then you'll wish you'd listened to me.
I'm guessing the exception to this is where a control that you want to bind an event to is inside a data-bound template. Then you're allowed to bind the event in the markup. I guess.

When will it take over the world?

In my opinion, as soon as everyone else realizes that the absolute BEST video streaming technology just got paired with the absolute BEST programming support is available in an a cross platform browser extension, this thing will take off big time.

I'll be putting it into my apps as soon as I can.

Rock on - joel.

The Ubiquitous, Mobile Web: The Final Frontier

joelvarty — Wed, 16 Jul 2008 21:10:40 GMT

The web works better when web sites are tailored to the capabilities of the platform.

That's a given, as far as I am concerned.

I have avoiding dealing with this issue in the past in terms of mobile devices in the hopes that the browsers mobile phones will eventually mature to point of approaching desktop capabilities. Also, I am sure that there is some amount of push back to browser quirkiness following the Netscape/IE browser quirk wars of the past decades.

But now, as I await delivery of an iPhone 3G, I wonder if I might be doing more to push development for the mobile platform in general.

For example, I have used the Opera 9.5 browser (a leaked beta :) on my HTC TyTN for the past few months and I am amazed by how fluidly and quickly it renders and zooms fairly complex web pages - even on a QVGA (320x240) screen. I am hoping/assuming that mobile Safari, which Opera is ostensibly attempting to surpass with it's mobile browser efforts, will be even more useful and amazing.

It does beg the question, though, about where the responsibility for the overall mobile browsing experience lies: the browser implementation, or the web developers themselves. As an architect, it makes perfect sense that we should design and build web controls that will degrade their functionality based on the mobile browser's known capabilities. This rarely happens.

Most web sites, in my experience, are envisioned by people who haven't had exposure to the Internet on the kinds of mobile browsers, like Safari and Opera, that actually make mobile browser worthwhile. That being said, it should also be noted that most web site are also envisioned as a set of features that must answer to features on competing web sites. Far from being able to think about what the user experience ought to be on a handheld platform, we often can't even escape the vertical market that we operate within.

So what is the answer?

Should a mobile web site come "out of the box" when a developer drops a custom web control on a page?

Should we be pushing for a second stream of mobile development to complement the "standard" mobile development?

Or should we just let the mobile device handle the page that was designed for the desktop?

Should Flash and Silverlight be expected to run in these environments?

At this point, do we even know what a "mobile device" mean? Does it include UMPCs, MIDs (Mobile Internet Devices), or the smaller laptops like the Asus EEE PC (and all of its copy cats)?

So many questions, and no answers.

What is silverlight good for (yet)?

joelvarty — Wed, 23 Jan 2008 19:09:00 GMT

I have just passed up my first chance to build a silverlight component into a website. It was a tough choice, since everyone involved generally agreed that Silverlight was a great technology and would add a ton of bling to the site.

That being said, it has to be noted that Silverlight does not have a good layout system in place, as it only uses the Canvas layout from WPF - no flow layouts, here folks! This means that you have to position every single element absolutely. And you have to code it in javascript. And there is not built-in project template for it in VS 2008 yet, so you have to jump through some hoops to get intellisense working for you.

That's not a good way to introduce yourself to a technology, in my opinion.

Here where I think Silverlight is actually a good technology to use:

Streaming video.

This is one of the main commercial uses of this technology at the moment, and it sure beats the pants of other streaming formats.
It would greatly benefit by better tools for encoding, but Expression 2.0 looks pretty decent so far (in beta).

Displaying vector graphics with small amounts of interactivity

Lets face it, you can code any amount of logic yourself into a Canvas framework, but the power of Silverlight is in its ability to reproduce WPF, which in turn is really only useful with its vector graphics capabilities, combined with the layour frameworks.
Until we get more of WPF to work with, getting more experience with XAML's in terms of more static vector objects is a good idea.

I can't wait for Silverlight 2.0, and I can't wait until we can all save each other oodles of time be coding Asp.Net controls that aggregate a whole wack of functionality into a simple tag that we drop into our sites and customize to our hearts content.

Stay tuned...