As you can see the site needed some love.  Thanks to the talent of our designer Amanda, we were able to update the look.  Here is the how it looks now, keep in mind that we are still working so the content so some on the screen will change but you get the picture:

Work will continue up until the end, which is a couple of hours away.  Stay tuned for the publish date!

I have to say that after three GiveCamps, the keep getting better.  I  can’t wait to see what next year brings.  To all the sponsors thank you, to all the volunteers until we meet again, and the Jim O’Neil and Kelley Muir for organizing such a fantastic event.  I would also like to thank Microsoft for letting us camp out in your spaces, the views can’t be beat (even overcast):

So until next year!

Well it is that time of year again.  I am once again volunteering for New England Give Camp.  For one weekend, over a hundred volunteers will help over 20 Non-Profit organizations solve there technical needs, getting help that most of these organization would not otherwise get due to cost.  Over the coarse of the weekend these organizations will get technical help, attend seminars that help teach them how best to use technology to their advantage, and network with other organizations.

This year I will be helping redesign the website for Respond, Inc.  They are New England’s first domestic violence agency and the second oldest in the nation. My team will be working closely to help solve all their web needs over the course of this weekend.  Quite ambitious, I know, but we are up to the challenge.  You will have to tune in at the weekend to see the results of our work. Our goal is to leave them with a site that will help them help their clients.

Camp is in the Name

That’s right we spend the weekend working into the wee hours of the morning.  Some go as far as to pitch a tent.  I would like to thank the sponsors who keep us fed and caffeinated. Good luck campers!!!

So the first thing I decided to do was see if any of the apps I built using the Developer Preview would run in the Consumer Preview.  Low and behold neither application would run. After a quick internet search I found Microsoft’s guidance on upgrading applications.  This document comes in at over a hundred pages.  According to what I found they listened to the feedback of early adopters and as such had to make many breaking changes. It was nice to see them listening to the community.  It does mean that any developers that created applications will need to spend time converting their apps. Since the applications I are not that import I decided to hold off on upgrading them.

Making Life Easy

So I decided to work on a new project.  I started by creating a blank C# Metro Application.  After the template finished loading I noticed something new, a ‘Common’ folder.  Inside the common folder there are some interesting files.  The first thing to take a look at is the ReadMe.txt.  In there, Microsoft explains what these new classes are there for.

Here is the contents of the ReadMe file:

The Common directory contains classes and XAML styles that simplify application development.

These are not merely convenient, but are required by most Visual Studio project and item templates. Removing, renaming, or otherwise modifying the content of these files may result in a project that does not build, or that will not build once additional pages are added.  If variations on these classes or styles are desired it is recommended that you copy the content under a new name and modify your private copy.

That is a little scary. These file are here to help but don’t modify them or your project may never work again.  So there are a couple of value converters which are ones I tend to build so thank you Microsoft. There is also a StandardStyles.xaml.  This is a nice change for the previous version where the styles were on each new page. I did not think that would carry through to the final version of the templates. 

Layout My Page Please

This leaves three other classes.  The one that I am going to take a deeper look at here is the LayoutAwarePage.  I will leave the rest for a different post. The first thing to notice is that the class is heavily commented which is nice but how it used?  Well it inherits from Page, so I assume it has to do with code behind files. I did a search of the entire solution for this class and it is not used anywhere.  So I created another solution using one of the other templates.  All the pages in that template inherit LayoutAwarePage.

One of the complaints I had with the Developer Preview is that there was no easy way to navigate from page to page. There was also no means to capture page history.  Hitting the back buttons on a page created by the templates did not necessarily do what the user thought it would.  It may or may not navigate to the last page the user visited.  Of course you could override that behavior but it required build a custom navigation framework.  This is now taken care of in this new class. Here are the convenience methods that handle that for you.

The Page class has a Frame member that handles the navigation and handles the call stack.

Handle Those Turns

One of the sensors that most tablets have is an accelerometer.  This allows user to orient their tablets in any orientation they want.  Also Metro apps can be snapped side by side with another Metro application.  Developers have to handle these changes.  In the Developer Preview each page subscribed, in the code behind, to the orientation event that gets fired. This functionality has been abstracted into the LayoutAwarePage class.  This makes sense since this class is named LayoutAwarePage. Here are some of the methods that handle that:

I like that this functionality has been centralized and removed from the code behind.  I like to develop XAML applications using Mode-View-ViewModel (MVVM) pattern.  Anything that helps limit the code in the code behind I am for.  So how does MVVM play out in Windows 8.

