Programmer Payback

Use Silverlight Reactive Extensions (Rx) to build responsive UIs

Tim Greenfield — Thu, 11 Mar 2010 19:45:19 +0000

If you haven’t heard of Reactive extensions (Rx) for .NET, it’s time to get familar. Rx is extremely cool and once you understand it, it will change the way you write client-side code forever. Instead of providing an overview of Rx, I’m going to urge readers to check out Pencho Popadiyn’s blog post, where he does a much better job of explaining it that I probably could.

Instead, I’m going to demonstrate one practical use for Rx extensions here in my 2 part blog. Yes, 2 parts! That’s how cool I think Rx is. And keep in mind that I’m only scratching the surface on the ways Rx can be used. Enough fanfair, let’s get started by building a super simple Silverlight app that updates a ListBox with and without Rx and you be the judge of which is better.

Let’s work backwards by looking at the end result first and then going over how to create it.

Click here to run

Download source code here

Now, here’s how it works…

Step 1: Download and install Rx for Silverlight (link about one page down on the right hand side).

Step 2: In your Silverlight 3 project, Add a reference to the 3 Rx assemblies: System.CoreEx, System.Observable, & System.Reactive.

Note: The 3 files only add ~70K to your .xap file.

Step 3: Create a function that returns a model. For this example, we’ll just have an IEnumerable as our model and I’ll toss in a delay between each item so we can exagerate the difference between Rx and non-Rx.

public static IEnumerable<string> GetModel()

    for (int i = 0; i < 5; ++i)

        System.Threading.Thread.Sleep(500);

        yield return "Item " + i;

Step 4: The standard way to put that model into our ListBox would be to assign it (the IEnumerable) to ListBox.ItemsSource. However, for the sake of an apples to apples comparison, I’ll manually loop thru my model and insert each item into an ObservableCollection that is bound to the ListBox.

//MyList.ItemsSource = GetModel();

var items = new ObservableCollection<string>();

MyList.ItemsSource = items;

foreach (string item in GetModel())

    items.Add(item);

Step 5: Rx magic time! First, I’ll write similar code as in Step 4 but using Rx…

var items = new ObservableCollection<string>();

MyList.ItemsSource = items;

IObservable<string> observable = GetModel().ToObservable();

observable.Subscribe(item => items.Add(item));

Instead of iterating through the IEnumerable, we create an Observable object from our IEnumerable using the .ToObservable extension method. Then, we subscribe to that observer which tells it to iterate over the collection and run our lamba expression for each item. Bottom line: same result.

Step 6: More Rx magic. Let’s use the power of multi-threading and get our model to be created on a background thread, while we add our items to our observable collection (in order to avoid an invalid cross thread exception). We just have to change the last two lines a little bit..

IObservable<string> observable = GetModel()

    .ToObservable(System.Concurrency.Scheduler.NewThread);

observable.ObserveOnDispatcher().Subscribe(item => items.Add(item));

Passing in NewThread to .ToObservable() causes the GetModel function to run on a new thread and .ObserveOnDispatcher() causes our Subscription callbacks to run through the dispatcher (therefore allowing us to update the UI). The end result is a UI left totally responsive while the model is manufactured on it’s own thread and each new model item appears as soon as possible in the UI.

This is certainly possible to do by running GetModel() on a new thread and calling Dispatcher.BeginInvoke for each item. Afterall, this is what Rx is doing internally for us, but I personally think the Rx code is much more readable and writeable.

Next to come: Combining M-V-VM, Rx, and unbuffered REST webservices for clean, easy, and hyper responsive applications that need to communicate with the server!

Cool demonstration of Silverlight VideoBrush

Tim Greenfield — Sun, 07 Mar 2010 19:21:44 +0000

Silverlight provides a variety of brushes that can be used to paint just about any area in your app: from text to shapes to borders. The most common brushes are for painting color and images: SolidColorBrush, LinearGradientBrush, RadialGradiantBrush, and ImageBrush.

However, today I paired the less common VideoBrush with an unusual visual element. Click below to see a demonstration of a fun and novel use of the VideoBrush in Silverlight:

Video Jigsaw Puzzle

Note: PuzzleTouch also now allows you to create your own video puzzles using .wmv or .mp4 files. All work is done 100% on the client! To create your own video puzzle, go to the Online Jigsaw Puzzles by PuzzleTouch homepage, choose “Custom Puzzle”, and have fun!

