Watch and Learn

If you are unfamiliar with RIA in Silverlight, I would recommend this video: http://www.silverlight.net/learn/videos/all/net-ria-services-intro/. It is a complete walk through of creating a demo from the 'Business Application' template in Visual Studio for SL 3. If you are working in SL4, be sure to check the comments in the video for the breaking changes.

What's the Skinny?

It's pretty fancy stuff. You make an Entity Framework model, based on your database. Then when you compile, the template generates a whole bunch of code for you. First, on the server it generates a Service and a Metadata class to expose your data entities and basic CRUD functionality to the client. Then in the client, another class is generated that handles the serialization and exposing of those server classes client side. One of the most impressive things about this interaction though, is that the return objects from the server are IQueriable, not arrays. Which gives you the ability to perform LINQ and deferred execution from the client!

So Why the Fuss?

Watch the video, play around with it. I'm not going to go through the whole thing here, but I will show you something I ran into.

I have a relational database, in this case I am looking at the League and Player tables. League has an OwnerPlayer_ID field that links to the Player table. The problem though, by using the RIA services and bindings out of the box, is that while the League class has a .Player property, it will never be populated. And showing people that a League is owned by Player #5237 isn't nearly as helpful as showing them the Player's name. We have to make 2 changes to get this to work correctly.

Reprimanding that Lazy EF