Is MVVM Dead?

When Microsoft released Expression Blend for Windows Phone development, they included a MVVM template.  That made a lot of people happy.  They started wondering when will there be a temple for MVVM within Visual Studio.  Sure there were third party frameworks that contain MVVM templates, MVVMLight being the one I liked the most.  Since there was not a template within the Developer Preview I was hoping that there would be one in the Beta. Alas I was disappointed.

What I did find is that there is a DefaultViewModel in the LayoutAwarePage class. Here is the property declaration:

This is implemented as an ObservableDictionary. This view model is set to the pages DataContext in the constructor.

“Properties” on the DefaultViewModel as you would using any dictionary.  There are two things to note first to pass data between pages through the Frame.Navigate method as NavigationsEventArgs.  Second notice the magic strings.  Bindings are handled the same as before, binding to the magic string noted above.

I am not sure that I like this.  My view models tend to have a little bit of logic in them.  It is convenient to be able to pass data in the navigation event but that would mean moving some service/data logic into the code behind.  I will have to think about this a bit to figure out how I want to handle my view models.

Summary

This was a look at one of the ways that Microsoft is trying to make it more convenient to develop applications.  I don’t like the language of the ReadMe text or how they seem to be forcing a paradigm down developers’ throats. Kind of like how Apple treats their iOS developers. I will have to see how much of a pain it will be to use or not use these convenience classes.

In this post I will take a look at what coming and give my feedback on what I have encountered thus far.  I have had to opportunity to build a couple of demo applications so I have experienced Windows 8 from the point of a developer and a user.  I installed it on the Acer laptop that Microsoft gave away at PDC 2009.  Windows 8 runs have way  decent on that machine though the touch drivers acts a little funny.

Architecture

From the time Microsoft announced Windows 8 to the time they announced the developer experience, there were a lot of rumors as to the fate of Name your favorite development language here. The only known at the time was that HTML5 was going to play a key part of the ecosystem. This sent all the XAML developers into fits. Then along came Build.  During the keynote all was revealed:

As you can see there are two stacks available for developing applications. The blue stack is the same stack that we have now.  The green stack on the left is the new goodness that allows developers to build applications targeted towards the tablet side of the house. These applications are called Metro Apps.  As a side note Microsoft has said that these applications will work just as well with a mouse as it will with touch.

These Metro applications operate just like WP7 apps.  They operate in a sandbox and can only access external resources through well define contracts.  Also they need user permission to access sensors, location data, camera and such.  This gives user a constant user experience. Metro apps are built on a core framework called WinRT.   WinRT abstracts access to the underlining operating system.  It then projects the API in the various languages.

With this architecture, Microsoft open windows application development to a whole new group of people, HTML/Javascript developers.  These developers can develop the same rich applications as the XAML developers, using the same WinRT API. This architecture also keeps C#/VB XAML developers in the loop but brings also brings C/C++ into modern times by allowing them to develop rich user experiences.  At the same time legacy applications will still run in desktop “mode”.

There are so many new features.  Too many to mention is a “short” blog post.  In an attempt to solicit feedback early and often the Windows 8 team have been releasing blog posts about their endeavors to Windows 8. You can read, in detail, the many new features that are coming.  You may even influence their course of action by posting comments on each topic.

Metro Everywhere

Over the years, Microsoft has paid little attention to User Experience (UX).  In contrast Apple has put most of their effort into creating the best UX possible.  In order to keep up Microsoft has recently  started to develop a common style that places UX in the forefront.  It started with Zune software, then it made an appearance in Windows Phone 7, the XBOX dashboard was not far behind, and finally it is the premier UX for the new Windows 8. The style is Metro.

What is Metro? It is a style based on simplicity. Inspired by signage seen in European Subways.  The style emphasizes clean line, subtle animations  and simple fonts.  Metro also takes power consumption into consideration. By standardizing the experience across the Microsoft  ecosystem, the user is familiar with how to interact with the system.  Couple that with the integration across platform and you can see that Microsoft has definitely learned that UX matters.

For Windows 8, Microsoft has published a set of design guidelines.  These guidelines assists developers and designers, in make compelling UX while adhering to the UX that Microsoft envisions for its users.   There has been some rumbling that if you follow those guidelines then how do you differentiate your application from all the rest?  Microsoft has even published in its guidelines on how to accomplish differentiation. 

Below are some screens shots from one of my demo applications.  As you can see I was able to follow the Metro guidelines while allowing my company’s brand shine through.  Windows 8 makes it easy to implement a Metro design.  There are built in styles and animations that helps in following the Metro guidelines.

