Rebuilding the App Shop

During the past couple of weeks I’ve rebuilt my App Shop, the portal that backs up posts in this blog with demo applications, where I keep solutions to problems I’ve built for the community, and other items of my portfolio. The App Shop is now a pure Silverlight application; you can access it only if you have Silverlight 4+ installed on your computer. This blog and the Silverlight community pages are the broadly accessible entrance to my work and portfolio.

So, anything worth mentioning about this rebuilt portal? Well, I like to think so. If one builds a portal like this, there are a number of requirements that need careful, integrated implementation. These requirements, concerning Compositionality, Navigation, MVVM implementation, and Blendability, will be discussed below.

Requirements

Compositionality

Reasons why you want your Silverlight application to be composed of small components that are downloaded selectively only if they are required (and cached after that) are abundant. The web server that hosts the App Shop, for instance, is located at my home. Measurements show that the upload speed from my home to an Internet Backbone is 0.8Mbits/s. So if you request the portal to show an App, that App just has to be small, or streamed, in order to provide an acceptable download experience.

Despite the slow upload connection to the World Wide Web, visitors of the portal should have a first view of the portal quickly. So, the portal has to start from a small initial component.

The App Shop also has to be easily extensible, where easy also means ‘without recompilation’. Since this is an App Shop you might expect that Apps will be added to it at a regular basis. Since this whole portal is about the Apps, and only about the portal itself in as far as it is a (going to be) showcase of a portal that I could build, it should not take much effort to add Apps to it.

A final compositionality requirement is that shared assemblies, such as the Silverlight System assemblies should be downloaded only once, then reused by further downloaded components.

Navigation

Navigation requires a master page and components one can load into the uniform environment the Master provides. In an extensible portal, you also want the navigation functionality to be extensible without compilation.

Blendability

Blendability means Editable in MS Expression Blend. This is a requirement I’ve learned from Laurent Bugnion. It was a major design theme in his MVVM-Light toolkit, and he is right. Blend is a fine design environment for Silverlight applications. It definitely allows you to scale up your design results. That is: while working in Blend, you generate an enormous and amorphous amount of XAML, so much one might wonder if it is feasible to do this all by hand, or in Visual Studio. Examination of the XAML code will show you in such cases that it is not obviously or overly bloated – some even call it efficient code.

So, being able to use Blend allows you to create at least one level higher up designs than if precluded its use by the design of your software system.

Implements MVVM

One way to preclude the use of Blend is to implement MVVM (Model View ViewModel) in a clumsy way. Connecting a ViewModel to a View as a resource that acts as the DataContext is a right way.

To be honest, I’ve had my doubts about this requirement. Implementing MVVM adds much extra complexity, just to be able to test the code automatically. Nevertheless, it’s good to have this technique in your developer’s toolbox. So, that’s why we have MVVM in this not very complex application.

Realization

MEF

Or, the Managed Extensibility Framework. This is really cool stuff. MEF is a very versatile compositionality framework. It works by attributing types as exports, that are subsequently discovered by MEF. Instantiations of exported types are inserted at variable declarations that are attributed as imports. For a real good introduction into MEF for Silverlight see the Hello MEF blog post series by Glenn Block.

Notably, a component that imports a class doesn’t need to know anything about the imported class. The import is guaranteed to implement a contract (interface) as specified by the importing class, or MEF will not insert it as an import. Components that are attributed as Exports can depend on Imports themselves. Developing software using MEF is a bit like Primordial Soup programming. You specify the interfaces or dependencies between the components and objects without wondering for a single moment how the required objects get at the desired locations.

Given the way MEF works, it can be applied in IoC / DI (Inversion of Control / Dependency Injection) scenario’s, for pure compositionality of course, for navigation in Silverlight, and for the implementation of MVVM. This last application of MEF relieves one of the task of manually maintaining the relation between a View and a ViewModel, while maintaining Blendability.

MVVM