On the server side, find your service class. It should be called something like 'MyApplicationDomainService1' and be in the 'Services' folder by default. In that class look for a method called 'GetMyObjects' where MyObjects is the collection you are binding to on the client side. It should contain something like 'Return (Me.ObjectContext.MyObjects)'. Change it to:
Return (Me.ObjectContext.MyObjects.Include("MyChildObject")
In my case this was the 'GetLeagues' method and it contains: 'Return (Me.ObjectContext.Leagues.Include("Player"))'

This will tell the Entity Framework model that it should Eager Load the .Player property. But before we rejoice and rebuild, wait, there's more!

Getting RIA up off the Couch

Next up, right next to the DomainService1 file should be a file called MyApplicationDomainService1.metadata. In this file we need to find the class that represents what we are querying (The "MyObject" from the previous step). In that class you should see the property you want to load (The "MyChildObject" from above). On this property, you want to prepend the <Include()> attribute. This will tell the RIA services that it should include this property in the serialization and transmission of the query results.

In my case of League and Owner Player, it looks like this:

And the Grid?

Now that the EF is loading the data we want, and the RIA services are returning the data we want, all we have to do is bind it! And this is the easiest part. It is just like they show in the video, with one minor change. Instead of just binding on the primary object's property, we use dot notation to get at the child object's property. Shown here as the "Player.Name" binding

-Rick

It's a great interface to a classic brain game. I especially enjoy the "Hard" difficulty level as it is pretty consistently solvable with out reverting to guessing. The "Expert" level though requires you to guess. And as a logic guy, I hate guessing.

Not quite so long ago, in the Programmer's Puzzles forum, we had a "Follow the Clues" challenge. I approached this problem just as I do Sudoku. Writing out the possibilities and eliminating the incorrect answers as I went through the rules list over and over. But just solving the problem isn't enough, the goal, seeing as how most of us are coders of one sort or another, is to write a software solution. So I put together a system that given an array of possibilities and a set of rules, would iterate through the rules and grid filtering out all impossible answers till only the correct ones existed.

It was a fun project, but it made me think. I was solving that problem in roughly the same way I approach Sudoku. So why not improve my solution to be able to solve Sudoku challenges as well?

There are a set number of rules to Sudoku, and a number of patterns that we can see that make solving them easier. So it was just a matter of coding out these rules and inferences, and applying them to a 3-dimensional array of Boolean values (column, row, index).

My initial attempts worked perfectly for anything up to the "Hard" level from OldSchoolDotNet's Sudoku client. But on the "Expert" level, it would get through all of the known steps and then stop. Adam came up with an idea for how to handling the guesses in a tree like branching method. And after a few attempts, I managed to come up with a decent solution.

It isn't cleaned up at all, but if you're stuck on a sudoku puzzle, it may be of use to you. Each click of the "Apply Rules" button will perform one pass of each rule (horizontal, vertical, block) on each square in the board. With out guessing, most puzzles can be solved in about 6-10 passes.

With guessing, it'll take a while. My last solving of an "Expert" puzzle wound up fielding over 18,000 branches. As the number of active branches increases, performance will degrade. But once you get through the bulk of them, the performance will increase as more and more branches are closed.

So, if you're a Sudoku fan, check it out Here.

Code is available Here

-Rick

I was working on a new interface this week for a rather complex item selection system. It deals with hierarchies and mandatory selections, multi-selects and single-selects. In order to make it easier for users to see what items were already selected, there was also a list of just the selected items.

Oh ObservableCollection, I See You!

I toyed around with a few different options, and debated some of them out with Adam, and finally decided to run with binding and an Observable Collection.

Everything is better with LINQ

One of the great things about observable collections is that you can pass them around like candy, make a change to it from any number of locations, and it will update all of the controls bound to it. Mix in a little LINQ and you've got some awesome functionality with very little code.

What Do You Mean CollectionChanged Doesn't Fire?

One of the things I needed to do though, was to detect when the user selected an item from the collection. When the IsChecked flag was flipped, I needed to go to the server to get any child items. But the Observable Collection does not expose property changed events, which started me down this path.

The User Interface

For this demo app, the UI is pretty simple. I just have two list boxes. Each list box has a DataTemplate with a CheckBox in it. The CheckBox has its Content bound to the "Text" member and IsChecked is bound to a like named member. The IsChecked property is also set to TwoWay mode. This means that when the user changes its checked state, it will update the underlying collection.

On to the Items

For the most part the Item class just contains our properties, but we have to beef it up just a bit. First, it needs Implements System.ComponentModel.INotifyPropertyChanged. INotifyPropertyChanged will create a public event called "PropertyChanged". In order to save ourselves a bit of repeating code, we can make a method called onPropertyChanged that raises that event for us:

Also in the item class we need to tweak the properties a bit. For instance:

Note that we are only calling the onPropertyChanged event when the value has indeed changed. Also, ensure that the underlying value has changed BEFORE you call the onPropertyChanged, otherwise you'll wind up with some really interesting behavior.

The Collection

The Observable collection doesn't expose the PropertyChanged event by default, so we have to bubble it up ourselves. That means we need to make a new class that inherits from ObservableCollection. In order to get a handler on the Items PropertyChanged events, we need to override the InsertItem and RemoveItem methods. Inside them we Add and Remove an event handler for the Property Changed event. And in the procedure that handles that event, all we need to do is to raise our new public event.

Back to the MainPage

In the code of the main page, we need an instance of the collection, using the WithEvents keyword will make it exceptionally easy to attach to our events. In the constructor, we can set the ItemSource of both of our list boxes to that collection. And if you check the objects/events drop downs, you should see that our collection now exposes both a CollectionChanged and ItemPropertyChanged event. Put a message box or break point in each and fire up the app.

Running

When you run it, you should see a number of identical items in each list box. When you click on the check boxes of either list, you should see the ItemPropertyChanged event fire, after which both list boxes should reflect the new value in the collection.

Show me the Demo

Show Me the Code

Working VS 2008 solution can be downloaded from here.

For example, I have a datagrid. One of the columns in that data grid holds a control that displays and icon and a tool tip based on the content of some data.

So you would start with a control like this:

Then, in the XAML of the data grid:

Everything looks good, but running the app will pop one of Silverlight completely unenlightening errors.

What we need to do is to set up MyToolTip as a dependency property. We just have to add a bit of code to the custom control:

And that fixes that. Why this wasn't just handled behind the scenes I don't know. I've heard that they have done a lot of work on the Binding system for SL4, so maybe this will not be a requirement once the next update rolls out.

-Rick

Introduction

Every week in my shop we do cross training. Someone brings in something they are working on, some system that people are unfamiliar with, some new technology, basically anything related to any of our jobs as developers and maintainers of applications. Often enough I do presentations on Silverlight and Blend, introducing my coworkers to different tools and options that we have available to us. This blog is a write up of one such training presentation. I give you, the Silverlight Spinner.

Just ran into this minor quirk today, figured I'd share the solution. I have a Webservice that returns an array of a class defined on the server. On the client side, I wanted to extend that class to link it to some GUI elements. Enter the partial class. If you haven't played with Partial Classes before, I'd recommend checking them out. It allows you to build additional functionality into any class. Not by inheriting from a base, but actually extending that class without creating a new one. Anyways, I wound up with the following:

srAlerts is the namespace of my web service. Alert is the name of the class defined in my web service. CommentIndicatory is the GUI control that I was linking to.

The critical part though, is the attribute. Without the System.Xml.Serialization.XmlIgnore attribute, you'll get an exception on the constructor of the web service Reference.vb file:

Exception has been thrown by the target of an invocation.
-There was an error reflecting type 'Alerts.srAlerts.BaseResponse'.
--There was an error reflecting type 'Alerts.srAlerts.GetAlertDataResponse'.
---There was an error reflecting property 'Alerts'.
----There was an error reflecting type 'Alerts.srAlerts.Alert'.
-----There was an error reflecting property 'CommentDisplay'.

It would appear that the web service system in Silverlight attempts to serialize all members of the class, even those that are defined client side in a partial class, and it gets a little confused. Using the XMLIgnore attribute forces the serializer to skip this property and allows us to use the partial class on the client side as we expected.

On a side note, there is also a WCF attribute: System.Runtime.Serialization.IgnoreDataMember which will NOT work for web service references.

-Rick

Sorry this post has been so delayed. I was wiped out last week and a half with a nasty cold that I am still recovering from. I missed my entire Thanksgiving break, curled up under blankets and coughing my lungs up. Anyway, I'm finally back on my feet, albeit completely buried under catch up work and a new project. But as promised, nuts and bolts from KBay!

The Power of Communication

One the best parts of KBay is, IMO, the communication design. Every web method in the service takes a single object parameter and returns a single parameter. These two objects are always called the Request and the Response.

Some of the awesomeness behind this pattern includes:
1) Client side, you can hang on to a request and populated it as needed. No more piles of variables to pass in, just set up the single request object, it's all nice and self contained.
2) Super easy logging/debugging. At any point in time we can serialize the request/response objects to see what's in them. Even using a tool like Fiddler you can see a nicely formatted data layout of your parameters.
3) Server side additions will not break functionality. So long as the server side checks the value it wants to use before using it, the client side will continue to function. This was great for us as we had 2+ developers on the project the whole time. If Adam was adding more parameters and functionality server side, I could continue hitting the dev server with out having to rebind or implement any changes.