XAML vs. HTML5

Now that we have a little background on Windows 8 how do we develop applications?  The frameworks available are shown in the green boxes above.  If you start from choosing a UI technology then your choices are HTML5, XAML, and DirectX.  For now we will concentrate on the HTML5 and XAML. Which one do is the best choice?  The answer is the same answer it depends. It depends on your skill set and on if you have resources that you want/need to reuse. 

Lately Microsoft has been emphasizing HTML5 and downplaying their XAML technologies.  In my opinion they are doing this to enable a whole new group of Windows developers.  By exposing WinRT in Javascript HTML developers can now can now build rich applications that will run on Win8 tablets. These developers will be able to develop HTML and CSS that can be reused in web applications.  There may even be some Javascript that can be reused, as long as the pieces of Javascript that interacts with the WinRT projection, are isolated.

XAML developers need not worry.  XAML is there, but not only is it there it has been opened up another language, C/C++.  There is even an opportunity for reuse here.  The XAML in Win8 is closest to the XAML in Silverlight.  The namespaces may be different but the XAML is similar.  Also class libraries be able to be reused as long as the functionality exists in WinRT.

So who can develop Win8 Apps? Web developers…..XMAL developers…C++ developers. The ecosystem of developers is large, larger than iOS and Andriod.  This was a smart move, in my opinion.  In order to steal market share away from those other platforms, Microsoft is going to need a large and varied collections of applications available from day one.  By lowering the barrier to development, they may be able to reach that goal.

It is Just Windows

“I have been developing applications for years, are my skills dead?”  The answer to that no. At the end of the day Windows 8 is just Windows.  You WPF application will run just as it did in Windows 7.  Even your WinForm apps will run.  Icons to launch your applications will even appear in the new start menu. As you can see “legacy” applications will appear side by side with new Metro applications.  You can even optimize these application for touch

Microsoft has creating an operating system that will run on a 7 inch screen all the way up to a desktop with rather large screens.  One of the goals of the system had to have been that it had to run Microsoft’s other cash cow, Office.  The current version of Office should run just fine but is not optimized for touch.  It is rumored that the next version of Office (Office 15) will have Metro versions of Office applications that will even run on devices that use the ARM processor.  The Metro versions will probably on have a limited set of features, features that make sense in a tablet environment.  But since a Windows 8 tablet is still just Windows (there is some debate as to the extent of  “legacy windows” will be available to ARM devices) the user just has to switch over to the desktop and launch the full version of that Office application. My guess is the functionality of Metro will be close to their Office Online versions.

Another nice feature of having full Windows on a tablet is the security features available.  One of the barriers to enabling tablet computers into the corporate environment is security.  Most network administrators are nervous when it comes to letting devices onto their networks that they cannot secure using their tried and true means.  With Windows 8 they will be able to encrypt the hard drive using BitLocker.  They will also have the ability to enforce Group Policy. So securing a table becomes as easy as securing a desktop.

App Store

Another lesson learned from WP7 is they have to control the user experience when it comes to Metro applications.  To do this they are creating an App Store.  This will be the only place where applications will be able to be loaded.  Applications must be submitted to Microsoft where they will be tested to ensure that they are safe for user to install.  The App Store is also where developer will be able to monetize their work.

Summary

This was a long post but there is some much that Windows 8 encompasses that I did not even scratch the surface. My observations have been made against the Developer Preview which has been out since September. With this release the development tooling is a little lacking, only an express edition of the next version of Visual Studio and an Expression Blend that only works with HTML5 applications.  There quite a few bug that popped up from time to time.  In less than 2 weeks a Consumer Preview will be released with a final version rumored to arrived later in the year.  

If Microsoft is able to deliver all that they have announced thus far they will have a viable competitor to Andriod and iOS.  They have taken a page out of Apple’s book and kept the details of Windows 8 under tight wrap. Hopefully the next release of Win8 will more details of what is yet to come.  I have enjoyed developing Metro apps and the tablets given to Build Attendees is a nice piece of hardware.  I am looking forward to the different form factors that been rumored to be delivered later in the year.  I just hope that Microsoft does Windows 8 right and that it does not become another Windows Vista!

State of The Environment

