Rants Tagged with “Silverlight”
As regular readers of my blog know (RIA Services Concerns Squashed), I have been a lukewarm supporter of RIA Services for Silverlight. As many of you know, Brad Abrams and company have come through with their latest release (RIA Services Preview July '09) with lots of changes I've been hoping for. Honestly I haven't had time to look at the new build (probably this weekend), but I am hopeful of its overall direction. I am still somewhat tentitive about some of the basic behavior of the framework but I will hold my tongue until I have more time to dive deeper into the code.
What really concerns me is that I've talked to students and others and many are opting to building systems with RIA Services right now. This only concerns me because RIA Services is not part of Silverlight 3 and is not released. Actually, the July version is a "Preview" (something like a CTP) which means they haven't even reached Beta with RIA Services. Now many these developers are working on very long time lines and can wait until RIA Services releases, but while investigating it makes a lot of sense (and I encourage everyone do that), building production code against a framework that is still in transition is a risky venture in my opinion.
I am curious who out there is using RIA Services in production systems that will ship this year. Could you comment on the blog with whether you're using it for an upcoming project?
Recently while in Vancouver for DevTeach, I sat down with Carl Franklin and recorded a couple of DNR-TV episodes. The first one is on Behaviors (and how to write them). If you're interested in Silverlight, Blend or Behaviors...head over the DNR-TV site and take a look.
http://dnrtv.com/default.aspx?ShowID=144
I was with a client recently and we were looking at refactoring some of their system to use Prism. This client had created a lot of infrastructure to do what Prism does (before Prism was released for Silverlight) that they wanted to opt into using Prism instead.
Out of the box Prism works well for composing your applications, but for particular cases it may not be perfect. In this case the client wanted to be able to process the .xap file before it was passed onto to the module loader. So looking through Prism's Modularity code and found that IModuleManager interface. In order to provide my own implementation I wrote a simple implementation of the interface:
public class CustomModuleManager : ModuleManager
{
IEnumerable<IModuleTypeLoader> typeLoaders;
public CustomModuleManager(IModuleInitializer moduleInitializer,
IModuleCatalog moduleCatalog,
ILoggerFacade loggerFacade)
: base(moduleInitializer, moduleCatalog, loggerFacade)
{
}
// Replace the module loader with our own
public override IEnumerable<IModuleTypeLoader> ModuleTypeLoaders
{
get
{
if (this.typeLoaders == null)
{
this.typeLoaders = new List<IModuleTypeLoader>()
{
new CustomXapModuleTypeLoader()
};
}
return this.typeLoaders;
}
set
{
this.typeLoaders = value;
}
}
}
This module manager is mostly used so I can get at the module loader list. In this case I just returned a list containing my own custom XapModuleTypeLoader as shown above. My custom module loader looks like this:
public class CustomXapModuleTypeLoader : XapModuleTypeLoader
{
protected override IFileDownloader CreateDownloader()
{
return new CustomFileLoader();
}
}
The thin implementation of the ModuleTypeLoader is to simply inherit from the existing XapModuleTypeLoader class and just override the CreateDownloader to return a custom downloader. The custom downloader is key as that is what downloads and returns the Stream that contains the actual .xap file. By writing my own, I can intercept the .xap file before it gets returned. Here is the CustomFileLoader:
public class CustomFileDownloader : IFileDownloader
{
FileDownloader dler = new FileDownloader();
public CustomFileDownloader()
{
dler.DownloadCompleted +=
new EventHandler<DownloadCompletedEventArgs>(dler_DownloadCompleted);
}
void dler_DownloadCompleted(object sender, DownloadCompletedEventArgs e)
{
// Remove the event handler (so we don't leak)
dler.DownloadCompleted -= dler_DownloadCompleted;
// If someone cares, decrypt the stream and throw the event
if (DownloadCompleted != null)
{
if (e.Cancelled || e.Error != null)
{
DownloadCompleted(this, e);
}
else
{
// Before you return the resulting stream,
// make any changes you need
DownloadCompleted(this,
new DownloadCompletedEventArgs(e.Result,
e.Error,
e.Cancelled,
e.UserState));
}
}
}
#region IFileDownloader Members
public void DownloadAsync(Uri uri, object userToken)
{
dler.DownloadAsync(uri, userToken);
}
public event EventHandler<DownloadCompletedEventArgs> DownloadCompleted;
#endregion
}
The downloader is pretty simple in that it uses a FileDownloader to do the downloading and just provides a place where we can intercept the download before it returns stream.
All this code was essential written to allow us to replace the default implementation of the IModuleManager. But how do we use the new IModuleManager? Since Prism uses Unity for Dependency Injection, I realized I could just register my type with the container and it would be used:
public class Bootstrapper : UnityBootstrapper
{
// ...
protected override void ConfigureContainer()
{
Container.RegisterType<IModuleManager, CustomModuleManager>();
base.ConfigureContainer();
}
}
By simply registering the IModuleManager with the CustomModuleManager, Prism gets injected with my implementation of the interface. Elegant.
This holds true for many parts of Prism. If you need to replace some implementation of the Prism framework, before you start modifying the source code, make sure you can't just implement the interface and use the container to inject it into the system.
You can get the source at:
http://wildermuth.com/downloads/CustomModularity.zip
I had a chance to sit down (metaphorically) with Dmitry Lyalin and Peter Laudati and talk about Silvelright, MVVM and Prism 2.0. Let me know if you agree, disagree or think that I am a little obsessed with IoC containers.
The Connected Show is a podcast on New Microsoft Technology for the developer community, produced independently by Dmitry Lyalin and Peter Laudati.
.jpg)
The new MSDN Magazine is out and my article on creating composite Silverlight applications using Prism is finally available. If you're building large scale Silverlight applications and need to learn how to compose pieces of your application together, go read the article!
I am here at DevTeach and having a great time. I got in a discussion with several of the speakers about the common complaint of some Silverlight/WPF folks that they want Blend to be in Visual Studio; or why Cider has always been disabled by most dev's.
I hear the complaint a lot that developers want the functionality of Blend hosted in Visual Studio. While I understand the desire, I've never been bothered by the dual programs. In fact, I think its better. Blend needs to be separate because its primarily for a Designer/UX role that isn't comfortable with the breadth of Visual Studio.
We have plenty of other solutions that have two overlapping tools: I can insert an Excel spreadsheet in Word but when I need to do an if/then analysis I use excel. A single Office App would be silly. Finally (I think the most compelling example) is SQL Server. When I am in Visual Studio, I can open a database connection and run queries, create stored proces and more. But if I want to manage users, create backup plans or other DBA-like tasks, I go to SQL Server Management Studio. I can do many of the same tasks in both, but developers never ask for Microsoft to remove SQL Server Management Studio and fold it all into Visual Studio. Different roles mean different tools (roles != people btw).
What do you think?
Fun first day here at DevTeach. I a talk showing creating a MVVM application from scratch (using ADO.NET Data Services 1.5 CTP). Kathleen Dollard had introduced the concept earlier that day, but we teach it a lot differently so it was fun to show off building a full MVVM application in the span of 75 minutes.
The project we built in the talk is now available here at:
I the demo is a little big because I included the database (that includes some additional information). You will need Silverlight 3, ADO.NET Data Services 1.5 CTP and to attach the database (as XBoxStore) to SQL Server Express to get the demo to work. I introduced the topic of separation and isolation of contract with interfaces. Hope it helps!
Looks like RIA Services finally has a roadmap. Wahoo:
- July 2009 CTP: Still listening to lots of changes and perhaps a golive license (but not firm yet).
- PDC 2009 Beta: Feature Complete but bug fixes are coming.
- First part of 2010: RTW (my guess is MIX 10 but who knows)
Hopefully the July 2009 CTP will have lots of changes I love. Stay tuned for what I think when it releases.
As I wrote and subsequently taught the Silverlight Tour workshop, I've had a number of discussions with students, clients and the community-at-large about how to architect Silverlight applications.
The momentum behind the Model-View-ViewModel (MVVM) design pattern makes a lot of sense to me, especially with declarative views (as seen in Silverlight and WPF). Most of my thinking around this was covered in my MSDN article about it:
http://tinyurl.com/slmvvm
One topic that the article is thin on is how the View and the ViewModel are related. After the article shipped, I had some lengthy conversations with lots of people about this from John Papa, Laurent Bugnion, Glenn Block, et al. It occurred to me that some of the nomenclature was confusing. The three parts of the MVVM are:
- Model: Responsibile for managing and delivering data.
- ViewModel: Responsible for shaping, sorting and filtering data for a view(s).
- View: Responsible for formatting and displaying data.
The three elements have a clear separation of responsibilities. Typically a small number (or one) model exists in my projects with Views and ViewModels being built in pairs. Though it is not uncommon to build more than one view for a single ViewModel. As long as the separation is there, having two views that show the same data but in very different ways is in keeping with the pattern in my opinion. This can be seen in this simple illustration:
Most what I've mentioned in the article and so far in this blog post is what most of the community seems to agree on. The last part of the contention is how do you create Views and ViewModels. The two approaches I hear most often are:
- View-First: The View has a relationship to its ViewModel(usually through data binding).
- ViewModel-First: The ViewModel creates the view (usually through an IoC container).
In View-First, it is usually is exemplified in XAML like so (as I showed in my article):
<UserControl x:Class="MVVM.Client.Views.GameView"
...
xmlns:data="clr-namespace:MVVM.Client.Data;assembly=MVVM.Client.Data">
<UserControl.Resources>
<data:GamesViewModel x:Key="TheViewModel" />
</UserControl.Resources>
<Grid DataContext="{Binding Path=Games,
Source={StaticResource TheViewModel}}">
...
</Grid>
</UserControl>
In ViewModel-First, it is usually implemented using a Inversion of Control container (e.g. Unity, Ninject, Spring, etc.). This way the ViewModel can request the interface (in the constructor) for the View it expects:
public MyViewModel
{
public MyViewModel(IMyView view)
{
}
}
In both of these methods I tend not to like the sticky-ness of the view to the view-model. Also, both of these imply a one-to-one relationship which while the common case, is not the always case.
I have come up with another pattern that I am tentatively calling a "Marriage". (I don't love this name but its the closest, non-technobabble name I've found for it).
Marrying the View and ViewModel
In my design, I want the View and the ViewModel to be ignorant of each other so that I could mock either side of the equation without impacting the other. In practice, mocking the View-Model is common, but mocking (and testing) the View is not common at all. But by not tying them tightly, it does allow us to move to a one View-Model to multiple Views without any real pain.
In a Marriage, you would simply apply the ViewModel to the View at runtime. This may be done with a class that handles and isolated this or simply with some simple code. For example, I typically have an IView interface that requires a method to do this applicaiton like so:
public interface IView
{
void ApplyViewModel(object viewModel);
}
Then in the module declaration for a module (or assembly) holding the View and ViewModel, I simply use the IoC container to create them (either using Interfaces or class names depending on the complexity of the project) then apply the ViewModel to the View via the interface:
IView view = theContainer.Resolve<IGameView>();
IViewModel vm = theContainer.Resolve<IGameViewModel>();
view.ApplyViewModel(vm);
The magic of this code is that you retain the anonymity while perserving the functionality. It becomes the user of the View/ViewModel's responsibility to determine how they are related.
I explain this pattern in my article on the Prism Framework and Silverlight coming in next month's MSDN magazine. Using this pattern with an overall Composition pattern for building your applications has a number of benefits beyond separation of responsibilities and testing.
Just to throw a plug in as well, I also teach this pattern (and Prism) in our Advanced Silverlight Workshop coming to Seattle in August.
Let me know what you think of this versus the View-First or ViewModel-First patterns.
A few weeks left before the Silverilght Tour hits Washington, DC for Silverlight 2 and 3! If you want to be ready for the next version of Silverlight, this is the place to be.
On June 16-18th in Washington, DC our three-day Silverlight workshop is going to teach the latest features of Silverlight 3 as well as the complete Silverlight 2 stack.
The new features we are covering include:
- Out of the Browser Support
- Pixel Shaders
- Hardware Graphic Accelleration
- Behaviors
- Navigation Framework
- Blend 3
- Binding Improvements
- Secure Web Services
- Binary XML Transport
- RIA Services Client Controls
- Text Rendering Improvements
- Render Caching
- And more...
To sign up for the class or hold a seat, visit the registration site:
http://silverlight-tour.com
On June 6th, the Cap Area Silverlight SIG will be holding a Silverlight Firestarter in Washington, DC as well (free). The Silverlight Firestarter is "A Silverlight Fire Starter is a one-day event providing developers and designers information on the concept behind Silverlight as a technology, what tools are useful in development and the knowledge in order to start building their own applications."
Their agenda includes:
- Keynote and Intro
- Building a basic Silverlight Application (with Databinding)
- Using Expression Blend
- Lightning Talks at Lunch
- Intro to Silverlight 3
- Lessons Learned - Bringing your existing skills to Silverlight
- Open Panel / Q&A
We will be giving away a free seat to the class at that free event. You can register for the event here:
https://www.clicktoattend.com/invitation.aspx?code=138392
