Update - The source for this article is available at http://www.cavinconsulting.com/Code/MediaPlayerRemote7a.zip.

The current version of the Smart Client Software Factory comes with a clever WCF service proxy recipe called the Disconnected Service Agent recipe. This recipe is a much nicer version of the webservice proxy shipped with the prior version of the toolkit. One of the nice parts of this recipe is the automatic online/offline detection capabilities. At its root, the recipe uses a RequestManager to queue up and dispatch webservice requests. Attached to the RequestManager is an IConnectionMonitor. By default, this connection monitor automatically keeps track of a client's connection status.

Unfortunately, this only determines if a client has a connection to the Internet, not whether the client can actually call the webservice of interest. What we want is to make sure the client is really "Online" with respect to the webservice it is calling. There are a couple of ways we can do this. The toolkit allows us to plug in our own service that implements IConnecitionMonitor. We could implement IConnectionMonitor in our own custom service and add an attribute to the ConnectionMonitor tag in the app.config file that would make the framework spin up our own, custom definition of what it means to be "online". That's probably the right way to do things, but I decided to implement a WebserviceMonitor service that simply polls the desired webservice to make sure it is available.

I added IConnectionMonitor.cs to Infrastructure.Interface/Services as an interface with a single, read only property -- IsConnected, and a single event -- ConnectionStatusChanged. Then, I added ConnectionMonitor.cs to Infrastructure.Module/Services as a class that implements both IConnectionMonitor and IBuilderAware:

            public class 
            WebserviceMonitor : IWebserviceMonitor, IBuilderAware {
... }

The constructor of the class uses the existing IConnectionMonitor as a service dependency:

            private 
            IConnectionMonitor _connectionMonitor; public WebserviceMonitor([ServiceDependency] IConnectionMonitor connectionMonitor)
{ _connectionMonitor = connectionMonitor; _connectionMonitor.ConnectionStatusChanged
+= new EventHandler(connectionMonitor_ConnectionStatusChanged);
}

The IConnectionMonitor manages whether the machine is online or offline. So, we need to manage the other half (whether we can get to the webservice). So, we implement a member method to answer the question:

            private void UpdateConnectedStatus()
{ bool wasConnected = _connected; _connected = _connectionMonitor.IsConnected
&& WebserviceAvailable(); if (wasConnected
!= _connected) OnConnectionStatusChanged(_connected); }

With that, we can call UpdateConnectedStatus on creation as well as any time ConnectionStatusChanged is fired by the connection manager. When we sense a connection change, we fire our own ConnectionStatusChanged event using the built-in event mechanism:

[EventPublication(EventTopicNames.OnlineOfflineUpdate,PublicationScope.Global)] public
event EventHandler<EventArgs<bool>>
ConnectionStatusChanged;

But this doesn't solve the problem completely. Why not? The webservice status is only updated in the event of a connection status change as fired by the IConnectionMonitor. So, how do we make sure the webservice status is updated periodically, even if the connection status doesn't change? One solution is to use a thread timer in the service to make periodic calls to the webservice. We can implement this by taking advantage of our IBuilderAware methods:

            public void OnBuiltUp(string id)
{ _connectionCheckTimer = new System.Threading.Timer(new System.Threading.TimerCallback(Tick), null,
0, PingDelay); } public void OnTearingDown() { if (null !=
_connectionCheckTimer) { _connectionCheckTimer.Dispose(); _connectionCheckTimer = null;
} }

There are the basic steps for producing a webservice monitor within the SCSF. I'm sure there are better ways of solving the problem, but this one works pretty well for my needs. Of course, subscribing to the service is as easy as getting a reference to the service or subscribing to the global event:

[EventSubscription(EventTopicNames.OnlineOfflineUpdate, ThreadOption.UserInterface)] public
void OnlineOfflineUpdateHandler(object sender, EventArgs<bool>
e) { _onlineOfflineLabel.Text = e.Data ? "Online" : "Offline";
}

Hope this helps.

After using version 1.5 in the real world, I've realized it's time to make the solution more robust, with higher performance. The 1.5 implementation is so bad, in fact, that I'm not going to offer the source code as promised -- it just isn't release (even alpha) quality. As implemented, if the server goes down or there is a momentary network outage, I have to restart the client (the WCF channel faults and no longer functions). What I really need is a way to make the communication channel more fault tolerant. I can approach this several ways, but by drawing on the toolkits I know best, I have decided to use the Smart Client Software Factory as a base implementation framework for the product. This is probably overkill for what I'm doing, but I really like the automatic offline/online detection and the modular nature of the services layers.

Since we already have something resembling a UI, the next thing is to take a serious look at the business / data access layers. They're pretty co-mingled right now, and experts in the field tell me that isn't a good idea. For the Data Access layer, I see two different approaches: 1) Direct webservice access (like we've done in our previous examples) using the Disconnected Service Agent block provided by the SCSF, or 2) employing the services of 1) for real-time information (now playing) and handling the large volume of media library information via a local, cached data store, regularly updated via ADO.NET synchronization services.

Of course, 2) is my favorite, but we'll start with 1) and move to 2). The nice bit about the SCSF in this case is that changing the data access layer at a later time should have minimal impact on either the business layer or the UI. So long as the data access layer continues to implement the same service interface, the actual implementation shouldn't matter.