I find it funny how these things go in cycles.  It is like the cycle of Client/Server –> Desktop –> Distributed.  If you think about it the technology of the time dictates the paradigm flavor of the month.  Take the switch from web apps to native switch right around the time smartphones started to become more common.  Native apps emerged to take full advantage of the hardware they were running on. Along comes HTML5 that starts to take advantage of parts of this functionality. So where does that leave us? Go native? Ride the leading edge of HTML5?

One of the reason native applications became prevalent in mobile applications is because the vendors keep out plugins that enabled rich applications. That left the developer with two choices: a) go native or b) go web.  Each of these has advantages and disadvantages. Native allows the developer to utilize the full feature set of the device, but for companies that want to be on all platforms, this requires redevelopment of the app into each native form.  If the developer decides to go the web route, they cut down on development time/costs but more than likely they can’t take advantage for all the capabilities the devices have to offer.  They also develop an app that doesn’t follow the visual design standards for the device. Windows Phone has Metro, Apple wants their apps to look like iOS apps, and even Google has guidelines for Andriod.

Keeping Developer Costs Low

So how do companies keep their development costs low while creating native apps for all the platforms?  They use frameworks that take one language as input and output native applications or HTML5 equivalents.  The input languages could be HTML5, Xaml, C#, or others.  The problem with approach is that the conversions don’t always take advantage of all the functionality of the devices. Or they can only handle a small subset of tasks (look at ComponentArt Mobile Dashboard Server). The ComponentArt server takes in Xaml and outputs many different formats that works on all different platforms.  The problem is that the input is Xaml markup of a ComponentArt dashboard.

Another barrier to conversion frameworks is cost.  So you are cutting developer costs but the costs of the different frameworks may wipe out and savings you are getting.  The aforementioned ComponentArt Server cost in excess of $10k (at the time of this post).  That’s a lot to pay for such limited functionality.  When evaluating whether to use one of these frameworks you should keep the cost vs. functionality in mind.

The Best of Both Worlds

Some organizations try to get the best of both worlds by creating hybrid applications.  They use native where it makes sense and incorporate HTML components when needed.  This allows them to create reusable components that can then be utilized within native applications.  This is just one way to get reusability out of common components. There are issues here.  Not all platforms handle hosting HTML within native apps the same so there maybe some workarounds that need to be implemented.  So how much time/money are you really saving.

Reusability to the Max

Another way to maximize reusability is to encapsulate as much business/data access logic behind web services.  Now the native app only has to handle creating a compelling user experience for displaying data.  That is where native apps excel.  Developers can take advantage of the capabilities/design guidelines of each platform.  What’s the catch? Well this approach requires the device to always have a connection and in certain situations a high bandwidth connection (data dependent).

When is Enough, Good Enough

Sometimes you have to ask yourself “When is enough, good enough” for my users.  There are situations when a mobile optimized web application is “good enough”.  If your applications does not require an accelerometer or fancy touch gestures then go ahead and build that web app.  Content delivery applications are another good candidate for the web.  These apps usually don’t have heavy interactivity requirements. Besides at the end of the day most users ignore apps on their mobile devices.

Summary

At the end of the day there is no right or wrong answer to what app should I build.  The situations, time, developer skill set, target audience, and budget are all going to factor into the decision on application type.  It is always good to look at the trends leading up to this point in time. 

What will the future hold?  Which paradigm will drive future development?  These are questions that only time will tell. If we don’t learn from the past we are destine to relive it.

I have recently started to look at reusing a Silverlight 4 ViewModels in a WP7 applications. I figured this would probably be the easiest place to start since they are both Silverlight. I was recently asked what would it take to make a component reusable across Silverlight and WPF.  That figures right into my ViewModel sharing research. I will start by looking at different ways to share code across all three frameworks.  In a future post I will explore ways to reuse Xaml.

The Challenges

Let’s start off by examining the challenges associated with this task.  The first challenge is the fact that they are three different frameworks that are designed for three different use cases.  That means that any reusable code would have to be coded to the lowest common denominator.  In this case it means WP7.

For this post I don’t have any working code to share but I have been trying a few things.  One of the first things I ran into was in the System.ServiceModel namespace.  Each framework handles calling web services differently.  Silverlight and WP7 can only make calls asynchronously and WPF defaults to synchronous calls.  I am still working out how I want to handle this.  There are other challenges too, take third party libraries for instance.

Another challenge that you are going to face is keeping consistent namespaces across the frameworks.  If your organization has a strict naming convention then this could become a challenge.  Luckily you control what your namespaces are but it can become quite hairy if you are not careful. 

