Simple and intuitive image-based navigation

September 30, 2010

My fiancé has been hard at work setting up her online business, selling vintage knitting and crochet patterns.  She has hundreds of patterns that the customer can browse.  The original catalog UI was basically just a huge hierarchy of categories, such as Knitting/Women/Dresses.  We tossed around a few ideas, and landed on something much more user friendly.  Instead of presenting lists of words, we decided instead to show pictures.  She rolled up her sleeves, learned some HTML and Javascript, and made it happen.  The result is very cool and much more user-friendly.  I will definitely use this approach in other UIs that I build in the future.

If you want to check it out, go here: http://shop.princessofpatterns.com/pages/catalog

Sorry if this post seems like a thinly disguised plug.  I’m just very excited about this, and proud that my cohort in crime is turning into a developer!

If you know anybody who is interested in knitting or crochet, please pass the link along.  🙂

Advertisements

Consuming resources from external assemblies in Silverlight 4

September 24, 2010

There’s a bug in Silverlight 4 that prevents you from being able to use resources that are declared in a ResourceDictionary in a referenced assembly.  The error is a XamlParseException whose message is “Failed to assign to property ‘System.Windows.ResourceDictionary.Source’.”.  The problem is that if you have a Silverlight class library whose name ends with “.Resources” it blows up at runtime.  To fix the problem, you must change the assembly name (in the project properties) so that it does not end with “.Resources” but, perhaps, ends with “.Resources.YouHaveToBeKiddingMe“. 😉

Here is an example of using a resource dictionary in an external assembly that will blow up at runtime:

Here is a fixed version:

If you compile a Silverlight application against a project whose assembly’s name ends with “.Resources” that DLL won’t even get included in the XAP or listed in the AppManifest.xml file.  It simply gets ignored, which lead to hours of head-bashing debugging for me.  I hope this workaround saves others the grief!


I’ve gone Mac (will I ever come back?)

September 16, 2010

I couldn’t resist any longer.  I bought a Mac.

Fear not, I’m still madly in love with WPF and rather fond of Silverlight.  But let’s face it, Apple is doing very, very well these days.  Everyone and their grandmother has an iPhone or iPad or MacBook, etc.  For the sake of career growth, job security, skills development, not to mention a shiny new toy, I decided to take the plunge.  I’m really excited about learning Objective-C, Cocoa, CocoaTouch, MonoTouch, and all the rest.  It’s like Christmas morning for me!

My journey of  learning how to tell an Apple device what to do will be logged in my new blog called iJoshSmith.com.  If you’re interested in seeing what it takes for a WPF/SL/.NET dev to warp his mind into Appleness, check it out!


Advanced MVVM now available on Kindle Store in the UK

August 9, 2010

I just got some good news from Amazon.  Folks in the UK can now get my book, Advanced MVVM, from the Kindle store.   If you buy my book from Amazon’s Kindle store, you can read it on a variety of devices: the Kindle e-book reader, iPhone, iPad, your PC, and others.

Here’s the link: http://www.amazon.co.uk/Advanced-MVVM/dp/B0038KX9FW

Also, I have some other exciting news to share.  Team Mole has been very hard at work, creating Mole for Visual Studio 2010, the second generation of our popular debugger visualizer.  We’re getting close to the finish line.  We expect to have our product online, and ready to be purchased, within the next few weeks.  Mole 2010 has been in the works since February.  It’s turning out to be an amazing tool…we’re all very, very proud of it.  We can’t wait to release it! 😀


The MVVM Twilight Zone

May 23, 2010

This morning I went to one of Seattle’s numerous coffeehouses to get breakfast.  While waiting in line, the two guys in front of me (looked like coworkers) were talking, and I overheard them use the term “ViewModel.”  When their conversation came to a lull, I politely asked if they’re talking about MVVM.  The following conversation ensued, between one of the guys and myself:

Guy: “Yes, we are actually.”
Me: “Oh cool, that’s a great pattern.  Always an interesting topic.”
Guy: “We use it all the time.”
Me: “What do you like about it?”
Guy: “I like that it’s based on dependency injection.  That makes it really easy to test ViewModels.”
Me: “What do you mean that it’s based on DI?”
Guy: “I mean, it’s based on DI.  Have you ever actually used the pattern?”   [Guy2 now smirks pretentiously]
Me: “Yes, I’ve used it.  But, to me, it’s based on Models, Views, and ViewModels.  That’s it, no DI.”
Guy: “Well it sounds like you don’t really get it then.  It’s complicated, so you need to read a lot about it.”
Me: “Oh, that’s good to know.  What do you suggest I read to learn about  it?”
Guy: “Start with Josh Smith’s MVVM article in MSDN Magazine.”

I kid you not.  That is literally what the guy told me.  I burst out laughing so loud that I felt embarrassed and had to leave.  The guy must have thought I was psychotic!

It’s worth noting that my MVVM article on MSDN never once mentions dependency injection, inversion of control, or any other dependency inversion technique.  That’s because dependency inversion has nothing to do with MVVM.

Happy coding…


Using DynamicObject to intercept and marshal property changes

May 22, 2010

One of the most interesting (and potentially dangerous) new features in C# 4.0 is support for the dynamic type.  It allows certain pieces of your code to bypass the normal compile-time type checking features that we have grown to know and love.  You can use a dynamic object however you want to, and the C# compiler will ignore the members you use on it.  At runtime, if the methods/properties/etc. your code tries to use are not actually present on the object, an exception is thrown.  If they do exist, they will be linked to and invoked dynamically.   This technique is called dynamic dispatch.  What you lose in safety, you gain in flexibility.

In addition to the dynamic keyword there is also support in the .NET Framework 4.0 for creating types that support dynamic dispatch. The System.Dynamic.DynamicObject class allows you to specify how an object performs dynamic dispatch.  You can subclass DynamicObject and override some of its methods, such as TrySetMember and TryGetMember, to perform whatever logic you need to link a dynamic property set or get to a backing store.

Sound pretty cool, right?  That’s what I thought when I first heard about this functionality.  Then I thought, “Why would I ever need to use this?”  I didn’t have an answer to that question, until tonight.  It dawned on me, while trying to read something not related to programming (damn OCD!), that this could be leveraged to implement a simple, reusable means of marshaling property changes to the UI thread.

As you probably know, you cannot get or set a visual element’s properties from any thread except the thread on which it was created.  When the UI thread creates an element, that element thereafter has an affinity to the UI thread’s Dispatcher object.  The only property on an element that you can access from another thread is its Dispatcher property.  Once you have a reference to an element’s Dispatcher, you can use it to dispatch method calls that manipulate the element on the UI thread.

If you work on a lot of UI-level components and controls, like I do, you probably find yourself writing a lot of code that works with Dispatchers just to do something simple like get or set an element’s property.  What a pain!  It turns out that this pain can be somewhat eliminated by making use of DynamicObject and the dynamic keyword.  Here’s a contrived example that shows how…

The code snippet above shows how to use my DynamicElement class.  It acts as a proxy to an element, which intercepts all access to an element’s properties.  This interception allows the DynamicElement to make use of the visual element’s Dispatcher, if necessary.  Here is how the interception works for setting a property:

The TryGetMember implementation is similar to the code seen above.

You can download the source code here.  NOTE: Rename the file extension from .DOC to .ZIP and then decompress it.


Fireside chat about MVVM

May 17, 2010

Craig Shoemaker recently interviewed me for an episode of his Polymorphic Podcast. We touched on a quite few interesting topics, ranging from the merit of the code-behind file, to implementing Undo functionality, to the role of MVVM frameworks. You can check it out here:

http://weblogs.asp.net/craigshoemaker/archive/2010/05/17/advanced-mvvm-with-josh-smith.aspx