So, here goes. We'll start by downloading and installing the most recent version of SCSF, Guidance Automation Extensions (GAX), and Enterprise Library for VS2008.

With that out of the way, we start with a brand new smart client project with WPF UI components enabled. By default, if you want to enable WPF UI components, it creates a WinForms application that allows WPF parts to be hosted. I'm not sure I like this hybrid solution, and may look into using the techniques in the SCSFContrib CodePlex project to get a truly WPF application at the end of the day.

Here's the plan of attack:

1. Implement the Data Access layer as an online/offline fault tolerant service.
2. Implement some form of business layer using a yet-to-be-determined approach.
3. Drop in the existing front-row clone as a UI layer for the time being.
4. Implement a client-side cache for the media library (seldom changing) data.
5. Replace the UI with a purely WPF implementation, possibly using the SCSFContrib libraries.

Sounds simple. Rather than walking through the entire solution, I'll post the areas where I have problems and (possibly) some solutions to these problems.

In segment 34here of this series, I discovered a distinct problem with Visual Studio's treatment of WCF Library projects. Specifically, any WCF Library project in Visual Studio is automatically hosted in a test harness during a debug session -- even if you have explicitly told visual studio not to start that particular project or deleted any reference to WcfSvcHost.exe in any of the project files!

This caused problems when I was explicitly hosting my service in an outside application (like my WinForm app). If I had the service, service host, and client application in the same VS solution (and who wouldn't?), I couldn't use the same configuration information in the WCF host library as the WinForms host. If I did, one of two would fail to initialize, and it was always my hosting application that started up after the WcfSvcHost.exe application that failed. But, changing port numbers between the projects meant that I couldn't use the automatic "Update Service Reference" tool within Visual Studio without manually changing port numbers before I updated. Convincing VS that this wasn't a WCF Library (by removing the project type guid) meant that the automatic update tool wasn't even an option.

The solution was a side effect of my attempt to re-architect my application for re-use. The "Update Service Reference" tool uses the App.Config file within the project where the service reference lives. The applications use the App.Config within the project where the applications live. So, the simple solution is to extract the service references into a different .dll from the client application like this:

Project	WCF Host Application	WCF Library	Service Access .dll	Client Application
App.Config	Port 3132	Port 3131	Port 3131	Port 3132

If you do that, then you can change the port numbers in the host application and client application projects without disturbing the port numbers in the WCF Library or the Service Access library. So, the "Update Service Reference" tool continues to work. The WCF service is still spun up twice on a debug session, but only once on the ports listed in the host application's app.config.

This one may seem a little rudimentary, but it caused me to think a little about the right pattern for handling background worker threads. That is, in .NET 2.0, I could take advantage of the BackgroundWorker control. This control did a nice job of spawning a thread to do some work and alerting the application (on the UI thread) when it was complete. It also got Disposed when the containing control got disposed, alleviating the need for any end of life thread synchronization. In WPF, however, this control doesn't exist, but a class called BackgroundWorker does.

My usual approach to something like this is to create a class level ManualResetEvent and then initialize the BackgroundWorker in the constructor with something like this:

_backgroundWorker = new BackgroundWorker();
_threadStopEvent = new ManualResetEvent(false);
_backgroundWorker.DoWork += new DoWorkEventHandler(GetNowPlaying);
_backgroundWorker.WorkerSupportsCancellation = true;
_backgroundWorker.RunWorkerAsync();

Then, have the periodic worker do a timed wait on the ManualResetEvent. When the wait times out, perform the action, and when the wait is triggered, exit the loop (ending the worker thread). This usually looks something like this:

            private void GetNowPlaying()
{ while (!_threadStopEvent.WaitOne(500,false))
{ // Do some work } } 

In the normal case, I tell the thread to stop when the owning object's dispose method is called like this:

            protected void Dispose(bool disposing)
{ if (disposing) { if (!_disposed)
{ _threadStopEvent.Set(); _disposed = true; } } }

This didn't seem to work in our case. Another alternative was to call the BackgroundWorkder's CancelAsync() method. That didn't work either. The reason? Our Factory has a static NowPlaying object. So, when should we dispose our NowPlaying object? There are many instances of the Factory class created. We don't want each instance to have its own copy of the media library, so we share it across all instances. But, how do we know when to dispose of it?

It turns out, it doesn't really matter. The BackgroundWorker class does a pretty good job of cleaning up after itself. So, we can just get rid of the Dispose altogether. The BackgroundWorker takes care of terminating all of our background threads automatically. Best Practice? I'm not sure. It seems like we're not doing a very nice job of disposing of our resources, but it's pretty slick.

While producing my new, pretty WMP remote control, I wanted to have clever navigation animations similar to those found in FrontRow. The example I used (/backRow) accomplished this in a pretty ugly way.  All of the controls were set up off-screen and flown on-screen according to some animation trigger. This worked, but it made it impossible to edit the contents of the pages with Expression Blend or the Visual Studio editor. So, I decided to use page navigation instead.

The trick was to figure out how to change the look and feel of the page navigation. By default, windows just appear over the old windows with no magical transitional WPF-ness. In comes the AnimationBehaviors Project on CodePlex. This clever little project allows me to control how a window is loaded and unloaded. So, in our case, we can define a page, the contents of which are an AnimationBehaviorHost, and set the AnimationBehaviorHost.LoadedBehavior to LoadedBehavior.SlideInFromRight.

That worked great, except that everything slide in from the right even if we were navigating backwards! It just didn't look right. What would be great is if the LoadedBehavior dynamically changed based on the direction of navigation. Sounds like a great used of Binding.

The first thing to do was to create a place to store the current animation behavior:

            public class 
            NavigationAnimation : INotifyPropertyChanged { //
Singleton class private NavigationAnimation()
{ } public enum NavigationDirection {
Forward, Backward }; private static NavigationAnimation _instance
= new NavigationAnimation(); public
static NavigationAnimation Instance { get { return NavigationAnimation._instance;
} set { NavigationAnimation._instance
= value; } } public static
void SetNavigationDirection(NavigationDirection direction)
{ if(NavigationDirection.Forward==direction)
{ Instance.AnimationBehavior = LoadedBehavior.SlideInFromRight;
} else { Instance.AnimationBehavior = LoadedBehavior.SlideInFromLeft;
} } private LoadedBehavior _animationBehavior
= LoadedBehavior.SlideInFromRight; public LoadedBehavior AnimationBehavior
{ get { return _animationBehavior;
} set { _animationBehavior = value;
OnPropertyChanged("AnimationBehavior"); } } private
void OnPropertyChanged(string propertyName)
{ if (null != PropertyChanged)
{ PropertyChangedEventArgs e = new PropertyChangedEventArgs(propertyName);
PropertyChanged(this,e); } } public
event PropertyChangedEventHandler PropertyChanged;
}

Next, we need to change the animation behavior based on our navigation state so we add an event handler to the NavigationFrame's Navigating event that looks something like this:

            private void OnNavigating(object sender, NavigatingCancelEventArgs e)
{ if (e.NavigationMode
== NavigationMode.Back) { NavigationAnimation.SetNavigationDirection(NavigationAnimation.NavigationDirection.Backward);
} else { NavigationAnimation.SetNavigationDirection(NavigationAnimation.NavigationDirection.Forward);
} }

Finally, we bind our AnimationBehaviorHost.LoadedBehavior to our current animation behavior.

            private void OnNavigating(object sender, NavigatingCancelEventArgs e)
{ if (e.NavigationMode
== NavigationMode.Back) { NavigationAnimation.SetNavigationDirection(NavigationAnimation.NavigationDirection.Backward);
} else { NavigationAnimation.SetNavigationDirection(NavigationAnimation.NavigationDirection.Forward);
} }

That's it! Navigating forward slides the windows in from the right, while navigating backward slides the windows in from the left. I may finally be getting the hang of this stuff!

Once I figured out how to update data-bound collections from a background thread, things progressed rather smoothly. But, when it was time to implement the "Now Playing" pane, I wasn't working with a collection of items anymore. No worry, just implement INotifyPropertyChanged the same way we did INotifyCollectionChanged (with the SynchronizationContext "hack") and all was well. Or so I thought.

The NowPlayingService exposes the album art for the media item currently being played as a System.Bitmap. I chose that because it appeared to navigate nicely across WCF services. While that is true, they don't bind very nicely to any property of a WPF Image control. As far as I can tell, there are a few options to solve this problem: implement a System.Bitmap to System.Windows.Media.Imaging.BitmapSource TypeConverter. dig through the documented converter classes to see if there might actually be one implemented for you (still possible, but I couldn't find one), or just do the conversion in the business object and expose the image property as the appropriate System.Windows.Media.Imaging.BitmapSource.

I decided the last option was easiest. So, I exposed a BitmapSource property called AlbumArt and assigned it from the System.Bitmap with something like this:

            private System.Windows.Media.Imaging.BitmapSource FromBitmap(System.Drawing.Bitmap bitmap)
{ return System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(
bitmap.GetHbitmap(), IntPtr.Zero, System.Windows.Int32Rect.Empty,
System.Windows.Media.Imaging.BitmapSizeOptions.FromEmptyOptions());
}

That worked great, synchronously. When I started updating it in the background thread (on a periodic timer), I got a "System.Windows.Xaml.XamlParseException: System.Windows.Data.BindingExpression' value cannot be assigned to property 'Source' of object 'System.Windows.Controls.Image'. The calling thread cannot access this object because a different thread owns it.  Error at object 'System.Windows.Data.Binding' in markup file ...". What? I'm marshalling across threads correctly. Everything else works. What could be going on here, and why?

Non sequitur - In a previous life, I was a C++, Win32, COM, and ATL developer. I was also an ESRI ArcObjects (a pretty large COM API for automating ESRI ArcMap) developer. As soon as I started working with .NET, I grabbed a copy of Adam Nathan's excellent book on COM Interop. With that, I sought to understand as much as I could regarding the interoperability between COM and .NET for I wanted to take advantage of the .NET UI from within my COM business model.

The inclusion of things like .Interop. in the namespace and GetHbitmap() in the arguments immediately led me to the potential that the returned BitmapSource reference was a simple wrapper around the HBITMAP in the System.Bitmap reference. By the fact that the UI is complaining about accessing an object in a different thread, I surmise that the HBITMAP of the System.Bitmap is in Thread Local Storage rather than global memory. So, I altered the conversion process to something like this:

            private System.Windows.Media.Imaging.BitmapSource BitmapSourceFromImage(System.Drawing.Image img)
{ System.IO.MemoryStream memStream = new System.IO.MemoryStream(); img.Save(memStream,
System.Drawing.Imaging.ImageFormat.Png); System.Windows.Media.Imaging.PngBitmapDecoder decoder
= new System.Windows.Media.Imaging.PngBitmapDecoder(
memStream, System.Windows.Media.Imaging.BitmapCreateOptions.PreservePixelFormat,
System.Windows.Media.Imaging.BitmapCacheOption.Default); return decoder.Frames[0];
}

With the business object exposing a copy of the bitmap, all is well. However, I am finding myself, once again, questioning whether it should be the job of the business object to know whether it's being used from a different thread. I guess it's a question of determining who is responsible for ensuring thread safety. Ultimately, it was the business object's fault for exposing a wrapper around thread local storage rather than heap storage.

This is the eighth in a series, but the numbering is getting confusing, so I'm going to stop counting.

The first step I took in creating my pretty WMP remote control UI was to steal design the pretty UI. Once I had the UI, it was a matter of binding the media library entries to the appropriate WPF elements (a listbox). I used some pretty standard dataset creation / binding logic I found somewhere that makes use of the ObjectDataProvider. To implement this, I created a MediaLibrary and Factory class that looked something like this:

            public class 
            MediaLibrary : ObservableCollection<Song>
{ public MediaLibrary() { GetSongs(); } private
void GetSongs() { IMediaLibraryService mediaLibrary
= new MediaLibraryServiceClient(); int librarySize
= mediaLibrary.GetSongCount(); int i = 0; while (i
< (librarySize + _pageSize)) { List<Guid>
currentIds = mediaLibrary.GetSongs(i, _pageSize); foreach (Guid id in currentIds)
{ Song currentItem = mediaLibrary.GetMediaInfo(id); if (null !=
currentItem) { this.Add(currentItem); } } i += _pageSize;
} } }

            public class 
            Factory { ///
<summary> /// /// </summary> static Factory()
{ Songs = new MediaLibrary();
} public static MediaLibrary Songs
{ get; private set;
} }

And I bound the contents to the UI using syntax like this:

            <
            Grid
            >
<
            Grid.Resources
            >
<
            ObjectDataProvider 
            x
            :
            Key
            ="FactoryDS" 
            ObjectType
            ="{
            x
            :
            Type 
            local
            :
            Factory
            }"/>
<
            DataTemplate 
            x
            :
            Key
            ="SongTemplate">
<
            StackPanel
            >
<
            TextBlock 
            Text
            ="{
            Binding 
            Title
            }"/>