Third Party Libraries are usually compiled against specific runtimes.  The third party library that I consistently use when working with Xaml is the MVVM Light Toolkit.  Luckily the MVVM Light Toolkit is compiled against the different Xaml runtimes and the functionality is consistent across the frameworks.  But with other libraries you may not be as lucky.  Now it is time to talk about the different options available for reuse.

Copy and Paste

The most basic method is copy and paste.  This is a quick and dirty solution.  First you create a file that works in one framework.  Then you create that same file in the other projects copying the code from the original class to the new class.  The up side to this method is that you can tweak the code for each framework.  But red flags should be waving and alarms sounding.

Copy and paste architecture is NOT the key to a reusable strategy.  There is no means to update the code once it resides in each project since the code is not linked together. Any change would need to be propagated across the different files.  Which may be ok if there is one “shared” file and more than that and you are asking for a nightmare. In other words there is no maintainability or scalability with this option.

Add As a Link

The next option I explored is add linked files to the projects. For this method you create a class in on project and then add it as a link to another project.  In the “Add Existing Items” dialog you can navigate to the file you want to link and select “Add As Link” from the “Add” button dropdown.

You can tell the file is linked by the icon of the file in the linked project. With this solution there is only one physical copy of the file.  Each project then compiles the file against the proper framework. The up side to this approach is that there is only one file to maintain.  On the downside namespaces can become an issue. You may also have to use conditional compile tags if modifications are needed.  Conditional tag will allow for the use of different using statements when it comes to third part libraries as long as the internal namespaces are consistent.

Portable Library Tools

The final method I looked at was the Portable Library Tools from Microsoft. The Portable Library tools

is a new Visual Studio add-in from Microsoft that enables you to create C# and Visual Basic libraries that run on a variety of .NET-based platforms without recompilation. – Visual Studio Gallery Description

The add-in can be downloaded from the Visual Studio Gallery.  This method allows you to create a class library that can run against many of the .Net runtimes.  To accomplish this the class library compiles against a very restrictive version of the .Net framework.   This can be a challenge when planning out what to include in a reusable library.

Since this project is still in the CTP/Beta phase not all of the available frameworks libraries have been included. Most notably there is no odata support so you cannot create a reusable odata access library with this tool. According to the Q and A tab in the gallery there is a product road map that plans to include more of the framework.

On a side note it looks like this tool is part of the developer story for Windows 8.  Take a look at the response, on the Q and A Tab, to the “System.Threading.Thread problem” question.

We needed to remove explictly thread creation for a reason that we’re not ready to discuss yet (ask me again in 3 months).

Note that the Build Windows Conference is three months away.

Conclusion

Sorry there is not any working code for this post.  I am still mulling over how I want to accomplish my goals.  I wanted to put this together to organize my thoughts and get feedback from others who have tried for reusable nirvana.  One of the lessons that I have learned so far is be picky about what you include.  The different frameworks kind of take care of that for you by restricting what libraries are available.

The other early lesson I have garnered from my investigation is that you have to be more aware of Framework updates that could break your reusable code.  There is a lot of churn happening right now with Xaml frameworks (Silverlight 5 and WP7.1).   New releases may break what you are doing but they may also bring in more components that can be reusable! 

Next I will be looking to see how compatible Xmal is across the different frameworks. The ultimate goal is to develop a strategy that allows components to be used across Silverlight, WPF and Windows Phone.

This weekend was the second annual New England givecamp.  A weekend dedicated to helping out charities with technical projects.  These projects range from designing web sites to building out content management systems.  In addition to getting technical help there are seminars designed to help charities make the most of the technology they are getting.  This weekend there were sessions on content management, engaging social media, and others to help these organizations grow in a highly technological world.

First I would like to thank all the sponsors of providing the means to fuel all the activities this weekend.  What does it take to keep developers developing…..a lot of support so again thanks.

Next I would like to thank Jim O’Neil and Kelley Muir for organizing the event.  It may not have seemed it to you but to us it was very well organized.  Leaps and bounds over last year.  Which means next years should be spectacular…..no pressure!

The one thing you need to realize is that the word camp is in the title and camped we did.  A number of the volunteers camped out here at Microsoft’s New England Research and Development Center, affectionately known as NERD! Thank you Microsoft for letting us have run of your beautiful facility for the weekend. There was plenty of room for people to pull up a piece of the floor, grab a couch and pitch a tent……wait pitch a tent?  That’s right some people even pitch tents!

As I stated before it takes a lot of food to keep an Army of Techies moving.  The food this year did not disappoint!  We had  chowdah from Legals, sandwiches for Cosi and pizza from Naked. 