The Simplest Web Methods Ever

First off, the actual code behind on the web services:

This code is actually for a different project, but it's what I had handy. All of the functions follow the same pattern as the ones you can see here. They take a custom Request object and return a custom Response object (both named after the method). Inside the method, they call the Request.FillRequest method.

Where's the beef?

So let's keep digging. Here is the GetInit.vb file that contains the functionality for the GetInit method:

A couple of things to notice here. First, there are two classes in this file, both the request and the response. This is just for organizational purposes. You'll also want to note the "servicemanager.AutoCreateSessionId()" attribute on the Request class. We'll use this again later.

One of the cool things about this system is that it uses generics to move data UP the hierarchy chain. In this case, you can see that we are inheriting from BaseRequest, which allows us to specify the types of the generic.

The "innerFillRequest" method is where the actual functionality of this web method takes place. In the case of GetInit, it grabs a string from the Environment Provider, splits it, and adds it to a member on the Response object.

Below that is the GetInitResponse class, which in this case is pretty simple and just contains a property that exposes a list of strings. The same property that is populated in the Request object's innerFillRequest method.

Strange Child, Who is your Parent?

While these derived classes show us what the method does, it doesn't show us how they are called. The web methods called Request.FillRequest, not InnerFillRequest. So lets look at the class that the request inherits from, BaseRequest:

The BaseRequest class is abstract, it must be inherited. But even cooler, it is a generic class. We can define it's type dynamically. It implements iRequest, which just guarantees it some basic members:

The "FillRequest" method is the conductor of this train. This is the method that the web services are actually calling. Right off the bat, if starts up a stop watch, so we can get performance indicators off of every web service call.

If you remember back to that GetInitRequest class, we set the AutoCreateSessionIDAttribute. And this is where it gets used. If that attribute is set, then we know that this is an acceptable application start method. So we Log the application start up, which returns the Session ID. The Session ID, from this point on, should always be passed back and forth between the client and server, so that all interactions with this user for this execution of the application are under one ID. If for any reason, this Session ID is not set, we kill the process with an exception. This prevents applications from jumping into web service calls with out following the appropriate chain of processes.

The RequestToken is a feature used for logging. It allows us to tie multiple log entries (say like a request, some server side process logs, and the response) into a single log entity. This is really only of use when viewing the log, so you can collapse multiple log entries into a single interaction.

The "GetLoggingReplacement" is a block we use to replace chunks of text we don't want to log. For instance, if the request contains large binary blocks (like uploading files) or sensitive information, we can set up string manipulations here to remove those items from the serialized request before it gets logged. This sub is usually overridden by the derived classes to add more method specific replacements.

Until Next Time

The projects continue to pile up. Everyone is trying to wrap stuff up before the holidays and new year, so I've got a lot on my plate. As I get more time, I'll try to put up more on some of the other technical tricks we used inside of Silverlight. But this communication system, in conjunction with our Logging system, Unit tests, and having 2 developers on each project has dramatically helped us cut down on development time, reduce released bugs, and improved user acceptance of the applications.