</
            StackPanel
            >
</
            DataTemplate
            >
</
            Grid.Resources
            >
<
            ListBox 
            x
            :
            Name
            ="songListBox" 
            ItemsSource
            ="{
            Binding 
            Songs
            , 
            Mode
            =Default, 
            Source
            ={
            StaticResource 
            FactoryDS
            }}" 
            RenderTransformOrigin
            ="0.5,0.5" 
            DisplayMemberPath
            ="Title"
/> </
            Grid
            >
          

That worked great -- synchronously. But, as we already found out, a synchronous call to the media library webservice isn't the best option (we'd rather page through the results asynchronously, updating the UI while we go). So, I add a background thread, changing the constructor to something like this:

            public MediaLibrary()
{ System.Threading.Thread thread = new System.Threading.Thread(new System.Threading.ThreadStart(GetSongs));
thread.Priority = ThreadPriority.BelowNormal;
thread.Start(); } 

Run this, and you get a nasty cross-thread exception: "System.NotSupportedException: This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread." Huh? What does my business layer need to know about threading? I'm just updating a collection. But, not to be intimidated easily, I try other options. How about implementing INotifyCollectionChanged rather than inheriting from ObservableCollection? Same problem. So, Google reveals a nice discussion by ILoggable. He's as frustrated as I am. Really, should my data access layer know whether it's running on the UI thread? I don't think so. Shouldn't the Binding mechanism in WPF assume that I will be updating my business objects in background threads? After all, what's the cost of a 4 core processor nowadays?