And when there was too much food what did givecamp do?  Give it away, of course, to a local shelter:

“took #givecamp leftovers, fruit, chips to CASPAR in Cambridge – shelter housing 100 tonight. Another way #negc2011 makes a difference.” @jimoneil

So here we sit, the morning of the final day.  Tech teams have 5 hours to get their projects done.  They are frantically racing to deliver quality projects to their charities.  The key word is quality.  The goal is to handover all the work to the charities so they can build upon a foundation laid out by their tech teams.

So until next year I leave you give camp with this quote

“Ladies and gentlemen, take my advice, pull down your pants and slide on the ice.” Dr. Sidney Freedman (M.A.S.H.)

And I would add

Get out of your office and do something nice!

Goals

The ultimate goal is to keep the UI specifics out of the view model.  This separation increases the reusability of the view models while at the same time allowing for maintainability and testability.  Another goal is to abstract out the launching of child windows so that they can be easily launched from any view.  A good example of this is an Error Window.  I will show an example of this in this post.

In this post I will show launching a dialog that requires passing data from the view. I will show an example that returns data from a dialog that the view model can consume. Finally I will show an example that takes my ReturnAction<T> object (described in my last post here) to handle passing data back including any exceptions.  You should be able to handle any situations by interchanging these building blocks. 

All of my child windows have their own view models so I am limiting the amount of code I place in my view’s code behind.  I am not an MVVM purist.  I believe you can put code in the code behind as long as you limit it to view specific code and do not do any business logic there.  In my case I will be setting properties on the DataContext (ViewModels).  I will also be closing the child windows from the code behind as you will see in later examples.

The Pieces

The first step is to abstract the launching of the dialogs.  To accomplish this I create a navigation service.  Here is the interface for my navigation service:

As you can see I have three different child windows in this demo, each requiring different data.  Note you could also add a method for navigating to other pages if you are using a Silverlight Navigation application.  This would allow you to navigate from page to page from the view models.

The actual implementation is responsible for launching the child windows passing any required arguments.  Here is what my implementation looks like:

Note the two different ways I am passing arguments to the child windows.  In the first method I am passing an exception to the constructor of the ErrorView child window.  I will then pass this parameter to the DataContext in the code behind of the ErrorView.  The second dialog takes no arguments and returns a message that gets displayed in the main view.  The final dialog takes a ReturnAction<T> which it uses to pass the results back to the main view.

The NavigationService is injected into the ViewModels  from the ServiceProviderBase through the ViewModel Locator (described in my last post here).  I treat the NavigationService just like I treat the my service wrappers from my service layer.  The NavigationService provides a service for the view model. 

A Reusable Error Dialog

One of the most common dialog in an application should be the error dialog.  There should be a mechanism to display friendly messages when an exception happens.  This is especially useful when fault exceptions come back from service calls.   I will be showing an example of this when I show the dialog that works with my ReturnAction<T>.  For now I am going to explain how I implemented the ErrorView dialog.

You can see from the code above that I am passing the exception to the DisplayError method in my navigation service.  It then calls the constructor on the ErrorView passing the exception:

In the constructor I am casting the DataContext as an ErrorViewModel.  I the set a property, that I created, with that exception.  The DataContext is set in my Xaml (described in my last post here).  Through the magic of data binding the dialog calls ToString() on the exception and displays it to the user.  If the dialog looks familiar it is because it is the same one that gets created by the “Silverlight Business Application” template in the New Project dialog.  This shows how easily that can be adapted to fit this architecture.

Now to launch the dialog I bind a command to the button from the MainViewModel:

That is how easy it is one line of code (line 77).

Handling Return Data

The next example will show how I handle dialogs that need to return data to the underlying View/ViewModel.  In this example I am going to use the Messaging capabilities of the MVVMLight framework.  There is nothing fancy with how I create the dialog.  It is exactly the same way I created the ErrorView dialog above except that I am not passing any arguments. This is the dialog that gets launched:

I bind a command to the ‘Ok’ button from the ViewModel:

Here the Messenger class takes a MyMessage object and sends it out setting TheMessage property with the text in the TextBox. In the MainViewModel I subscribe to the message from the dialog.  It takes the MyMessage object and uses it to set a property on the MainViewModel that is bound to a TextBlock on the view:

The final thing to do is close the dialog.  Since we removed the click handler from the ‘Ok’ button, the code that usually closes the dialog no longer gets called.  So I subscribe to the same message in the dialog’s code behind.  In the Action of the message I call the code that closes the dialog.