SuperStackPanel = Grid + StackPanel

Tim Greenfield — Thu, 25 Feb 2010 04:54:09 +0000

Here’s a new panel to add to your tool chest. It’s one I expect to use almost daily and save approximately 3.1 hours of typing over the next year. Hopefully you’ll find it useful as useful as I think it is.

What’s wrong with the built-in StackPanel:

You can’t get children to conform to the size of the panel. Imagine you want the following label and list but want the height of the Listbox to stretch or shrink according to the room available:

At first glance, a StackPanel would seem to be the natural choice for which panel to accomplish this. Afterall, you just want a linear list of two objects: a TextBlock and ListBox. However, unless you are willing to hardcode the size of the ListBox or resize it with code, with a StackPanel you’ll end up with:

Yuck! Clipping instead of a scrollbar. So how do you get the desired behavior?

Answer: Grid.

So what’s wrong with a Grid?

Grids take more lines xaml to create. Compare the StackPanel Xaml to the Grid’s above and notice the 4 extra lines of Xaml. Ok, not a huge deal but if you’re doing this every day like me, you start to get sick of creating RowDefinition and ColumnDefinition objects.
With a grid you have to explicitly define the order of the children. Adding the attached property Grid.Row is easy on your first pass but what happens if you want to insert a new row somewhere in the middle. You not only have to add a new RowDefinition, but you also have to remember to go increment the row number on all subsequent siblings. This is a pain and error prone because a sibling would potentially be defined in any order in the grid.

Wouldn’t it be great if you could get the best of both worlds?

What we really want here is a StackPanel that allows you to define the size of the children.

Welcome SuperStackPanel:

Just set the attached property StackPanel.Length to “*” to get a child to stretch.

In fact, SuperStackPanel lets you use all the same GridLength values you can use in a Grid (Auto, *, n*, and x):

Have I sold you yet? The nice part is that SuperStackPanel is completely compatible with a normal StackPanel. Just swap out your StackPanel for SuperStackPanel and everything will look the same because the default value of Length is “Auto”. Frankly, I’d love to see Microsoft expand the role of StackPanel to support this natively. Of course, until then, there’s SuperStackPanel.

SuperStackPanel is lightweight and simple to add to your project, just download the C# source code, add to your project, add the namespace to your xaml and away you’ll go. Enjoy!

Use Silverlight to resize images and increase compression BEFORE uploading

Tim Greenfield — Thu, 21 Jan 2010 06:21:04 +0000

I’m always looking for ways to take advantage of Silverlight to accomplish tasks that traditional web technologies can’t. Here’s one that will save you money, increase scalability, and improve your user’s experience…

Allowing users to upload images is becoming common place for many websites and applications today. Equally common is the fact that most cameras and phones today produce very large and high quality images. On the other hand, very rarely do you actually want a high resolution / low compression image sitting on your server; nor does the average user know or care enough to manually reduce the size of their image before uploading it to your site.

Therefore, unless you’re lazy or in “get it done” mode, you are probably going to want to shrink the image and even increase the compression on that image before storing it on your server. Doing so will result in faster downloads of that image which means lower bandwidth costs and a better user experience.

The typical (and only option for standard Javascript+HTML based sites) is to do the work on the server. But wouldn’t it be great if you could do this work on the client BEFORE sending it up to your server!? Doing so would 1) decrease the time it takes to upload the image in the first place, 2) decrease the amount of work required by your server; thereby increasing scalability of your site, and 3) decrease the bandwidth used by both you and your user; thereby saving you money.

Silverlight has your answer! Here’s how:

Step 1) Use the OpenFileDialog to acquire the stream that contains the bytes of the image.

OpenFileDialog openDialog = new OpenFileDialog();
openDialog.Filter = “JPEG Files (*.jpg;*.jpeg)|*.jpg;*.jpeg”;
if (openDialog.ShowDialog().GetValueOrDefault(false))
{
    using (FileStream stream = openDialog.File.OpenRead())
    {
        // now you have the filestream
    }
}

Step 2) Create a WriteableBitmap from those bytes using a ScaleTransform to shrink the image.