I found a bunch of solutions to this problem that relied on explicitly making calls to Application.Current.Dispatcher.BeginInvoke. That seems sleazy to me. One, slightly less sleazy solution I found was to pass in a SynchronizationContext to the MediaLibrary class. This still sounds like the business objects need to know too much about the runtime, but at least SynchronizationContext is in the System.Windows.Threading namespace, so it doesn't completely destroy my hopes of separating UI, business, and data.

The solution I finally came up with (borrowed heavily from here) was a MediaLibrary with these changes:

   public classMediaLibrary : List<Song>, INotifyCollectionChanged
   {
        private const int _pageSize = 5;
        privateIMediaLibraryService _mediaLibrary = newMediaLibraryServiceClient();
        privateSynchronizationContext _synchronizationContext;

        /// <summary>
        ///
        /// </summary>
        publicMediaLibrary(SynchronizationContext sync)
        {
            _synchronizationContext = sync;
            System.Threading.Threadthread =
                newSystem.Threading.Thread(newSystem.Threading.ThreadStart(GetSongs));
            thread.Priority = ThreadPriority.BelowNormal;
            thread.Start();
        }
        private voidGetSongs()
        {
            IMediaLibraryService mediaLibrary = newMediaLibraryServiceClient();
            int librarySize = mediaLibrary.GetSongCount();
            int i = 0;
            while(i < (librarySize + _pageSize))
            {
                List<Guid> currentIds = mediaLibrary.GetSongs(i, _pageSize);
                foreach (Guid id incurrentIds)
                {
                    SongcurrentItem = mediaLibrary.GetMediaInfo(id);
                    if(null!= currentItem)
                    {
                        this.Add(currentItem);
                        SafeCollectionChangedNotification(currentItem);
                    }
                }
                i += _pageSize;
            }
        }

        private voidSafeCollectionChangedNotification(SongcurrentItem)
        {
            if(_synchronizationContext != null)
            {
                _synchronizationContext.Post(delegate
               {
                    OnCollectionChanged(currentItem);
                }, null);
            }
            else
           {
                OnCollectionChanged(currentItem);
            }
        }

        private voidOnCollectionChanged(SongcurrentItem)
        {
            if(null!= CollectionChanged)
            {
                CollectionChanged(this, newNotifyCollectionChangedEventArgs(
                    NotifyCollectionChangedAction.Add, currentItem));
            }
        }

        #regionINotifyCollectionChanged Members

        public eventNotifyCollectionChangedEventHandler CollectionChanged;

        #endregion

and passing in the context from the factory:

Songs = new MediaLibrary( new System.Windows.Threading.DispatcherSynchronizationContext(
System.Windows.Application.Current.Dispatcher)); 

Of course, this means the factory needs to know what context to pass in, but I wasn't convinced the factory needed to be in the service layer anyway. Really, it's just there so WPF has some form of static class to bind to.

I'm still not sure what I think about this approach. While it works, and can even be used within a WinForms application (and probably even in ASP.NET), it seems like we're putting the onus on the event producer rather than the even consumer (who is, after all, the one who knows whether the event should be caught on a particular thread). I guess that is one of the things I like about the event model in the Smart Client Software Factory (SCSF). The producer just raises the even. If the consumer has specific thread constraints on consuming that event, they declare them explicitly. Hmm. Maybe I should start looking at using the SCSF to implement this thing...

This is the seventh in a series.

• Part 0
• Part 1
• Part 2
• Part 3
• Part 4
• Part 5

As of Part 5, we had a functional end to end solution (let's call it version 1.0) that I deployed across my enterprise household. So, what's next? As with any product, we know things don't stop here -- the clients have additional expectations for functionality, the developers find new technology that would be cool to use, and the QA team finds bugs. Now that it is deployed, however, I'll have to pay special attention to version handling within our data and operation contracts.

Before making many changes, I decided it might be nice to have some unit tests to make sure I didn't break anything when rolling out new versions. A few tests later and I was glad I did. It turns out, I didn't write perfect code during my initial creation (shocking, I know). There were a few off by one errors, some stupid copy and paste errors, and a couple of functions that were just plain wrong. So, even though I didn't do test driven design, per say, I did gain the benefits of a module with reasonable unit test coverage.

So far, the biggest complaint observation from the user base has been that the client application sucks. While it's functional, it certainly isn't pretty. Additionally, it isn't the most robust implementation. For example, if you close the server application and start it back up, the client never reconnects. This is because, once a WCF service proxy faults, it stays faulted until you do something about it. So, the next phase will be to write a more robust, prettier version of the desktop client. Let's start with pretty.

The first step in creating a prettier application is, as is standard in our industry, to poach someone else's look and feel. While I certainly make my living within the Microsoft camp, the innovative UI solutions fall solidly within the Macintosh camp. So, let's take a look at Front Row. There's a great WPF implementation based on some of the Front Row functionality in a "tutorial" called /backRow. It's been a while since the author updated the article, and the Macintosh camp could do nothing but complain about the features that were missing. But, I'm no artist, so I figure I'll start with the look and feel as presented in his article but with a slightly different animation implementation. More on that later.

Source for this article will be available as it becomes ready. The next few segments will cover some of the challenges I ran into while developing the newer, prettier UI. In the mean time, here are a couple of screen shots:

This is the sixth in a series.

• Part 0
• Part 1
• Part 2
• Part 3
• Part 4

With the completion of the previous article, I finally have a media player remote control that allows a client to do most of the things set out in the original requirements specification. So, what happened when I deployed it to my production server? Clicking on the Playlist button causes all sorts of problems. Why? Unlike my test environment, my production environment has several thousand songs in its media library. So, the call to GetMediaLibrary() fails spectacularly. Even if it didn't fail completely, an individual call to GetMediaInfo for each song would take prohibitively long if I had a sizeable media library.

Chris Sells wrote a wonderful article series on the benefits of multithreading in WinForms version 1 (here, here, and here). While these methods are still applicable, multithreading has gotten easier in version 2 by using the BackgroundWorker component and a few other approaches outlined in Chris' excellent book Windows Forms 2.0 Programming. Additionally, the service reference I added to our client application has asynchronous calls built-in, so I may be able to make use of those to keep from freezing the UI.

As far as I can tell, there are two popular ways to solve our problem: 1) take care of paging in the UI, 2) take care of paging at the service level. There is a nice discussion of some reasons for each here.