One thing to note, it does not matter what you set DialogResult to.  We are not subscribing to the close event of the dialog.  We are handling any business logic (whether the user clicked ‘Cancel’ or ‘Ok’) through messaging.  It is up to the view models to take appropriate actions.  Theoretically you could hold off sending the message until a service returned and not do it right on the button click.  This would allow for a save action, for instance, to complete prior to closing the dialog.  But the decision to  close now resides with the view models and not the view.

An Alternate Way

The previous example is one way to get data back from a dialog.  Here is another way.  It is a combination of the ErrorView (getting an object in) and the last example getting data back.  In the ErrorView example I use the view code behind to set a property on the DataContext.  Here is an alternate way to accomplish the same task without using the code behind:

To understand what the ReturnAction<T> is look at my previous post here.  In a nutshell it captures a return object or and exception and allows the caller to create a call back method that gets called when the Notify method is called.  Here is the ReturnAction<T> getting created:

The constructor takes an Action callback which I will show in a few minutes.  In the dialog I create commands to bind to buttons on the dialog. For this example I simulate a message and simulate an exception being thrown:

(Note: I still have to use the Messenger to close the dialog).

In the MainViewModel I can now handle the action appropriately.  If there is a message I can display it and if there is an error I can handle it.

Conclusion

These example should give you some ideas as to how easy it is to use MVVM in your Silverlight Applications while dealing with Child Windows.  With a little bit of infrastructure in place you are able to work with different views passing data back and forth.

If you want to play with the code you can get it here.

In this post I will document an approach that I have used a couple of times that allows me to layer my Silverlight application in the way I would any other application.  That is the first trick to developing in Silverlight.  Treat the Silverlight part of the application as if it were is its own application, because it is! This holds true whether you are using RIA Services or getting your data from an external web service. By treating it as its own application you tend to bring in accepted coding practices but as I stated before there are some challenges.

For this blog I am going to use a project that I just started and will be working in my spare time.  I am building a File downloader to download content from Microsoft’s Mix11 Conference. This little project was inspired by a project Mike Taulty did for last year’s PDC.  I know that there are easier ways to download the video content from the conference.  Scott Hanselmen documents one such way by using the RSS feeds from Channel 9. This is more of an exercise to build an application that consumes an OData feed while at the same time maintaining an elegant solution.

Here is my initial layer diagram that I am working form:

These are the layers that I have come up with and will be working with through out this project.  I will be covering the details and interesting aspects of each layer in the following sections.

Presentation

I choose to use M-V-VM when I develop with Silverlight.  This pattern allows for separation of the UI markup from the functionality.  There are many frameworks that help out when working with MVVM.  The one I like to use the most is MVVMLight.  This is a nice light weight framework that contains a bunch of templates, some base classes and a messaging service.  Laurent Bugnion is even adding a light IoC container in the next version.  There are other frameworks that perform similar functionality and are just as good (Prism for one). I started using MVVMLight a few years ago and haven’t turned back since.

The next key to an elegant solution is to use a ViewModelLocator.  There are a few schools of thought when it comes to binding ViewModels to Views.  Some new them up in the constructor of the Views.  The problem with this is that there is no design time feed back using this method.  Others like to declare the binding in Xaml.  This is similar to how I do it except that I bind to a property in my ViewModelLocator.  With a ViewModelLocator you can control the lifetime of the ViewModel (new instance for each load or created once for the lifetime of the application).

Here is my ViewModelLocator:

Here you can see that I am using my locator class to inject a dependency into my ViewModel (I may changes this in the future to use the Simple IoC class from the MVVMLight framework).  I create an entry in a Resource Dictionary for my locator class.  So binding the ViewModel to the View is as simple as this:

In my ViewModelLocator you should notice a class called ServiceProviderBase.  You may be asking yourself what purpose does this serve.  I will tell you.  As you recall from our layer diagram our data access services live in another project. This class serves a factory for serving up our services.  In order to have design time data a DesignServiceProvider is created. Let’s take a look at the base class:

As you can see it is implemented a Singleton and which instance to serve up is determined in the CreateInstance method.  This method determines if it is design time or run time and serves up the proper provider.  That rounds out my Presentation Layer except for some Resources and Value Converters (the other things that make the UI elegant).

Model

You can’t have MVVM with a Model.  If you did you would VVM and that just does not look balanced! In this project I am not doing anything fancy.  I did decide to create a model that is separate from the model that is generated from the service proxy.  This will allow me to switch out the service layer implementation (say when the next conference happens) with little impact to my presentation layer.  I handle the mapping in the service layer. That concludes the model layer, I will now return you to your regularly scheduled program…..I told you not too exciting.

