Mike Kenyon

The Oscars with Style – Part 1

hoarked — Sat, 14 Feb 2009 22:28:53 GMT

The raw, basic functionality of my Oscars application is now up and running. Next job is to get the application up and looking pretty. This is without a doubt, at the moment, the ugliest application I’ve ever built and was intentionally. The goal was to do all the functional work first, and then tackle the “look pretty” work. Well, that time has come.

Defining the “Look”

So I’ve got to decide on a look to go with for the application. I want everything to feel like it should fit together, so I spent a little while thinking through what I want it to look like. When I think of the Oscar’s, I think of the Mann Chinese Theater, the red carpet and things in Black & Gold. So I think that’ll be my theme. What I’d REALLY like is to have a 3D scene in the background but I’m just not that good with 3D. I can do some nice shading with black and gold and get a fairly attractive app. Here’s the main screen before styling.

Here’s the same screen with a little styling applied …

MUCH better…. still some issues. I’m being lazy at the moment with icons for the top-right and since I had to, I figured out the resource loading issue, so I should go back and remove them as actual buttons and use the ModeSelector type I made back at the start. Right now, I’m excited to make progress aesthetically, so I’ll save it for cleanup before I get to to adding features.

Browse Pages

The browse pages were fairly easy to style as well. The main categories page was just four buttons. We needed to come up with something a little flashier.

When I got to the This required that I start tracking an image on the category, which is fine, because I started thinking about it and it should probably show the winner’s picture after they win.