As indicated above, MVVM is a very important software development pattern. Its main advantage is that it allows for automated unit testing, hence test driven development. A developer should have mastered this technique. Implementing MVVM is usually supported by a toolkit. The MVVM-Light toolkit by Laurent Bugnion is at the time of writing the dominant MVVM toolkit.

The MVVM-Light Toolkit is popular and respectable, but after having done some trials with it, I didn’t like it after all. The “why” lies mainly with the global ViewModel locator, an implementation of the Service Locator pattern. It is global, and as noticed by others, introduces a separate source of maintenance effort. John Papa and Glenn Block have provided an alternative based on MEF that I do have used. The MVVM-Light toolkit does, however, provide a facility to handle events generated by the View, in the ViewModel. This facility is the RelayCommand, an addition to the MVVM-Light Toolkit based on work by Josh Smith.

Ok, only ButtonBase children have commands. For events form other controls you can use the EventTrigger from the Interactivity library for e.g. the Loaded event of the UserControl like so.

<i:Interaction.Triggers>
    <i:EventTrigger EventName="Loaded">
        <i:InvokeCommandAction Command="{Binding NavigateTo}" commandParameter="NextPage"/>
   </i:EventTrigger>
</i:Interaction.Triggers>

The NavigateTo command referenced in the code above is implemented as a RelayCommand in the ViewModel. The road from the ViewModel to the View is always by DataBinding

Blendability

Attaching a ViewModel to a View as a resource preserves Blendability: the possibility to edit the View in Expression Blend, and finding in Blend that the ViewModel is attached as the DataSource and is accessible as such. When using a MEF ViewModel locator following the article by Papa and Block, Blendability is also preserved. Moreover, one of the goodies of using MEF is that the style defined for the App shop automatically permeates through to the Catalogue and its items, to the Master window, and to all the Apps loaded into the Master. Of course locally specified styles are preserved.

Architecture of the App Shop

So, now that we now about the requirements and the technology used, what does the structure of the App Shop looks like?

The portal consists of a main window that holds the logo, which acts as the Home button, and some small buttons, collectively referred to as the “small prints” at the bottom that concern legal aspects, contact information, and maintenance of visitor profiles (to be implemented 🙂 ).

This main window holds at any time one of two components:

– The App Shop Catalogue which presents the available Apps

– The App Master Window that provides a uniform context for all Apps in the shop.

Graphically:

Typically the user selects an App from the catalogue, by clicking on its icon, and the portal navigates to the Master window which loads the selected App. Information concerning the selected App is stored in the application level resource dictionary during transition, which (indeed) is abused as a kind of session variable, much like the Session in ASP.Net.

The Catalogue consists of a number of buttons, each holding an image and a caption identifying the App it represents. The images are loaded from a directory at the web server, the information about the Apps is loaded from an XML file, also at the web server.

To deploy an App, it suffices to add a catalog record to the XML file, to add an image to the image directory and to add the App to the App directory. No recompilation of the portal required. The App needs to have one or more MEF “Export” Attributes added, so has to be rebuilt.

When an App is selected from the catalogue, the Catalogue is unloaded, the Main window loads the Master, and the Master loads the App. The App is retrieved from the web server, at that point and not before. Apps that have been retrieved once are cached by the web browser, as are shared libraries. When preparing an App for use in the portal care is taken not to copy in libraries into the xap file that are already present at the client.

Quirks

The Binding System

The Blog Post by Papa and Block mentions a bug in the binding system – and provides a work around. The bug has not been resolved yet, at the time of writing this article. The articulation of the bug is incorrect, by the way. The text states that DataBinding will occur at most 6 times. In reality, DataBinding will occur exactly 6 times, for each binding (where 1 time would suffice).

Deployment

Although Apps can be added to the App Shop without rebuilding and redeploying the entire postal, I find myself doing just that nevertheless. The reason is that I like to keep the portal and Apps source code together in a single solution.

And Now…

Well, now it is easy to maintain and extend the portal, it is time to add Apps, of course, to Load the portal into Expression Blend and give it a much more sophisticated design and User Experience, and to add some more technical features. To be continued!