So, what's the answer? Our original goal was to allow client applications to run on a variety of platforms, including via a web page. So, not all of our clients will be able to solve the problem by multithreading the UI or using asynchronous calls. I guess I have to figure out how to implement a service which will allow paging to the client. That will allow us to solve the client responsiveness issue in whatever way is most apparent for the client. Our WinForms application can call a huge get-all type of solution in a background thread while showing a please wait message,  our web application can page the current n records to the display, and our WPF front-end can change animations and button themes by directly databinding to the service connection state by injecting dependency objects into its visualization tree (or whatever it is that the WPF kids are doing these days).

That means changing our MediaLibraryService contract to look something like this:

[ServiceContract(Namespace="http://www.cavinconsulting.com/MediaPlayerRemote/")] public
interface IMediaLibraryService { [OperationContract] List<Guid>
GetMediaLibrary(); [OperationContract] int GetSongCount();
[OperationContract] List<Guid>
GetSongs(int startRow, int rowCount);
[OperationContract] List<Guid>
GetSongsByAlbum(string albumID, int startRow, int rowCount);
[OperationContract] List<Guid>
GetSongsByGenre(string genre, int startRow, int rowCount);
[OperationContract] List<Guid>
GetSongsByArtist(string artist, int startRow, int rowCount);
[OperationContract] Song GetMediaInfo(Guid songID);
} 