-Rick

Rick here again. I really want to get to the nuts and bolts of KBay, but first, we have to get into some of the tools our shop has in place. We leverage these tools to improve almost all aspects of our development life cycle. Two of the biggest tools we refer to as Environment Provider and Application Logging.

The Environment Provider

The Environment Provider does exactly what its title suggests: It provides an environment, or more specifically, all of the meta-data an application needs to exist in a specific configuration. Connection strings, end points, application configurations, etc. There is one single database that holds all of this data. This data is identified by a "context". For example, the KBay webservices can exist on a local developer's PC, a Development Server, a Staging Server, and a Production Server. Each of these locations can connect to either the Development or Production database. So a combination of the location of the application and the desired data environment gives us a context for which a set of environment parameters to use. In the case of KBay, the structure is pretty simple. We have some other apps, international apps with multiple data sources, well, they get a bit crazy, but we have an app just for managing all these settings:

The EP Tree

It started off as a proof of concept for organizing Environment Provider data when someone mentioned a "Tree" controller and someone (probably Adam!) put it to a Silverlight challenge. Different types of parameters (leaves) are color coded, and if connection strings are detected that point to databases other than their context (branches) would imply, they turn red. And yes, the sun and sky are also animated. Although it started off as a joke, we actually found some bad configurations with the color-coded leaves.

Accessing the Meta-Data

All of this data gets exposed through a web interface. A web service that takes a context, User Name, and other external parameters returns the appropriate environment data. So all of our applications go to 1 central point for configuration data.

It's Better Than Great, It's Log!

The other biggie is the Logging System. The Logging System is pretty straightforward. There is a table that stores application information, one that stores user information (tied in to Active Directory), one that stores Session information (User X started System Y at this date on this machine with this Environment Provider Context), and one table that stores log entries for the sessions.

By Your Powers Combined

We store the Environment Provider Context on each session. This is actually a function of the Environment Provider. When an application calls the EP web service, in addition to all of the environment data, it also gets a SessionID. The call into the Environment Provider calls the logging service which creates the log session, populates the appropriate data and logs an application start event. This allows us to quickly identify log entries not just to an application, but to a specific user, on a specific server, with a specific data connection, etc...

Getting at More Data

All of this log data is exposed through a really quick and dirty Silverlight app that provides us with some standard search functionality:

Great Business Value (aka: How to convince your boss it's worth doing)

Being able to quickly and easily pull up log entries has proven absolutely essential for tracking down user issues, communicating error details between developers, and even determining usage and error rates in applications to help with prioritization. For instance, I give you our Application Usage tool:

Rendered Data at Your Finger Tips

Application Usage is a tiny Silverlight App that sits on our developers' Share Point portal. Similar to the lay out here at LessThanDot, we have a right hand column with generalized data displayed. We've found that column to be a great place to add Silverlight apps for interactive reporting. The Application Usage app for instance, and another that tracks Source Control locks, lock durations, and even file names per developer.

Where's the Code?

That's about it for this post, tomorrow I hope to get more written about the communication system. And after that, some of the code and XAML that makes this stuff tick!

-Rick

Rick here again with another little blurb on my most recent Silverlight project, KBay. Today, I'd like to write a little bit about what went right.

Separation of Power

One of the biggest attributes of KBay's success, IMO, was the segregation of development. My coworker Adam (Hi Adam!) and I handled the majority of the work for this project. The initial goal was to try to involve everyone on the App Dev team, to give them more exposure to Silverlight. But with the tight time-line and other priorities, we couldn't keep the whole team on page. So after some initial design meetings and DB layout, it largely fell to Adam and me to get it to work.

Balance Your Strengths

Adam and I approached the problem from our own strengths. Both of us are more than capable of writing the entire solution, but we both have our strengths and weaknesses. In my case, my experience with Blend and XAML, along with some rudimentary graphics arts knowledge, really allowed me to speed through the front end, while Adam's envelope pushing experience with LINQ and Generics allowed him to come up with some really awesome solutions to communication and technical issues.

Two Heads are Better Than One

This separation really allowed us to greatly improve not just our development speed, but it also worked as a sort of code review, where we were both interacting with each other's interfaces. Since we had virtually no requirements for the project, it allowed us to brainstorm freely and to consider many options that neither of us would have thought of on our own.

Lather, Rinse, Repeat

Both of us were so struck by how excellently this approach worked in our environment, that we have recommended to our management that we reuse it in more projects . And so far, it has continued to work exceptionally well.

One of These Things is Not Like the Others

Working in Silverlight, unlike any other mainstream MS platform, means that your only option for interacting with the server is via Webservice or WCF calls. Not only are these the only options (aside from some socket options) but they are also entirely Async in their behavior.

Limits Are Good?

This limitation opens up a number of options and challenges. First, there is a crystal clear separation between the presentation layer and the business/data layer. It allows for developers to be very pure on either side. A web service does nothing for layout and the UI does nothing for data manipulation (save for maybe some caching).

Green Light Go! Red Light Stop!

Second, the UI developer can track explicitly when any IO begins and ends, and with a bit of wrapping, control the UI accordingly.

Unit Testing Made Easy!

Third, and probably best of all, since almost all of the functionality is being controlled by web services, it is really easy to isolate functionality for integrated unit testing. This has been a huge boon for us in terms of stability of deployments, even in the dev environment with multiple developers. It takes 20 seconds to run every single method through all of our known use cases, and those unit tests are run before every deployment. These unit tests are a critical to reducing risks for off-schedule deployments.

Are Limits Bad?

Maybe 'limits' isn't the right word for this. You can still do almost everything you can do through other platforms, you just have to go about it through entirely different means. The limits that exist force developers to go through the new means, using async communication and webservices/WCF instead of continuing to depend on integrated IO and synchronous processing. So while there is a learning curve in changing the way we approach problems in Silverlight, I think that overcoming that curve will enable more developers to think in a parallel style. Removing the interface from the process, and making the processes async forces developers to partake in good development practices. Because every time I see a Windows app go to a white screen because some developer tried running I/O operations on the GUI thread, I cry a little on the inside.

I Love Log

That's it for the more abstract summary of the KBay project. I promise my next segment will deal with more of the technical nuts and bolts of the project. Including the communication layer and my personal favorite, LOGGING!!!

-Rick

It's me again, Rick the Silverlight nut. I've been buried under a pile of work this last month and haven't had a chance to post much of the fun stuff I've been working on. But I've got a few minutes to write about my last big project. So I give you, the story of KBay:

The Story So Far...

I work for Kerry Americas, a food product company with a corporate office in Beloit, Wisconsin. Over the last year we have relocated much of our sales, service, R and D, and other folks to a brand new, state of the art office building and production facility. This place rocks. This did however, leave us with a whole lot of cruddy old furniture, that had been well-used in many of our older office spaces. So the building managers, remembering that almost a decade ago the IT shop had given them an EBay-like app used to auction off goods for charity, gave us a call. They wanted us to fire up this archaic app so they could try to move the furniture to employees for charity. My boss, seeing an opportunity for something better, got us 2 weeks to get something running. We could either get the classic site up and running again, or make one from scratch in Silverlight, but it had to be entirely off the books.

Racing the Clock...

So we worked our fingers to the bone pulling it off after hours, over lunch, etc, but after 9 days we had a working prototype. On day 10 we demo'd it to the users and they were ecstatic. We had 3 weeks to the auction and we used some of that time to refine and improve the system (I hope to be posting about our communication frame work shortly!)

Going Live...

Last week, Monday morning we went live with over 200 auctions and almost 600 available users. We had a huge load on the server that morning, but everything stayed up and stable. No crashes, no complaints. We had a few minor bugs, and since it was a non-critical app the boss-man gave us the go-ahead to push to production off-schedule.

Down to the Wire...

Friday evening was the big test though. All of the auctions ended at the exact same time. The managers were joking that they had never seen the parking lot so full on a Friday night. And the web server was showing some severe strain. With 300+ users sitting on their favored auction's page, hitting refresh over and over again, the server was having issues keeping up. But it never crashed, it just got slow to access the site.

In the End...

It was a huge success! The company off loaded almost all of the auctions. The employees got some great deals on some impressive furniture. A local charity food bank picked up a few thousand dollars. And we got Silverlight installed on almost every PC in the building AND got some major good-credit with the users.

The Post Mortem...

And post-hoc analysis is pointing to an obvious short coming in our interactions. Since we had developed the application so quickly, we had cut some corners. One of those corners was image caching. Each time users were browsing auctions they were downloading every thumbnail, and every time they looked at a single auction, they would download the full sized image. We had mentioned caching briefly during design, but with a 9 day window, we scrapped it and it was forgotten about while we polished. But looking back now, we could have just hosted the images via an ASP.Net page. Not only would that have solved the hosting issue, but it would have also allowed Silverlight to use the built in browser cache for all of the images. A full caching system without writing a single line of code. We're kicking ourselves now for not seeing it before, but we'll have it in for the next auction!

More to Come...

I hope to have time to post some more of what we learned on this project soon, but I've got another hot deadline approaching for a Silverlight application that mocks Share Point inside of Sales Force.

-Rick