For the type listing page (listing all categories, movies, what-have-you, I wanted VERY much to get a nice grid-array. This tripped me into two major problems.

First, it was slow, butt slow. At least, it was slow when I was showing People. If I showed Songs it was great, of course, there are only three songs and pushing 600 people. I was forcing a new image source for each image,which was costly. So, I gave up a little abstraction and converted the business types to return image sources. I thought about coding VIewModel wrappers for them all to do just that, but it seemed excessive for the degree of violation of abstraction that it was. Pragmatism sometimes needs to rule.

Second, I was using a wrap-panel to represent things (like I did on the main categories page and that wasn’t great. I decided I needed to virtualize. There’s great though about making a VirtualWrapPanel on the Internet, but the only guy I can find to do isn’t giving up the source. I didn’t have time to get the panel and scrolling issues taken care of. I really just wanted to steal something, so with a little creative Google-foo, I found the VirtualizingTilePanel, which is close enough for government work. The hardest part was getting the scroll-bar styled nicely. There’s just a lot of moving parts there. None of them are hard, you just to put some thought to what you’re looking for.

Content Pages

For the content pages themselves, all I needed to do was to add a DataTemplate for each of the 4 stylized approaches. This works out great. Check out the different stylings just by setting the default style for the data template for the module. The “before” pictures were just the name of whatever it was twice, so I’m going to skip over that if no one minds …

Making a Splash

So, somewhere in this whole deal, I downloaded the WPF Futures Splash Screen add-on and turned it on. In about 0.222 seconds I had a VERY nice splash screen for application startup. I was impressed. It’d be nice if Prism integrated a little better here. The splash screen comes down when the main window comes up, which is well before module loading has completed, so there’s a couple of minutes of dead-time before the modules kick in and the app is actually usable. All you need to do is add an image and then set it’s BuildAction to SplashScreen. It couldn’t be any easier.

Backing Up

I found it really necessary to add a back button, which gets us back to our whole issue of the navigation. My first cut at this was to just add a button that knew what the previous page would have been and re-activate that. The downside was that that’s REALLY taxing to do, breaks a lot of encapsulation and the whole idea goes out the window when I start having the browse pages link to one another. So, I needed to create a navigation service. Once that was in place, I just made everything a button or hyperlink bouncing it to the appropriate navigation service.

I did this in two parts. First, I wanted an easy way for the different pages to link to a spot, so I created an IOscarsNavigationService that provided methods to allow you to link to interesting areas without having to know anything about them. I put the definition in the foundational module OscarsNight, but the implementation I put in the Browse module as this is logically where the smarts to the do the work are located. Once I had the service in place, I followed the How to: Create Globally Available Commands guidance from the Prism docs to create a global ItemNavigate command, which the Browse module intercepts to navigate any INamedEntity that might happen to be navigated to. I had already created a single, named DataTemplate that I used to describe the little icons I was dropping all over the place with cross references in them. By associating the command with the template everything suddenly became navigatable! I then dropped like 40 lines of code (mixed XAML and C# code) that had been doing navigation and I got a clean implementation back that gets rid of list boxes, and just shows everything as being a link.

The second part was trying to clean-up the Back button that was now everywhere. I actually wanted it to go back, but that requires understanding what “back” means. I needed a stack. I needed to track what the active view was at any given time. I thought about doing it with a behavior, but I don’t need to and behaviors really are great when you want the behavior to apply to all regions of a specific type. In this case, we want to handle exactly one region as the navigation locale, so I think we’ll pass on it. A little playing around got it working pretty quick, which allowed me to clean out a bunch of code dedicated to supporting the hack I had had in place. The code is now starting to look clean.

Future Proofing

I’m a big fan of planning for the future … if it’s easy enough and in this case it is. I know that I’m going to want to add more information to what I have stored on the different objects in Browse, but I don’t know what and as they’re going to be later add-ons, I don’t want to have to know. So what I did was I added an ItemsControl to each of the data templates that style the navigatable types and marked that items control as being a region. This enables me to register views with the region and through view discovery, they’ll auto populate whenever the page pops up. As the types will invariably need to see the thing being presented, I made that the RegionContext of that region.

Next up the voting module …

Here is the code.

Creating a WPF Application With Prism v2 – The Final Frontier

hoarked — Sat, 14 Feb 2009 15:56:13 GMT

Okay, recap. We got the shell of the application up and running. We’ve made two foundational modules to provide functionality to the business modules. We’ve created a couple of business modules to allow people to browse the nominees and to allow them to vote. We’ve refactored more times than I care to count. We have also created possibly the ugliest application I’ve ever been associated with.

Left on the plate? We’ve got the last major business module to write (that being the module that scores the Oscars when they’re on). Next we’ve got a lot of styling to do. Let me repeat that. We’ve got a lot of styling to do. Following that, we’re on to bells and whistles (like song clips, player photos and critical reviews).

Score Module Design

So, I’m down to the last module to create. In some ways, it’s the most complex, in others, its the easiest. I’m thinking in my mind that there are three major capabilities. First, they’ve got to be able to pick a category. God only knows what order they’re going to do the categories in, so I need to be able to pick in a random access fashion. There are some general rules (best supporting actor tends to come first, best picture is always last, etc.). Second, they need to be able to pick a winner. The designer mind clicks in here and I’ve got a mental image of it being the 4 or 5 part split, but no matter how you cut it, at the moment its a list box. Third, we want a leader-board, so that people can brag amid-game.

Part of me says to keep things simple and make it as three separate views, part of me says life will be easier with one. I’m going to take the latter approach till I find a reason to split it out. Refactoring is life after all.

I don’t want the category selector to take up that much room, so I think I’ll plan initially on it being something like the selector control out of Kevin’s Bag of Tricks (which you should look up if you’re not familiar, a great tool to understand and learn WPF). Barring that, I may decide that the carousel on a path is a better option, we’ll just have to see what the designer wants. Either way, a ListBox is the correct choice for the actual control to use, everything else can be taken with styling.

For the leader-board, I don’t want a section model, the data should auto sort with the leaders on top. I’m going to put it as an ItemsControl (it has multiple values and no selection model).

WPF Philosophy Aside

One of the things that I love best about WPF is the philosophy of developers designing by function and designers designing by appearance. I’ve been an advocate of <strong/> and <em /> over <bold /> and <italic /> since the early, early days of the web. I’ll admit my limitations and while I can make just about anything look the way the designer intended, coming up with that intent often alludes me. As a developer, how it functions is more important to me than how it looks and WPF supports, embraces, nay insists on this separation. If you don’t take it, it takes it for you through the use of styling. The fact that I’m (as a developer) responsible for how something logicallly is laid out frees me from bit-twiddling to figure out why I’m 1-pixel off somewhere and let’s me concentrate on the important things. It also means that I (as a designer) am responsible for the aesthetics and experiential behavior of the application and don’t have to worry about what and who gets called for what.

I find myself using precious-few actual controls in actual user controls. Typically, it’s ContentControl, HeaderedContentControl, ItemsControl, ListBox, Button, CheckBox and layout panels. Just about everything else I can do styling. Theoretically, I don’t even need panels, because I can use an ItemsControl and set the ItemsPanel for the control in the style … actually, that’s a pretty good idea. I may refactor to do just that.

Flipping State

One of the things that I’ve noticed is that I tend to end up recreating views over and over. This generally isn’t horrid. There’s some gap in my activate vs. create logic that I’ve got to take care of. In most cases, I’m displaying data out of a service and therefore don’t care, because the service itself is a singleton. In this case, I don’t have a service (as a moral thing, I don’t create a service if one view is the only possible consumer) so I need to store some state that will will live between creations of the control (just in case). I could store it in the database, but it’d be a couple fields and persisting the winners doesn’t really interest me. It means I have to clean things out when I’m testing and I hate that. So, I’ve got two real pieces of state. First, who won each category. Second, the leader-board. The winner seems a perfect case for an attached property again. This way, I can store data on someone else’s type without having it be (necessarily) readily apparent, public knowledge. For the leader-board, I’m going to store it in the Application object which has a hashtable for exactly this sort of situation.

For the leader board itself, I’m going to just make a derived ObservableCollection<Player>. This gets me everything but sorting and I can throw an event handler to sort the list every time the player’s score changes. So, how do I represent the scores? I think that’s another great case for an attached property on the Player itself.

Without much problem at all, I got the system up. Now onto styling.

See it here.

Creating a WPF Application With Prism v2 – Encapsulation Junction - What’s Your Function?

hoarked — Sun, 08 Feb 2009 01:16:15 GMT

So, I’ve just hit a snag. It’s not a big snag, but it’s somewhat fundamental. I was happily going about my business. I’d gotten the Browse module up and running that was going great. I was about to start in on the Add or Voting module. In order to do this one, I’m going to actually need an implementation of the IGameService to exist. I hadn’t forgotten it, but I didn’t want to get mired in it until I had Browse up and running, since Browse didn’t really need it.

When I went to implement IGameService, I came to two conclusions very quickly.

The first was that a lot of the infrastructure for HollywoodService really is the same as the Game Service. For the Entity Framework implementation of those two services, they’ve very tightly linked. This lead me to rename the HollywoodService to be the CombinationService (I could have named it the EntityFrameworkImplementation) and had that single class implement both interfaces. This allows me to do the actual initialization work once and share a context between the two different implementations easily.

The second (and less happy) conclusion was that I had an identity crisis. As I was looking how to implement methods like Guess() where the database requires IDs, I was doing a lookup for each parameter to look up the entity by name to get its ID to insert into the database. I considered for a moment adding an ID field to the business classes, but that really puts a burr in my saddle (I live in Denver, we’re required to use a Western idiom once a week). The addition of an ID is really an implementation concern and shouldn’t be exposed out through the interface, however, it’s darn convenient to have it there. After 5 minutes of biting my lip, I fell back on an idea that a co-worker had come up with about a year ago. We have a conceptual data model at work and objects to represent the conceptual data types (classes representing columns, tables, etc.). There were pieces of information he wanted to store that he needed to know, but didn’t want expose out as part of the interface. For a couple of weeks we explored re-inheriting the types off of DependencyObject so that he could use attached properties to store the data. Not part of the interface, stored wtih the object, GREAT! We had backed out of that path because of some of the threading issues around DOs on in an MTA, but in a rich-client application, this should work well.

So I’ve rebuild the business objects to be full-fledged DOs, this will also help with data updates in binding situations, so it’s a double-benefit.

As a side-note, I find that every once in a while, I trip over something that’s just … wrong. Today, it’s that I can’t seem to find the WPF snippets in my installation of 2008. The workflow definition is the there, but that means that I’ve got to use the snippet and then change it every time and that’s just WAY too much effort. So, I salute Dr. WPF and his repository of snippets for making my life a pleasure again.

At this point, I tripped on a small design flaw. It seems that LINQ to Entities has problems understanding attached properties. I tripped into this based off of how I was reconnecting objects in the business tier after having gotten them out of the database in the services. In several cases I had two real entities that had a join table between them (occasionally with some data hanging off of it). My loading order was to load and objectify the entire entity system (it’s really small) and then tie the business objects representing those entities together. So, my approach was to iterate one of the entities to be tied, look it up in the join table and then get the equivalent entries from the other entity. This required direct pulling of the attached property of the first entity and several cases and just became unworkable. What does work, is to iterate the join table and then do lookups from the business objects based off of the attached IDs.

With a fair amount of giggling, mostly around getting the “double down” feature to work, I now have voting working. Two down, one to go before styling starts.

Here's the code

Creating a WPF Application With Prism v2 – Browse Module, Why Resources Suck & Navigation Horrors

hoarked — Wed, 04 Feb 2009 19:14:31 GMT

So, next step is to get some business modules in place. I’m going to start with the browse module and I’m doing it for two reasons. First of all, because it’s the easiest. Second of all, because it doesn’t really have any connections out to other modules. The reverse is true, but not that way.

Overall Design

I’m thinking that I should be able to pull this module off with a total of three views. First, one view to list the different types of things that you can browse (categories, movies, people, & songs). Second, a view to show the list of whatever they picked on the first list. Third, I’m going to need a detail view page. Theoretically, and I do stress theoretically, I should be able to track all the differences between them via styling and suffice with just that.

Mode Button

My first goal is to get the browse selector on. In the back of my head, I’ve got a mental image of the a series of slick buttons in half-transparency that pop when you do a hover-over and clicking each sends you to the root. Since you can only be in one mode at once, a radio button makes sense. However, all of that is me in the designer roll and I shouldn’t be there now. So, what I’d like to do is pop out the ViewModel and let styling take care of it. I found a gnarly little bug which I reported up to the P&P crew that forces anything displayed as a View to inherit from DependencyObject. Not the best thing, but it doesn’t really hurt me to do so at this point, so until they get that fixed, I’m good with making my ViewModel inherit from DO.

All I should have to do now is put a data template on the ViewModel type to make it appear as a radio button and bind it’s click to the Activated command on the ViewModel.

Why Resources Suck

There I said it. The cat’s out of the bag and it’s not going back in. Resources suck. [Editor’s note: The author is equally likely to say that resources are the best thing ever invented by man … depending on who’s side of the war they’re on at the moment.] They’re buggy, drop errors and leave you doing your best James Dean impersonation for hours as you try to figure out why X is in the wrong spot, is the wrong color or is just plain wrong. They’re also incredibly powerful and this occasional urge to through your computer … and the WPF team … out the window is part of that pain. And in a modular application, this just got worse.

In a non-modular application, my root would have full-connectivity to all the modules and I’d just through the style into any of the resource files included by the main window of the application and I’m 5x5. Sadly, putting this in a fully modular context slowly eats away my options.

First, one of the reasons to make your application modular is to be able to treat parts of the application as plug-ins, which you really can’t do if there are compile-time references between them. So, putting the style into the main application won’t work because it doesn’t know (and shouldn’t know) what my ViewModel is and should not care.

Second, there’s the question of where to register the styles into. Every control has a ResourceDictionary, but I’m not registering a view, but rather that display model behind that view. So, my options are really registering it into the Application itself or into the MainWindow. I’ve found that resources up in the Application don’t get included when you’re using the default bootstrapper configuration, which is unfortunate. This has driven me to put all the “top-level” resources I want access to into the MainWindow. This could have problems if I’m in a multi-window situation, but in general should be okay, at least for this application.

So, I decided to create a service that would put resources in the MainWindow’s merged resource collection. This lead me through a series of three hoops.

First, I figured I would do things the OO way and make my ResourceDictionary (in a file called BrowseResources.xaml) a derived ResourceDictionary type and load that. Sadly, this does not work. You can certainly add a x:Class tag on the type and make it a derived class. You can create one. It has no resources. Unlike everything else in WPF, ResourceDictionary’s don’t parse their contents on creation. They load themselves from their Source attribute later, so though you end up with a derived type, you don’t get the nice OO way to represent resources.

Second, that left me with needing to define the location of the resource file. URI’s are relative to the application, by default, so just supplying the file name doesn’t work. You have to whip out the pack URI. For those that are not familiar, here’s what one looks like, in the context of loading this file.

service.RegisterResources(
    new Uri("pack://application:,,,/Browse;component/BrowseResources.xaml", 
        UriKind.RelativeOrAbsolute));

I consider myself reasonably smart, but I can’t figure these damn things out. It’s a strictly voodoo part of my job. I just copy an old one that worked and make the necessary modifications. I’ve read through the documentation about a dozen times and I just can’t make it stick. I’ll get it for a while, and then something more meaningful (like belly-button lint) takes its place.

Third, I got the resources to load and they still didn’t take. It’s there, just not getting used. So, for the time being I’ve commented out, used a hack in its stead and thrown out lifelines to others trying to figure out why.

As a final thought, I’ve gotten into two habits that make my life much easier on the binding side. First, I always derive my ViewModel from DependencyObject, this gives me some flexibility on the order in which things get set. The second practice is to always either set the model before the call to InitializeComponent() in the constructor or to make it a dependency property itself.

Navigating the Situation

So, I love agile because it gets me going and my assumptions are generally good enough to get me most of the way without too much re-work. Occasionally, I make a bad call and have to rework almost immediately. This would be one of those days.

I realized as I tried to get the content list view in place that what I had in my mind was kind of browser-like. You pick say “People”, go back, pick “Movies” instead. Then you drill in on “Tropic Thunder” and then “Robert Downey, Jr.” to see that he’s also in Iron Man which was also nominated (for sound effects I think). That’s a navigation app. Crap. Okay, so the ContentRegion as I have it defined has to go. There’s no direct support in Prism for Navigation, so I guess I’ll have to add it. This means two things.

It means adding a region adapter for the Frame class. Frame is a ContentControl, so I guess the system would work, but the semantics would be all jacked up. It wouldn’t provide the history semantics that we’d want. I think it’ll also mean adding a service because some things that you’d want to do are hard to do from the region interface (like clear out all history).

After a lot of soul-searching (and searching those wiser than I), I’ve given up. Navigation isn’t going to do what I want. The default content control behavior is close .. very close. I’m a little disappointed by this, but in the process I’ve found a bit of a jewel. You should surely check out the Helix project by David Hill. This is a better version of Navigation that would probably due 90% of what I need rather than the 70% in WPF proper, but it’d take me to long to integrate it in the first cut.

Entity Framework Woes

I have a love-hate relationship with the entity framework. For some things it absolutely rocks, for others, it’s not that great. A problem that I encountered trying to get my foundational module to work is an illustration of that in the small. It took about 10 minutes to write the HollywoodService class, it was REALLY easy. On the flip side, it took about an hour to figure out why the damn thing wouldn’t load on me. Seems that when you don’t have direct references from the main executable to the DLL in which the entity model is located ,the connection string which is automatically generated is incorrect. The system generates a connection string that looks like this:

"metadata=res://*/OscarsEntities.csdl|res://*/OscarsEntities.ssdl|res://*/OscarsEntities.msl;provider=System.Data.SqlClient;provider connection string="Server=(local);Database=Oscars;Integrated Security=True;MultipleActiveResultSets=True""

What will work is something like this. The “*” is replaced with the name of the DLL that contains the file.

"metadata=res://OscarsNight/OscarsEntities.csdl|res://OscarsNight/OscarsEntities.ssdl|res://OscarsNight/OscarsEntities.msl;provider=System.Data.SqlClient;provider connection string="Server=(local);Database=Oscars;Integrated Security=True;MultipleActiveResultSets=True""

After a little effort, however, we have a system with an operational Browse module. Next up, the Guessing module.

To see the current code check here

Creating a WPF Application With Prism v2 – Foundational Module

hoarked — Wed, 04 Feb 2009 19:14:16 GMT

Okay, so the next stage, I’m going to need some data in order to do stuff. I’m going to create three DLLs, all class libraries. They are:

OscarsNight.Interfaces – The interfaces for the services and the business objects.
OscarsNight – The actual implementation DLL, with some data access stuff. I think I’ll use Entity Framework for that.
OscarsNight.Tests – A testing DLL that tests the implementation.

Business Objects

For the business objects, I’m going to create two sub-namespaces, one each for Game and Hollywood types.

Data Types

For the most of the data types, I’m trying to stick to primitives. This is hard when it comes to the images. The image fields need a data type, but what to use? ImageSource would work great in general, but that presumes WPF or Silverlight. I might want to use it elsewhere. I could use an System.Drawing.Image, but that’s hard to use in WPF sometimes. So I think I’m going to aim for something more … agnostic. My leading choice at the moment is a Stream. Easy to load into any of display systems and non-preferential between them.

Game Types

I added a player type that’s similar to that defined in the data. For guesses, I’m a little dubious. You can guess either a movie or a person, depending on what category it is. I could create a couple different methods to take the different type of things you can guess, but then I’m toggling in code. I could have them pick a Nominee, but I’d really like to not expose that table if at all possible. The best initial thought I have is to create an interface for things you can guess and so, we now have an IGuessable.

Hollywood Types

There’s not much of a way I can get away without creating Category, Movie and Person types. Actor and Nominee tables I don’t really want to expose. I can just use the Person type for Actor table. For the Nominee table, I can use either Movie or Person, since I now have the IGuessable interface.

So it’s at this time that I realized that I was missing a type. One silly category, Music (Song), is different. It has songs instead people attached to it. I thought about being a cheese-monkey and just using the picture, but two of the three songs are in one movie, so I have to have a new type. I considered for a brief second putting them in the Person table with a flag, but decided against it.

Services

So for the services, I’m going to generate two, one to return game information and the other to retrieve movie data.

IGameService

The game service should let them add and remove players, and to have them guess or clear a guess.

public interface IGameService {
    IEnumerable<Game.Player> Players { get; }
    void AddPlayer(Game.Player player);
    void RemovePlayer(Game.Player player);
    void UpdatePlayer(Game.Player player);
    void ClearPlayers();
    void Guess(Game.Player player, 
        Hollywood.Category category, Game.IGuessable guess);
    void Guess(Game.Player player,
        Hollywood.Category category, Game.IGuessable guess, double multiplier);
    void ClearGuess(Game.Player player, Hollywood.Category category);
    void ClearGuesses(Game.Player player);
}

IHollywoodService

The Hollywood service is very basic, it just exposes data. Since the objects are interconnected, its very easy in its interface.

public interface IHollywoodService {
        IEnumerable<Hollywood.Category> Categories { get; }
        IEnumerable<Hollywood.Movie> Movies { get; }
        IEnumerable<Hollywood.Person> People { get; }
        IEnumerable<Hollywood.Song> Songs { get; } 
}

Creating a WPF Application With Prism v2 – Module Layout

hoarked — Mon, 02 Feb 2009 21:51:50 GMT

Okay, hopefully this is going to be a short one. Next thing that has to get done is to a little division of work. Looking over the requirements, there are only a couple of things that I’d like to, but first a word on module types.

Module Types

There are two types of modules that are defined in the previous incarnations of the framework (SCSF and WCSF). They are foundational and business modules. They don’t exist as fine-grained separations in Prism, but I’ve found using them to be useful concepts, so let’s talk about them for a minute.

Foundational Modules – These modules just augment the services set. They contain no UI. This may seem odd for a client application, but its a powerful concept. In my current position, we’ve been able to show significant reuse between WCSF, SCSF and Prism by having foundational modules with a large chunk of business logic embedded in them that we can use in all three versions of the framework. As there’s no UI, there’s no external dependencies that are hard to deal with lying around. Within Prism, with a little effort, you can generally get foundational modules to share code between Silverlight and WPF.

Business Modules – Contain the views and their presenters along with anything that comes tightly bound to them, they can have but don’t necessarily often have services made available through them. These are hard to reuse between different display paradigms even within Prism (Silverlight and WPF).

So, what modules do we think we need?

Foundational Module

Each of the following are going to be three DLLs in true foundational module style. One for the interface, one for the implementation and one for the testing of the implementation.

OscarsNight – Maintains queries for dealing with loading and managing Game and Hollywood data for the back-end data store.

MoreInfo – Does movie/person based lookups using the IMDb web services and possibly other services to get reviews. I’m not sure if I’m going to populate this into the local DB or do live hits out. We’ll leave it for the moment.

I’m thinking I’m looking at needing a Utility foundational module that has some things that Prism lacks out of the box, more on that later.

Business Module

I’m thinking one business module for each of the three main modes (Browse, Add and Score). The add-on information I’m going to put in additional modules so I can add and remove it on the fly and don’t have to worry about tweaking modules as I go.

So there’s the module list. Base install will be 4-5 modules, after that everything is gravy.

Creating a WPF Application With Prism v2 – Ummm, Ummm Data!

hoarked — Thu, 29 Jan 2009 04:40:09 GMT

So sometime about now, I tripped on the absolute worst part of this whole process. Heck, it’s so bad that in the years where I haven’t had a scoring app, this has been single-handedly why there was no scoring application. That, of course, is loading the data. Consider, 24 categories results in between 20 and 120 movies nominated (50 this year). If you’re recording information on people involved, it rapidly hits the hundreds. If you don’t want to store a lot of data, it’s not that bad, but it’s still hours of typing potentially and it’s all very error prone and well, I’m lazy.

I considered for quite some time this year just linking to IMDb. The problem is that I don’t believe in having a TV in a non-dedicated space. I don’t like TVs in my bedroom, living room or anywhere else where they promote vegging and ignoring real, live people. So I have a TV room … in my basement … where there’s next to no internet connectivity. Besides, what do you link off of? There’s link 45 movies that you get hits off if you go to IMDb with “Wanted” as a title, which one do you want. Heck, for the foreign movies the title that nominee has is not the title that appears in IMDb. So, I passed on that idea.

In perusing that idea, however, put me on the track for what eventually become a PHENOMENAL idea. So, I figured that IMDb, like everything else these days probably had a web services interface to it and if I was lucky some other guy had gone and build me a library to make it easy to use. And so they had. The IMDb Services project on Codeplex was just the ticket. Not only did it come with a client-library, but it also came with a sample app to pull the data. Twenty minutes of coding and I had an app that would let me search IMDb for a movie title, and then record not only the movie, but everyone in it for posterity sake. About an hour of debugging (always the way) and I had a nicely robust app that would let me ingest all of the movie data. Thirty minutes later, all 50 movies, 507 people and their 471 roles were ingested into the system. Heck, it was so easy, I’m half temped to do it again and get more data. Okay, when I found the service, I nearly tripled the amount of data I was storing on Movie and Person, but there’s more data still that might be useful, so I may decide to drop and rebuild the table. The worst part was trying to figure out all those multiple-hit situations …

Creating a WPF Application With Prism v2 – Shell

hoarked — Wed, 28 Jan 2009 16:30:42 GMT

I’m always happier in my Agile mentality with having something up and running that I can hit F5 on and see the fruits of my labor and this is no different. So, the next thing we need to do is get a basic Prism application up. The most basic Prism app in the world has three things in its .exe.

The Application object, which sets up the bootstrapper object.
The Bootstrapper object, which kick-starts the IoC container, loads modules and starts the shell.
The Shell window (which I really wish began with a “C” so I could do an ABCs joke) is the display husk in which all other content in the application will be housed.

Let’s look at each individually and make some choices about them.

Application Object

Ironically, that which is most important in traditional WPF applications may be completely unimportant here. The code for an application object might as well be a template. The following steps will ALWAYS result in you having an appropriate application object in a Prism app.

Open up App.xaml and remove the StartupUri attribute.
Open up App.xaml.cs and replace the constructor with the one below.

public App() {
    Bootstrapper bootstrapper = new Bootstrapper();
    bootstrapper.Run();
}

You’re done. We haven’t defined the Bootstrapper yet, but we will. That was easy.

One minor thing that’s a fall-out here is that the resource dictionary from application is inaccessible. This means that if you want to do global resource swapping you’re doing it on the Shell.

Bootstrapper Object

The bootstrapper component has the job of doing all the start-up stuff associated with the application. It’s home to the composition container, loads and initializes all of the modules and, in short, causes all good things to happen. It also requires choices.

The IBootstrapper interface gives you the typical steps and you can go through and implement on without too much problem. The principal reason to do so is some preference on a composition container. With the advent of the common service locator, most of what I want out of a container is behind a wall and I don’t care. To that end, I don’t see why I should spend time implementing something new to get a choice in something I should (hopefully) never see. Hence, for the sake of discussion here, I’m going to take the default which is the Unity container from the EntLib folks.

So we’re going to make a class called Bootstrapper that derives from the UnityBootstrapper class. Doing so requires that I implement one pure-virtual (abstract) method, CreateShell(). Here’s my implementation. Barring needing to do something funky, this is also template code. The creation of the shell through the container is not expressly necessary, but it’s mighty convenient for getting the system to resolve dependencies for you.

protected override System.Windows.DependencyObject CreateShell() {
    Shell shell = Container.Resolve<Shell>();
    shell.Show();
    return shell;
}

This is, however, also the time to decide how you want to modularize your application. Modular apps are broken into, shockingly, modules. Each module is going to load some services for others to consume, play a part in UI composition and have a chance to integrate itself with the rest of the application. Traditionally, modules are bundled one to the DLL, but they’re no requirement for this. Instead, the system uses an object called the module catalog to load each of the different modules. Prism comes with loaders that work off of configuration files, reflection and just hard-coding it. Heck, if you’re willing to cannibalize from SCSF, you can get one that does a web-service lookup call pretty quickly. My personal favorite has always been one that does a directory scan with reflection. This gives me the feel of Adobe Photoshop – a shell of an application with 90% of it’s functionality loaded from plug-in files. Is it really necessary here, no … but it gets us into the feel of Prism, so I’ll use it.

protected override Microsoft.Practices.Composite.Modularity.IModuleCatalog GetModuleCatalog() {
    return new DirectoryModuleCatalog() { ModulePath = @".\Modules" };
}

This creates a module catalog which will scan the application root for a “Modules” directory and will load and initialize any module in there.

All of this has added a couple of dependencies:

Composite UI – Microsoft.Practices.Composite.Desktop & Microsoft.Practices.Composite.Presentation.Desktop

Composition – Microsoft.Practices.ObjectBuilder2, Microsoft.Practices.Unity, Microsoft.Practices.Composite.UnityExtensions.Desktop

Services – Microsoft.Practices.ServiceLocator

That’s the framework. if you were using a different composition container, you could swap that stack for the one provided.

Shell Window

This is the root window of the application. By requirement, there aren’t any. It could be just a traditional window and be done with. I’m going to make a couple of configuration changes here. I’m looking for the kiosk look-and-feel, so I’m going to set WindowState to Maximized and WindowStyle to None. This gives me a screen that coats whatever monitor it goes up on without any window chrome. Perfect. I’ll still give it a title even though it won’t appear in the non-existent chrome because if you swap off of the window, it’ll still be listed in the task bar and window list that way.

A word on resources. I’m a big fan of keeping most stuff in resources whenever possible. It gives me flexibility and styling avoids display lock-in later. Opposing that, it gets hard to find things, so I’m a fan of storing everything in one place, so I break up the resource list into a series of resource dictionaries, by type or resource and stow them each off separately. I organize it by typed (default) resources up top and named resources below, in alphabetic order. Here’s my definition of the resource dictionary at this point. Over time I’ll have to templatize more things, but right now, panels (which I include windows into) are about it.

<Window.Resources>
     <ResourceDictionary>
         <ResourceDictionary.MergedDictionaries>
             <ResourceDictionary Source="Panels.xaml" />
         </ResourceDictionary.MergedDictionaries>
     </ResourceDictionary>
</Window.Resources>

By default windows start out holding a grid and I’m not going to change that. One of the real failings of the WPF grid is that you can’t store the row/column definitions in a style themselves. There is no ControlTemplate for a Grid nor can you create an object of RowDefintionCollection or ColumnDefinitionCollection. I’m going to create the grid as a 2x2, with the top row autosizing and a 50%/50% split vertically. In the upper-right corner, I’m going to drop an ItemsControl. I’m going to need a way for people to swap between the modes and this is the easiest one I can think of. I like using ItemsControl because I don’t know how I want to have it look right now and this way I can defer selection to a later date and time through styling. I’m going to give it a style tag of “ButtonPanel” and move on. In the entire lower row, I’m going to add a ContentControl. This will hold the current display view for whatever the user is doing. I’m going to give it a style tag of ContentZone and turn my mind to more interesting matters.

Regions

We’ve got places to put content, but we don’t currently have any way to get content into it. Prism supports two different mechanisms for doing this. Both involve the use of a region, which is defined most simply as a place that you can put content.

View Discovery – Involves the region “finding” the views that should fit into it. It’s the easiest to use and the default mode. Since the list of modules is going to be static and not based on user-action, we’ll use discovery for populating it.

View Injection – Involves an external entity “shoving” content into a region. This is best used when the view is contextual in nature. Since the bottom is going to have views that represent specific movies and categories, it makes sense that we inject into it.

In both cases, all we have to do at this stage is specify a region name with an attached property (which I’m doing through styling). Next stop, getting some basic content.

If you're interested here's the Project So Far

Creating a WPF Application With Prism v2 – Data Design

hoarked — Tue, 27 Jan 2009 04:16:58 GMT

So I’m a firm believer that once you have business requirements its a good idea to have the data right. You may have to expand on it later, but it’s good to know what you’re dealing with in a problem space. In a larger, green-fields application, I might well do a part at a time to keep in good Agile methodology, but this is neither large nor green fields (I’ve build the application several time so far for different years in different tech stacks, though this hopes to be the prettiest). So, here we go …

Hollywood Types

Types in this schema are those needed to model the actual Oscars.

Category: The 24 different categories that represent the Oscars night balloting.

Movie: The different movies up for awards.

Person: The people up for nominations or involved in movies up for nominations, with photos (from IMDB).

Actor: The list of all people involved in the movie. This would support giving an actor list for all nominated films, but will probably be the last table I bother to populate.

Nominee: The relationship between categories, movies and people. The 3-way join it necessary to support cases where two people are up for the same movie.

Game Types

Types in this schema are those needed to play the Oscars as a game.

Player: A record of the players of the game.

Guess: That player’s choices.

Creating a WPF Application With Prism v2 – Background & Requirements

hoarked — Tue, 27 Jan 2009 02:52:51 GMT

I’m not a Microsoft employee, but I’ve been on the advisory board for P&P’s Composite Architecture for WPF and Silverlight (hereafter just called Prism) project since v1. It’s a great little piece of software and I’ve been negligent about blogging on it, so I thought I’d take the opportunity of starting up this blog to do so.

History

For those that are unfamiliar, since 2003, P&P has been generating a series of application blocks, software factories and guidance packages that have promoted a concept called composite architectures. The goals here are several:

Separation of concerns. There’s a struggle in trying to test UI applications in that the business code becomes entangled with the display and it becomes harder and harder to test. Anything that can break the display from the behavior enables better testing.
Modularity. Large applications tend to get generated by large teams and there’s not generally good communication channels between them. When different teams need to share an executable space, there need to be some protocols in place for how they get initialized, talked to and share information.
Composable UI. This extends the modularity concept not only to the application as a whole, but to parts of the display. How do I have menus interact, toolbars unify, etc. when the different parts were made at different times by different teams.
Loose coupling. Its frequently the case that as applications grow, you want to share data from one end to the other. As this occurs, you find more and more of your application tied to opposite ends and you end up with the veritable spaghetti bowl, rather than a nice, neat application anymore. Supporting ways to loosely tie things is like adding a little salt & oil to the pasta water. No more clumping.
Injection-friendly. Inversion of control has become a reasonably common pattern for supporting configurability and supportability along with greatly improved testability. These frameworks embrace the idea.

The combination of these traits results in code that is cleaner, easier to extend and easier to support.

The downside is that traditionally this also came with a lot of weight.

In 2003, P&P supported the release of the Composite Application Block (CAB). This was a cut at supporting this functionality for WinForms applications and had great success, but it was monolithic. It was very hard to use the system without being trained in its depths and making changes for the uninitiated was hard. A severe shortage of secret handshakes and staves meant that it didn’t get the play it probably should have.

In 2004-5, CAB bulked out from large to ghastly with the addition of a number of supporting blocks, GAT/GAX tooling and LOTS of documentation and became the Smart Client Software Factory (SCSF).

In 2005, SCSF was ported to the web and became WCSF. It was smaller and leaner. The documentation and GAT/GAX tooling was there and it was slightly easier to comprehend then SCSF. It also lost some of its purity to the pains of the web. On the downside, because of a number of issues, there were large chunks of code that were re-used between the two blocks either as pure copy-and-paste reuse or with minor tweaks to work on the web. This made it hard, but not impossible to write components that worked in both SCSF and WCSF.

In 2006, the CAB community extended SCSF out into the WPF space with plugins that supported both WinForms with embedded WPF content and the reverse. The problem was that a LOT of the concepts and ways of doing things in SCSF were tied to WinForms concepts that either no longer made sense or could more cleanly be done with mechanisms in WPF.

In 2006-7, Microsoft launched the Acropolis project. This project was a from-scratch application framework in WPF. It had a LOT of great tooling around it, but it suffered a number of problems and for reasons I’ve never had completely clearly articulated the project was disbanded. It wasn’t perfect, but it was better than the SCF-WPF bridges.

In 2007, Microsoft launched Prism. Prism is the new-generation to grow from both the ideas and the lessons learned from SCSF and WCSF. It’s cleaner, smaller, lighter-weight and “injectable”. What I mean about the last one is that its relatively easy to incorporate the framework in an existing application. In the previous incarnations, it was much harder to do an incremental inclusion of the framework. Possibly in all of them, yes. Harder, surely. Prism also attempts to alleviate the differences between windows and web by supporting the same framework on Silverlight and WPF. You have to jump through some hoops in order to get there, but that’s caused by differences in the display frameworks themselves, not caused by the application framework that sits on top of them.

Where is this all going in the future? Well, that’s a good question. Microsoft has started up the managed extension framework and the common service location projects which are part of .NET 4.0 and will have a major impact on the portions of the framework that are “Core .NET” and not.

Project

So I don’t know about you, but my mind always works better when it’s got something physical to wrap around and I find that I can actually motivate myself better to do things when I have something to get accomplished. To that end, I need to make a confession. I have a horrible, dirty addition. I … I … I love the Oscars. Yes, its pedantic, yes, it’s a bunch of people I don’t care about 364 days out of the year spending MILLIONS slapping each other about the back, but there’s something about the Oscars I really like. Okay, I’ll admit it. It’s a good excuse to haul the kilt out. Apart from that, it’s an excuse to get a bunch of people together, have some adult beverages and observe all that there is wrong with the world in so many, many ways.

In accordance with this addition of mine, I’ve taken to having a party annually. A black-tie affair, held in my basement. I have a red carpet, there’s wine and appetizers, the whole deal. Part of the festivities has annually been the proclaiming of guesses and the scoring of the same. There are 24 awards categories for the televised show and we assign a point-value to each. Everyone then makes their guess for all 24 and then we tally points as we go through. In the past, I’ve taken stabs at making an app to do the whole deal because otherwise we end up with a slightly tipsy Welshman in the back of the room ignoring the show and doing maths. Funny, but not really the best plan.

The practical goal therefore is to come up with an application that will do this task for me. This is going to be a running journal of the experience, good, bad and indifferent.

My actual goals extend beyond that. I want to provide a sample of Prism development. I also want to explore Designer/Developer separation. To do this last bit I’m going to withhold styling the app as best as I can stand it until its up and running and then go and style it. Of course, in this case I’m playing both roles, but I’m going to try to segregate as much as possible.

For clarity sake throughout the series I’m using Prism v2 drop 9, which is the latest as of the date of this post.

Requirements

Designing a composite application does not mean not designing an application. Just because the application can be composed and there’s a fair amount of injection going on, how and where that’s allowed is still up for grabs. It’s also really hard in my opinion to design without having requirements, though less so with composite applications than others. So, let’s run through a couple of business requirements and from those let’s abstract out a series of design decisions. So, without further ado …

The application (or at least the first cut) is going to have 3 major functions. These are:
1. Allow people to see a little about the current nominees, reviews, etc. (Browse mode)
2. Allow people to select their choices for who is going to win. (Enter mode)
3. Score the live Oscars to provide blow-by-blow results and facilitate people bragging, talking trash and doing the Snoopy dance. (Score mode)
It should be possible to switch between these three modes at any given time.
Current state for a mode should be remembered when switching between modes.
1. It’s not necessary (but nice) to remember state between runs.
In Browse mode, the user should be able to browse between the following items.
1. Categories
2. Movies
3. People
For each display, at a minimum it should list the other types of data to which its connected (e.g., when looking at movies, you should see the actors in them and the categories they’re up for).
In Enter mode, you should be able to pick in any order, go to and return from the Browse views for the nominees.
You should be able to make exactly one pick a “double-down” for double the normal points.
In Score mode, you should be able to pick the categories in any order.
1. You should be able to reprise an answer (if you screwed up).
2. There should be a display with the current leaderboard sorted descending with point values.
Time permitting, it would be nice to support additional views on the data:
1. Allow the viewing of reviews
2. Allow the viewing of other people’s current choices
3. Hide the above and expose them for a drop in point values
4. Hide the above and allow a limited number to be exposed (dial-a-friend and poll-the-experts).
5. List of actors/roles in the movie.

That’ll do for now.