I've left the GetMediaLibrary() method to support the non-paged version of getting all of the songs from our library. Also, I switched the song ID type from string to Guid since they will pass nicely across a WCF ServiceContract and DataContract. Lastly, I have omitted some potentially useful methods such as GetGenres and GetArtists. That is because the underlying media library doesn't really support this easily. We may add this later, depending on the requirements of our client applications, but it will be less than trivial.

The implementation of the paged back-end was relatively straight forward, though the implementation I came up with may not be the fastest. Now, we can take a look at how make use of them from the BackgroundWorker control. Here's what I did: drop a BackgroundWorker control on the form, add a DoWork event handler, add a DoWorkAsync call to the form load. Here's what I ended up with for the DoWork event handler:

            private void _mediaLibraryBackgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{ // Populate the library int librarySize
= _mediaLibraryService.GetSongCount(); int i = 0; while (i
< (librarySize + _pageSize)) { List<Guid>
currentIds = _mediaLibraryService.GetSongs(i, _pageSize); foreach (Guid id in currentIds)
{ Song currentItem = _mediaLibraryService.GetMediaInfo(id); if (null !=
currentItem) { AddSong(currentItem); } } i += _pageSize; } } 

Where the AddSong() method looks something like this:

            private delegate void 
            AddSongDelegate(Song song); private
void AddSong(Song song) { if (InvokeRequired)
{ // Invoke AddSong on the UI thread (since this gets called
from the worker thread) this.BeginInvoke(new AddSongDelegate(AddSong), new
object[] { song }); } else { if (null !=
song) { _mediaLibrary.Add(song); // {... Add the appropriate
TreeNodes to the TreeView ...}  } } }

That's it. Now, the playlist UI comes up immediately and the library pane is updated a few songs at a time, while still remaining responsive to the user. One thing to note -- the only time we access our member collection (_mediaLibrary) is after we know we're on the UI thread. So, we shouldn't have any problems with concurrent access to the collection (reader / writer problem). As a result, we don't have to mess around with locking the collection or using the SynchronizedCollection<Song> class. Of course, I could be wrong, and often am.

