| Comments

One of the cool features for Silverlight 4 Out-of-browser applications that was announced as a part of the Silverlight 4 beta release is the NotificationWindow class.  Most commonly referred to as “toast” these are the little notifications that popup in the system areas of your operating system to provide helpful (and sometimes annoying) information.  Any user of Microsoft Outlook no doubt has seen them.  They look something like this (Windows system tray area shown here):

Silverlight 4 NotificationWindow sample image

After reading Corey’s post showing a quick FAQ on customizing the experience of the NotificationWindow, I was drawn to the comment he made about queuing.  While the NotificationWindow API doesn’t have a queuing mechanism, .NET does and we can leverage that.

NOTE: For a simple overview with a short video and downloadable sample code in C# and Visual Basic about the Notification Window API visit this video: Notification API in Silverlight 4.

Let’s say you had some need to queue up notifications.  Or better yet, you really didn’t have a *need* to, but wanted to ensure that any notification you wanted to display would regardless of if a notification was currently showing, etc. – you want to make sure your notification hits.

Instead of just firing .Show() on your NotificationWindow, thing of using the Queue<T> class.  This enables a collection of items stored in sequential order and serves this purpose well.  Let’s assume a simple demonstration here.

We have an extremely simple UI with four buttons…each going to trigger a different NotificationWindow.  Here’s our XAML:

   1: <StackPanel x:Name="ApplicationSample" Visibility="Collapsed">
   2:     <Button Content="Notification One" x:Name="Notify1" Click="Notify1_Click" />
   3:     <Button Content="Notification Two" x:Name="Notify2" Click="Notify2_Click" />
   4:     <Button Content="Notification Three" x:Name="Notify3" Click="Notify3_Click" />
   5:     <Button Content="Notification Four" x:Name="Notify4" Click="Notify4_Click" />
   6: </StackPanel>

The button click logic looks the same for each (with the exception of passing in a different string of text to display):

   1: private void Notify1_Click(object sender, RoutedEventArgs e)
   2: {
   3:     CreateNewNotificationControl("Notification One");
   4: }
   5:  
   6: private void CreateNewNotificationControl(string NotificationText)
   7: {
   8:     NotificationWindow nw = new NotificationWindow();
   9:     nw.Width = 400;
  10:     nw.Height = 100;
  11:     nw.Closed += new EventHandler<EventArgs>(OnNotificationClosed);
  12:  
  13:     NotificationControl nc = new NotificationControl();
  14:     nc.NotificationText.Text = NotificationText;
  15:     nw.Content = nc;
  16:  
  17:     AddNotificationToQueue(nw);
  18: }

Notice the core function of CreateNewNotificationControl and the last line of AddNotificationToQueue.  This is the key function here.  Here is the code for the function:

   1: private void AddNotificationToQueue(NotificationWindow notification)
   2: {
   3:     if (_currentWindow == null)
   4:     {
   5:         _currentWindow = notification;
   6:         notification.Show(5000);
   7:     }
   8:     else
   9:     {
  10:         _notifyQueue.Enqueue(notification);
  11:     }
  12: }

In the code above _currentWindow is a NotificationWindow and _notifyQueue is a Queue<NotificationWindow> member variable.  We basically are adding the NotificationWindow objects we are creating to this collection and letting the Queue<T> help us manage what is showing when.  It is also key to note that when we do add a new NotificationWindow that we are attaching a Closed event handler that helps trigger the Dequeue function for our collection.

The end result is that we are essentially queuing up our notification windows.  Here’s a simple result of the code running (animated image):

NotificationWindow Queue demonstration