The Commons

When I am developing Silverlight application, I find that there are some classes I can’t live without.  These classes are needed in all the layers so I like to pull them out to a separate project that can be referenced throughout the application.  Someday I may even create my own open source collection of these things.  One of the biggest short comings of the Silverlight framework is a means to convert an IEnumerable into an ObservableCollection.  ObservableCollection’s are used to bind collections to the ItemsSource property of ItemsControls.  The observable part is what allows for updates to be delivered to the UI when something changes.  So I implement this as an extension method in my common project.  This is the kind of stuff that I like to put in.

One of the key things needed to separate out the services from the rest of the application is to have a means handle the asynchronous nature of service calls, especially when they are happening in a different dll. How does that presentation layer know when the service call they made is finished?  I have seen a few different ways to handle this including creating events in my service layer that the ViewModels cans subscribe to.  This is kind of like recreating the functionality in the proxy.  This approach can complicate things when it comes to unit testing.  The approach I like to take is to build out an object that contains a callback action.  This approach is similar to the approached outlined by Ben Day in his post Silverlight Asynchronous WCF Calls Without Ruining Your Architecture. Here is my implementation of his ReturnResult object:

The premise is that this object will be passed into all service calls.  When the service returns the Notify method is called with either the results or and exception.  The ViewModel can then handle this.  This brings us to our Service Layer.

The Serivce Layer

This is the layer that is responsible for ferrying the data between the source and the Presentation Layer.  The source can be anything from an RSS feed to a SOAP Service or in our case an OData feed.  Here I am abstracting out the how the data is retrieved allowing the Presentation Layer to concentrate on presentation.  I start out by creating a ServiceBase that is responsible for instantiating the proxy.  Here is my ServiceBase for the Mix11 OData feed:

I then create a design time service that returns design data and I create an actual runtime service.  In Silverlight all service calls return void.  The magic happens in the callback method.  How do I get access to my ResultAction<T> object in the callback method?  With a proxy created from a web service all the service method calls have an overload that takes an object that is available in the callback.  all you have to do is cast it as the ReturnAction<T> and be on your way.  I could not find such a thing when dealing with the DataServiceCollection<T> object used to pass queries to the OData service.  So I created my own caller that inherits from DataServiceCollection<T> and has a property to hold any state that must persist after the call returns.  Here is my caller:

And here is an example of this class in action pre call:

and post call:

This also shows the ReturnAction<T> class in action.  All my services implement interfaces that are used by the Presentation Layer in the ServiceProviders.  The Service Layer allows for many different data sources.  Adding/subtracting sources or even changing source will not have any affect on the Presentation Layer as long as they adhere to the contracts set forth in the interfaces.

Conclusion

This is a good place to stop for this post.  In this post I have laid out a layered architecture that can help developers build elegant Silverlight solutions.  I have addressed some of the pitfalls associated with Silverlight development and proposed solutions to those pitfalls that have worked for me.  As I get further along in my quest for building this downloader I will write further post that other may find useful.

The first question to as is why do I care about the Windows credentials of the user?  The simple answer is that I am building an internal Line of Business (LOB) application and I want to use Windows Authentication .  This makes sense.  If your company does not have a federated solution so that you can use claims base security, then Windows Authentication is the next best thing. 

Start out by creating a Silverlight application using the defaults, letting the template create the web application for you.

The first thing that you want to do is set up the web application to restrict users from accessing your web resources (xap files, .svc files, etc…).  To do that add the following code to your web.config file:

Obviously you would restrict the “allow” to specific domains and add a deny key for all other users.  You can restrict down to the folder level, allowing different access rights to different folders.

Now you are ready to create the a service.  For this example I am did a simple “Hello User” service.  It has a single method that returns the Windows Identity of the user making the call.

Ok the service method is configured, you need to modify service configuration in the web.config.

The key to this is the “security” configuration in the binding.  Once the service is configured you add a reference from the Silverlight client just like you would normally do.  There is nothing else you have to do.

My coworker then came back and said, “Our services are hosted on a different server this surely this won’t work in that situation?”  So I added another web application created an identical to the service I created in the original web application.

What do you think happened?  The same results. So it didn’t matter what server the services were on a different servers.

In this situation the client technology doesn’t matter.  The client could be WPF or even Winforms.  The key is your service configuration.