The source for this version is available here. Now that things are functional (i.e., we've proven the concept), it's probably time to revisit the design and implementation with an eye for error handling, testing, usability, etc. Since the service layer is the foundation for a potentially large number of clients, we should probably start there.

This is the fifth in a series.

• Part 0
• Part 1
• Part 2
• Part 3

This time, let's concentrate on the manipulations a user will want to do on the media library (retrieving songs, genres, artists, etc.). For this, we'll add another WCF Service to the MediaPlayerRemoteListener project called MediaLibraryService. The service contract for this will looks something like:

[ServiceContract] public
interface IMediaLibraryService { [OperationContract] List<Song>
GetMediaLibrary(); } 

With that, all we need to do is plug in the implementation on the server side and start making use of it on the client side. Of course, this is were things get difficult.

Once again, I find myself at odds with the tools. I've labeled both service contracts with the "ServiceContract" attribute. I've also been very careful to use the "DataContract" attribute for any data items returned from our service (in this case, the Song data contract). However, when adding references from the client via the Add Service Reference option, I am faced with two copies of the Song data contract on the client -- one in the MediaLibrary namespace, and one in the NowPlaying namespace. So, if I get a List<Song> from my MediaLibrary service, and I want to send them to the Play() method of the NowPlaying service, I have to convert the MediaLibrary.Song to a NowPlaying.Song. This leads to a large number of mapper classes (or one cleverly designed generic mapper that uses reflection). I recall similar difficulties with the old .NET 2.0 webservices, and I had hoped this challenge had been overcome in the new tool set. Apparently not.

I supposed it's prudent to talk about the idea of a data contract. Should separate services need to share the exact same data definition as an input or an output? One could argue that if they're so similar, they should be a part of the same service. However, the simple truth is that it happens quite often in the real world. For example I'd like to host one interface for read only access and one interface for read/write access. This allows separate levels of permissions / authentication / protocol for each interface.

One solution is to revert to command line tools with the new /shareTypes parameter to wsdl.exe (via http://www.theserverside.net/tt/blogs/showblog.tss?id=WSStrikesBackP6). But, this makes the already tedious task of updating our service reference all the more tedious. Every time I change my contract (which has happened several times so far), I have to run the hosted version of my service library, escape to the command line and run a batch file refreshing the service reference in our client application. Of course, now that I write it down, it's not that much more difficult than changing the port numbers in my app.config and running the built-in refresh command.

Here's another option. Given our current implementation, we may be able to change the interfaces to remove any need to share data contracts. Does the Play method really need the entire song, or just some form of unique identifier to allow the media player to add it to the play list? It seems like we may be able to get by with a single GetMediaInfo method returning all of the Song information, and simply passing around some form of unique identifier for all of the rest of the methods. So we end up with interfaces like this:

[ServiceContract(Namespace
= "http://www.cavinconsulting.com/MediaPlayerRemote/")] public
interface INowPlayingService { [OperationContract] PlayState GetPlayState();
[OperationContract] string GetCurrentSong();
[OperationContract] List<string>
GetCurrentPlaylist(); [OperationContract] void VolumeUp(int amount);
[OperationContract] void VolumeDown(int amount);
[OperationContract] void SetVolume(int volume);
[OperationContract] void MoveNext();
[OperationContract] void MovePrevious();
[OperationContract] void MoveToSong(string song);
[OperationContract] void Play();
[OperationContract] void Pause();
[OperationContract] void Stop();
[OperationContract] void SetRandom(bool random);
[OperationContract] void SetRepeat(bool repeat);
[OperationContract] void SetMute(bool mute);
[OperationContract] void PlayPlaylist(List<string>
playlist, bool appendToCurrentPlaylist); }

[ServiceContract(Namespace="http://www.cavinconsulting.com/MediaPlayerRemote/")] public
interface IMediaLibraryService { [OperationContract] List<string>
GetMediaLibrary(); [OperationContract] Song GetMediaInfo(string song);
} 

This has the advantage of sending around significantly less data than our previous version. It has the downside of passing primary keys around as strings (I think WMP uses a 128 bit GUID). This isn't exactly what I had in mind for a solution, but it seems to be the direction the tools are pushing me. I'm still not sure this makes sense from a practical standpoint, but we'll keep on following this path for a while longer.

The source for this post is available here. There is a really bad implementation of a ListBox that supports being a DragDrop source as well as destination, and a horrible implementation of displaying a media library in a TreeView (BTW, Drag and Drop on playlists only works for songs in this example).

This is the fourth in a series.

• Part 0
• Part 1
• Part 2

With our "design" out of the way, we can start digging in to the actual implementation. Our first draft will be somewhat exploratory in nature. Given my limited knowledge of the Windows Media Player plug-in architecture, I have decided to start by hosting the WMP ActiveX control in a standalone WinForms application, and have this WinForms application host a WCF service. So, here goes:

We'll start off by designing the communication contract through which our client controls and queries our media player. For now, we'll concentrate on controlling the media player. For this, we'll use a WCF contract called INowPlayingService:

[ServiceContract] public
interface INowPlayingService { [OperationContract] PlayState GetPlayState();
[OperationContract] Song GetCurrentSong();
[OperationContract] List<Song>
GetCurrentPlaylist(); [OperationContract] void VolumeUp(int amount);
[OperationContract] void VolumeDown(int amount);
[OperationContract] void SetVolume(int volume);
[OperationContract] void MoveNext();
[OperationContract] void MovePrevious();
[OperationContract] void Play();
[OperationContract] void Pause();
[OperationContract] void Stop();
[OperationContract] void SetRandom(bool random);
[OperationContract] void SetRepeat(bool repeat);
[OperationContract] void SetMute(bool mute);
[OperationContract] List<Song>
AddToCurrentPlaylist(List<Song>
playlist); [OperationContract] void PlayInPlaylist(Song song);
[OperationContract] void ReplaceCurrentPlaylist(List<Song>
playlist); } 

That looks like a pretty comprehensive list of operations we would want to perform on a media player. So, let's get down to the business of actually implementing this in Visual Studio 2008. I start a new solution and add three projects, a WinForms host application, a WinForms Client application, and WCF Service Library. I add a project reference from the host application to the service library. Then, I notice I can add a service reference from the client application to the service library. Right click on the project, click add service reference, click discover->services in this solution, and choose the service of interest. Nice! Or, so I thought.

Here's where the first problem arises. Remember, I'm using this as an exercise to get my head around the new technologies. The WCF service library project type does a nice job of housing the service components as well as publishing the appropriate meta data for things like adding service references. However, when I go to debug this application, VS automatically spins up the WcfSvcHost process to host our service library. But, remember, I want to host the WCF endpoint within my host WinForms application. No matter what projects you tell VS to start up (or not start up) on debug, it ALWAYS runs the WcfSvcHost application and starts hosting my service library.

It turns out, I'm not the first person to have this problem: Visual Studio 2008, WCF Service Libraries, and CTRL-F5. It appears that the solution is to "remove the project type GUID" that tells VS that it's a WCF Service Library. What? So, in order to host a WCF service library in my own application, I have to disable all of the helpful aspects of VS regarding WCF endpoints (like, say, updating my service reference as the contract changes over time). Ridiculous.

Here's how I finally resolved it. Leave it as a WCF service library, but change the port values in the app.conf sections so my host uses a different port than the WCF service library. That way, in the course of normal debugging, the client points to the ports opened by my host. When I need to update the reference, I change the port to the VS host port, update the reference, and then change it back. It's a nasty bit of kludgery, but it works for my needs. It seems like I must be making a habit of doing things Microsoft doesn't expect. First, I expected a standard windows application to be simple in WPF, now this.

Anyway, source code (so far) is available here. You'll want to change the URL property of the media player control in the host application. You'll also want to set the startup projects so that the host and the client are both started. It's a pretty basic remote control with standard navigation utilities. Next, we'll flesh out some of the media library functionality so we can change what gets played.

This is the third in a series.

• Part 0
• Part 1

Design

As with any good development effort, we begin by designing the solution, complete with an assessment of the pros and cons of each option. Of course, as with any good development effort, we begin with every intention of designing the solution, but we usually skip right past this to writing the code since designs are never any fun. Design: There is a server and there are 0 or more clients that want to control what the server spits out the sound card.

Right. With the design done, let's talk about implementation options:

As I see it, there are two options for implementing the functionality as exhaustively enumerated in Part 0 of our series: 1) A standalone application in which we host and automate a Windows Media Player control, 2) A plug-in to the existing standalone Windows Media Player in which we automate the instance of Windows Media Player in which we are hosted.