public static WriteableBitmap GetImageSource(Stream stream, double maxWidth, double maxHeight)
{
    BitmapImage bmp = new BitmapImage();
    bmp.SetSource(stream);
 
    Image img = new Image();
    img.Effect = new DropShadowEffect() { ShadowDepth = 0, BlurRadius = 0 };
    img.Source = bmp;
 
    double scaleX = 1;
    double scaleY = 1;
 
    if (bmp.PixelHeight > maxHeight)
        scaleY = maxHeight / bmp.PixelHeight;
    if (bmp.PixelWidth > maxWidth)
        scaleX = maxWidth / bmp.PixelWidth;
 
    // maintain aspect ratio by picking the most severe scale
    double scale = Math.Min(scaleY, scaleX);
 
    return new WriteableBitmap(img, new ScaleTransform() { ScaleX = scale, ScaleY = scale });
}

Note: I’m still investigating the need for setting the Effect property on your image control. While this code does not actually affect the user’s image, it is necessary to get this to work. Maybe a bug in Silverlight 3?

Step 3) Encode the WriteableBitmap object back to a Jpeg using FJCore and set your compression quality.

Stream Source = Encode(wb, 20);
public static Stream Encode(WriteableBitmap bitmap, int quality)
{
    //Convert the Image to pass into FJCore
    int width = bitmap.PixelWidth;
    int height = bitmap.PixelHeight;
    int bands = 3;
 
    byte[][,] raster = new byte[bands][,];
 
    for (int i = 0; i < bands; i++)
    {
        raster[i] = new byte[width, height];
    }
 
    for (int row = 0; row < height; row++)
    {
        for (int column = 0; column < width; column++)
        {
            int pixel = bitmap.Pixels[width * row + column];
            raster[0][column, row] = (byte)(pixel >> 16);
            raster[1][column, row] = (byte)(pixel >> 8);
            raster[2][column, row] = (byte)pixel;
        }
    }
 
    ColorModel model = new ColorModel { colorspace = ColorSpace.RGB };
 
    FluxJpeg.Core.Image img = new FluxJpeg.Core.Image(model, raster);
 
    //Encode the Image as a JPEG
    MemoryStream stream = new MemoryStream();
    JpegEncoder encoder = new JpegEncoder(img, quality, stream);
 
    encoder.Encode();
 
    //Move back to the start of the stream
    stream.Flush();
    stream.Seek(0, SeekOrigin.Begin);
    return stream;
}
Step 4) Send the stream for the new, potentially MUCH smaller Jpeg up to your server!

byte[] buffer;
using (Stream Source = JpgEncoder.Encode(wb, 50))
{
    int bufferSize = Convert.ToInt32(Source.Length);
    buffer = new byte[bufferSize];
    Source.Read(buffer, 0, bufferSize);
    Source.Close();
}
Service1Client service = new Service1Client();
service.SaveImageAsync(buffer);
That’s it! Plug this code into your Silverlight app everywhere you upload images and improve your website!
Download the source code here.
CreditsKudos to the folks that made FJCore for sharing all their hard work with those of us that would never consider trying to build it ourselves!
Kudos to nokola for finding a way to build a WriteableBitmap object from an image control without touching the VisualTree.

Google Web Toolkit 2.0 brings web apps one step closer to… Silverlight

Tim Greenfield — Thu, 10 Dec 2009 04:19:52 +0000

What is GWT?

In case you haven’t had a chance to explore, Google Web Toolkit (GWT) is a great new tool for building web applications. At its core, GWT allows developers to code in Java and essentially “compile” to Javascript. But it offers much more: GWT also provides a set of common controls (or widgets) to build UIs and even provides a plugin for Eclipse that allows developers to debug both client and server-side code in the same environment that they write their code. Cross browser compatibility is taken care of for you and if you stay within the confines of GWT, for all practical purposes you’ll think you were building a native Java client/server application.

What’s new in GWT 2.0?

Yesterday Google released Google Web Toolkit 2.0. GWT 2.0 provides a number of improvements but the most important one is the ability to define your UI using markup instead of code. You could always create good old fashion html with GWT, but if you wanted to use the native UI widgets, you’d have to do all the creational work in code. With 2.0 you are now able to use a feature called uiBinder to build your own native GWT widgets (the equivalent of UserControls) all in markup. The cool part is, you can mix html with your GWT markup if you want to.

The Good:

GWT helps developers build complex client/server applications with first class tools in a first class language and target any browser without the need for a plugin. The developer doesn’t have to know anything about Javascript, Html, or cross browser quirks and can use accepted design patterns for building complex web applications.

The Bad:

Before my time, assembly programmers must have argued with C programmers that they could never write code in C that would be as efficient as assembly. They must have argued that there would be certain advanced tasks that couldn’t be done easily in C, and that the compiled C would be bloated by comparison and nearly impossible to read if something went wrong and you needed to inspect your code. This is the same argument GWT faces today from the Javascript camp. Ultimately, a javascript app is still being created under the hood and because of it, GWT developers will never have the same level of control and flexibility as if it had built in Javascript from the beginning. All choices have tradeoffs and this is one of GWT’s.

The Ugly:

The product that GWT allows a developer to create will always only be as good as the browser running it and will be held back by the older browsers that it needs to support. In the near term, in order for the GWT feature set to progress, 2 things have to happen: 1) browsers have to natively start supporting new features (can anyone say HTML5?), and 2) certain features in your GWT app won’t support older browsers. While this is a reasonable way to compete with ASP.NET Webforms, jQuery, and Ruby on Rails, this is not a sustainable path to compete with Flash, Silverlight, or Java FX. Hence…

My opinion on GWT’s long term strategy:

Either GWT will ultimately be positioned as a technology suited for catering to lowest common denominator scenarios or…

Google will have to adopt something similar to the plugin approach. GWT developers will still build their app using GWT the way they do today but if they want access to all those extra goodies that Flash, Silverlight and Java FX have (the ones that are not supported in the current version of HTML or Javascript), GWT will need to build those features into Chrome and allow developers to build apps that require some variation of Chrome (Chrome browser, the Chrome OS, or the Chrome Frame plugin). Google may try to bake these feautres into whatever the next version of HTML is at the time but my guess is that they won’t always be willing to wait around for W3C to agree and will start adding them to Chrome as they need them. In the end, GWT apps that need the latest features will essentially be native Chrome apps built on (for all practical purposes) a Java powered plugin framework.

Personally, I say unless you need a plugin independent app, why wait? Silverlight, Flash, and Java FX give you today everything that GWT will provide tomorrow.

PuzzleTouch wins the ComponentArt Silverlight Coding Contest

Tim Greenfield — Wed, 04 Nov 2009 02:19:50 +0000

UPDATE: The results are in and PuzzleTouch won the grand prize! I had some tough competition so I am extra excited to have won.

The ComponentArt Silverlight Coding Contest results are in for the five finalists and I am super excited to annouce that my creation: PuzzleTouch Online Jigsaw Puzzles made the cut! Thanks to all who voted for me!

If you haven’t see PuzzleTouch yet, check it out. It’s as fun to play as it was to write and is a great testament to what Silverlight is capable of producing.

It’s the only online jigsaw puzzle on the web that supports 360 degree rotation, 100% mathamatically unique shapes, unlimited levels of difficulty, full multi-touch support (my favorite for those that have the hardware!), out of browser mode, the ability to save games, and the ability to run offline (great for planes, trains, and autos).

Host your Silverlight apps on Amazon S3

Tim Greenfield — Sun, 01 Nov 2009 02:50:54 +0000

Silverlight apps are nothing more than big zip files and Amazon S3 is dirt cheap and hyper-scalable. Why would you ever host your Silverlight .xap files on your own server or ISP? … especially with Silverlight Streaming being dropped soon.

Here’s a quick guide to putting your Silverlight apps on Amazon S3 and depending on your app, never worry about scalability or bandwidth costs again…

1) Create your Amazon S3 account.

2) Install S3 Organizer FireFox plugin (this is the equivelent of an FTP client for Amazon S3).

3) Run S3 Organizer, log into your account and create your bucket.

4) Upload your xap file to your bucket. BUT… you must add custom headers unless you are also going to host your .html file there too. Silverlight xaps need a MIME type specified when they are loaded from another domain. The good news is, this is easy with S3 as long as you do it at the time that you upload the file. There is probably a way to set it after the fact but not with S3 Organizer.

Simply set the content type to ‘application/x-silverlight-app’ and send up your xap. Don’t forget to do this EVERY time you upload an update.

5) After uploading your .xap file, set permissions so everyone can read your xap file. Right click on your newly uploaded xap file and choose “Edit ACL…”. Then check Read access for Everyone and Authenticated Users. You do NOT need to do this every time as S3 remembers your ACL settings.

6) Add the enableHtmlAccess param to your object tag within your html file to enable access to the DOM bridge (assuming your Silverlight app needs access to the DOM bridge).

For example:

7) Change your html page to load your xap file from S3 directly by setting the source param in your object tag.

For example:

Note: ‘mybucket’ is the name of your bucket on S3.

8 ) Upload your html (or aspx) page to your web server. GoDaddy.com offers cheap hosting for only $5 per month.

That’s it! At this point, the only scalability concerns you should have are those of your web services (assuming you call web services from your Silverlight app).

And with S3, the costs depend on the usage — which will literally cost you just pennies per month until you have some descent traffic. Do the math and you’ll see that it would only cost 17 cents to have a 300K .xap get hit 3500 times. At that rate you’d pay ~$48 to have 1 million new users per month. (I say “new” users because unless you update your xap, users should be caching your xap file and won’t need to re-download it).

Happy cheap hosting and Silverlight coding!

Silverlight Presentation at EADNUG

Tim Greenfield — Thu, 22 Oct 2009 05:05:05 +0000

Thanks to all who attended my presentation tonight at the Eugene .NET users group (EADNUG)! There were many great questions I had a fantastic time showing off all the cool things Silverlight can do.

Click here to get all the fun little projects covered (and a few we didn’t have time for).

See you again at the next meeting.

How HTML5 can compete with Silverlight and Flash

Tim Greenfield — Wed, 23 Sep 2009 02:26:51 +0000

In case you haven’t heard, Google just debuted Google Chrome Frame; allowing developers to run the Google Chrome rendering engine inside IE as a plugin and thereby trumping IE.

Reading blogs like this one, I distinctly get the feeling that most of the tech journalists out there don’t understand what this is really all about. This is not about Google being annoyed with old versions of IE, it’s about HTML5 vs. Silverlight vs. Flash. Right now HTML5 has 3 big disadvantages over their plugin counterparts…

Different browsers will implement HTML5 differently. Even if it is standards based.
Most browsers don’t support HTML5 and getting a user to switch browsers is a lot harder than getting them to install a plugin.
Standards based innovation is slow. HTML5 in its entirety should be ready for browsers to implement in 2012; just in time to be as far behind Flash and Silverlight as HTML4 is today.

In the end, there are only 2 ways around all of these disadvantages:

Either get everyone to use your browser or
Run everything thru a plugin.

Google Chrome (the browser) and Google Chrome Frame together make it possible for developers to write and test code in an IE-less world, thereby getting more developers to care about Chrome, less to care about IE, and more to choose HTML5 as a framework to develop apps on.

Right now the plugin is an ActiveX plugin and therefore only works on IE, but give Google some time and I’m sure they’ll have a Netscape plugin too that will work in Safari and Firefox. It’s only a matter of time before you Google will be nearly in complete control over how HTML5 will be rendered (if the developer chooses so) and thereby won’t need to wait on a standards committe to approve further innovation to HTML.

Of course, the picture is even bigger than that… whoever owns the developers will own the dominant OS. In my opinion, this is all a tactic in the Android/Chrome OS vs. iApple vs. Windows war and the reason Google built Chrome in the first place.

You say hello and I say goodbye (to Windows Azure)

Tim Greenfield — Sun, 19 Jul 2009 18:49:01 +0000

This week Microsoft finally revealed its pricing structure for Windows Azure hosting services. Using Azure to host the simplest website in the world costs a minimum of $0.12 / hour. Work out the math: 0.12 * 24 * 30 = $86.40 / month.

While this might sound reasonable to a large organization with tons of traffic or anyone currently using Amazon EC2 or Rackspace’s Mosso, this is way out of reach for the majority of developers and organizations who are just trying to create a useful webservice or website that could scale in the off chance their idea took off or got mentioned by the press.

Based on this pricing it’s obvious that Microsoft is trying to compete with Amazon and targetting the same market. Nevertheless, I personally had high hopes that Microsoft was actually trying to compete with Google App Engine by offering the first and only affordable and scalable Windows hosting option… which raises the point: (in case anyone from Microsoft is listening) if Microsoft wants .NET to compete long-term as a server-side platform (which is essential for Windows to thrive as a server-side OS), someone is going to have to solve this problem soon or it will find itself playing catch-up.

I love Windows Azure and I believe it is a great, simple and affordable option for the big boys. But as Windows Azure leaves beta and the world says hello, I say goodbye before I have to start coughing up ~$100/mo for my personal websites. Back to shared hosting at GoDaddy ($4/mo for Windows + SQL).