You can download the full code here: NotificationWindowQueue_CS.zip (C#) or NotificationWindowQueue_VB.zip (Visual Basic).  Remember, that NotificationWindow requires the application to run in Out-of-browser mode, so be sure to install it first!  Also, this requires Visual Studio 2010 and Silverlight 4 development tools to run.

This concept might come in useful for business applications where different functions (perhaps things out of view) need to notify the user of certain things.  Hope this helps think outside the box a little bit!

| Comments

I was messing around with a new internal application the other day and made a wise crack about some of the features out in the open.  And by wise-crack, I mean ‘feedback in the nicest way possible’ of course.  On one of my suggestions someone pointed out a RTFM moment that the feature was actually in there but had a dependency.  The feature I was requesting was “toast” notifications.

What is “toast”?  Aside from a delicious breakfast treat, it’s a term that most people refer to those little notification windows that popup from applications in the Windows system tray.  Sometimes annoying, mostly useful (depending on how many notifications you get of course). 

examples of “toast” notifications

If you are a Windows programmer, there are APIs you can directly tap into to trigger these things in the standard notification bubbles provided by Windows.  If you are a web programmer though, it would be a challenge to bubble up a message to the native client from a web page with ease.  You could if you wanted though, as Windows provides a standard method for any application to opt-in to using.

OSX users have the same feature (global notification system), but I’m assuming it isn’t easy to use, which is why Growl exists.  It is an application itself that allows a developer to send a notification message to it.  It is user configurable (meaning I, the user, define what my notifications look like and when), but serves as a platform for OSX app developers to leverage and provide the user with a consistent notification platform.  Growl is not a part of OSX though and still requires to be there.

Back to my internal app feedback.  This application made use of something I wasn’t aware of – Growl for Windows.  It’s basically a Windows port of the Growl framework.  Interesting I thought.  I wondered why this application developer of our internal app didn’t just use the native Windows notification system, but I digress.  I started looking around and saw that they have it enabled for web applications to use it.  Cool!  Of course the dependency is still required (i.e., it must be installed), but if it is there, you can use it!  Now, there are others that emulate this type of thing like jQuery Growl for web applications.  These frameworks, however, show notifications in your application and not in your operating system.  So if your web app was minimized you wouldn’t see the notification.

I got curious and saw they had a Javascript library to use…hmmm…Silverlight notifications.  So I busted out a quick sample application for Silverlight that provides notifications through the Growl framework.  Here’s a quick video of my efforts with me explaining a bit:

So what you have is multiple parts.  First, it will only work if Growl for Windows is installed, so if you want to play around, install it.  Second there is the Growl.js library of the framework.  This would be in your web application hosting your Silverlight app.  That’s really all you need.  Now you can expose some Javascript functions to call the library.  I created a generic one called NotifyGrowl which takes a title and content.  This is very generic and uses a single notification type.  Growl let’s you configure notification types to segment your messages a bit and allow your user to customize them like a different UI for error types versus warning types.

It’s pretty cool and interesting to play around with.  Now for the things I don’t like…

Flash – It feels just a little dumb to be using a Flash component in a Silverlight application.  In fact that’s what is happening here.  The JavaScript API for the framework, really is a JavaScript API to a Flash application.  When you initialize the Growl API in JavaScript, you are creating a SWF dynamically that you are then communicating to in later calls.  It works, and works well, but it just feels wonky.

HTML Bridging – Hence the name of JavaScript implies that you’re using some HTML bridge activity to call from Silverlight into the API.  While this is incredibly easy (you can learn how to do this here: <>), it will only work in-browser at the moment.  I think the real power of notifications could be in the out-of-browser applications.  Unfortunately, the HTML bridge isn’t available in OOB right now.

Dependency – This is obvious.  While it is cool, it relies on Growl for Windows being installed.  Are you going to ask your users to install two things?

Not common Growl – The API I played around with wouldn’t trigger Growl on OSX.  That kinda sucks.  I thought it would which is why I started messing around.  I figured you’d be able to write to an API that both platforms subscribe to, but it isn’t the case.

The Growl for Windows project does have a .NET library, so why would I use the JavaScript/Flash one?  Well, the Growl system relies on socket communication so in theory, Silverlight should be able to use it.  Right now, however, Silverlight has restricted port ranges for socket communication.  Those port ranges don’t fall in line with the current accepted range for Growl messages.  In theory (and I’ve asked the developer about this) you should be able to forward messages back/forth.  An experiment for another time perhaps.  Right now the developers of Growl for Windows operate using the Growl Notification Transport Protocol (GNTP) but the Mac/OSX version of Growl does not yet.  Apparently the Mac/OSX developers have pledged to work on this. 

It was a fun experiment to play around with and see how a Silverlight/browser application could provide OS-wide notifications if a framework existed.

What do you think…would you like a “toast” navigation API in the Silverlight runtime for you to use?  What features would you expect that feature to have?