So, which of these approaches is better? I have no idea. So, we'll design the approach in such a way that the end user (client machine) doesn't care. How? SOA, WCF, and other TLA's. I figure I can hide my media playing component/service/application behind a WCF connection point. Then, if hosting the ActiveX control fails miserably or creating the WMP plug-in doesn't play nicely with .NET, then I'll always be able to call some arcane WIN32 function to dump directly to the sound card or convert to Linux, convert all of my WMA's to raw .au files and just cat [file.au] > /dev/audio.

Of course, that's an exaggeration. I'm sure one of the two approaches will work fine. I just don't know which. So, hiding the solution behind a WCF connection point should give me the flexibility to try both approaches without rewriting the clients.

At this point, I find that there are a couple of interesting questions to which I do not know the answer. This, of course, will not keep me from plunging headlong into the implementation. They're just questions.

• If I host an instance of the WMP ActiveX control, does it still do all of the clever background work of sniffing media information from the Internet, listening for changes in my media library, and downloading album art or is it just a numb playback machine using the existing media library?
• What are the multi-threading characteristics of the WMP library? Will I have to perform the read/write locks, or will WMP take care of that for me?

Build or Buy decision

This is the second in a series. The overview is here.

State of the industry:

So far, I can find a bunch of solutions to stream media to a client. That is, given a server containing a bunch of media, Spit it out to a client machine (PC, cell phone, television, etc.) so you can consume it wherever you are. This doesn't cut it for our purposes. Instead, we want the media to play at the source, but be able to change the behavior of the media player at the host from a client somewhere.

Items of interest:

• http://pocketpccentral.net/software/remote2.htm - semi-functional
• http://msdn2.microsoft.com/en-us/library/ms973247.aspx - educational, but not entirely functional for our purposes (makes use of .net remoting which isn't my favorite solution, not sure why)
• http://www.alloysoft.com/ - Might be great if I had an iPhone
• http://www.x10.com/entertainment/remote_controls.html - might have something of interest if I were an X10 household

So far, that's all I have. So, if I want a remote control to work on a laptop, pocket pc, smartphone, (and maybe a website), it looks like I'm out of luck in the commercial market. So, it looks like the build option is the one for me.

Of course, that's what I expected to choose. Otherwise, this would have been a really short series.

This is the beginning in a series of unknown length regarding controlling the Windows Media Player from remote machines. So far, I'm at the requirements phase. Next will come industry research (buy or build), but I'm pretty sure I'm going to build something anyway (even if there are perfectly usable buy options -- I'm just stubborn that way).

Here are the requirements in no particular format or order:

• I have a Server 2003 machine running with its audio output hooked up to the whole house audio system (okay, it's just two speakers in a different room, but there's a volume control in there, so I can call it what I want). The server houses the media collection and runs a uPnP server (TwonkyMedia) for the rest of the machines in the house to stream.
• I can play audio through the server if I remote terminal to the server, run media player, and choose some songs. That, of course, completely fails the Wife Acceptance Factor (WAF).
• What I would like is a service or application running on the server to be ready to play at all times, and have the rest of the machines (including handheld and smartphone) be able to dynamically change the playlist, start, stop, fast forward (most important) and rewind.
• I'd like this to run as part of Media Player. I'm not sure why, since SOA dictates that we're just exposing a service, not a particular technology. I think it's mainly because I'm used to maintaining the media library in WMP and I don't want to change.
• An added bonus is if there were a sidebar gadget for my wife's Vista machine (yes, I'm still on XP until some of the performance issues are worked out), and a 10' UI for the media center PC in the family room.
• Since the uPnP server streams media to all of the important places (laptop and media center), there's no reason to mess around with streaming the actual audio to the remote control client, though the now-playing art would be nice.

That's it. In those few, short paragraphs, I have managed to cut out a lot of work for myself. I'm looking for a media player with remote controls that run on smartphone, pda, xp, and as a sidebar gadget. I'd like it to run on server 2003 every time it starts up, be multi-remote control robust, and extremely fault tolerant.

Now, to the buy or build comparisons...