Silverlight BiggestBox Feature Complete “…So what!”
All of the features for my Silverlight BiggestBox are now running in the application. This means that the only expected changes to this application will be related to adding new samples to the application—these additions largely come from my current W2 labor in arguably the biggest Silverlight shop in Southern California: 20th Century Fox Filmed Entertainment.
Now that I’m finished, I can commend Scott Hanselman for graciously not complaining about Tweets I’ve sent him regarding the subject of Silverlight after he’s told me politely on two occasions that he is not a Silverlight guy. John Papa is no longer a Silverlight guy. Brian Noyes is no longer a Silverlight guy. Jesse Liberty is effectively out of the Silverlight business—especially when he’s hanging out with Jon Galloway. Sorry guys, for the last six months I’ve been in the Silverlight business…
Jon, by the way, is an ASP.NET MVC guy—and I can relate to that because my Silverlight BiggestBox runs on top of ASP.NET MVC 3 with Razor. In fact, over the last few days I’ve updated my MVC plans in Visual Studio by insisting that my JavaScript libraries must be maintained by NuGet (check my packages.configon pastebin.com). I will no longer try to maintain, say, jQuery UI by hand. More on my MVC stuff later… (And, yes, I adore knockout.js—but this I fear has been abandoned…)
So: the final feature that made the Silverlight BiggestBox so complete has to do with a rather nasty cross-cutting concern: Navigation. What I was rambling about in “Implementing INavigationContentLoader with an abstract class…” has to do with a Navigation system that defines more than just frame pages as Bookmark locations—it resources child windows as “deep-link” indicators as well. When I did all that INavigationContentLoader stuff and pushed the code out, I thought I was done. But what I really did was cover how to navigate to my resources—not properly handling navigating from a resource. When I close my ‘special’ child window (used to display one of the BiggestBox samples), the application needs to navigate back in history.
With MVVM Light Messaging this seemed like a simple fix (I could send a message about a child window closing and then have message “listener” call the Frame.GoBackmethod). However, the UI would sometimes appear (and be) disabled after the child window closed and the messaging did its work. It took more than couple of hours to figure out that my “listener” needs to call Frame.GoBack about one second after the child window closed. This one-second interval would give the UI time to perform its snazzy animations associated with opening and closing a child window. This one-second delay was handled by a System.Threading.DispatcherTimer.
I can exclaim with confidence that there are few people on earth who know how to handle Silverlight Navigation with such fine detail (and I’m even including the folks who built Silverlight itself). But Scott Hanselman might rightfully say, “So what. Who would umm…. be around to care? Hey, Bryan, we have this thing called WinRT now. Didn’t you watch the Build Conference videos?”
Even before details Windows 8 were made public, I knew for years that Silverlight jobs were hard to find. At first I thought it was an emerging technology that will catch on later… then I began to see that it was more like a technology in need of a non-Microsoft evangelist (like how Jesse James Garrett of Google fame turned Microsoft’s Dynamic HTML into AJAX). Silverlight is the concept car of user-experience design. The name Silverlight might fade away but the declarative UI technology represented by it will never go away (it clearly lives on in Windows 8).
My Silverlight BiggestBox is full of little UX snippets that will stand as the gold standard against which all other technologies will be measured. I will use my Silverlight BiggestBox as a guide—a specification as to how something should be built in WinRT Metro-style, HTML 5 or even MXHTML. There is no other mix of tooling and framework features that come close to what Microsoft is offering here. So I’m not going to delete all of my Silverlight files just to keep a few iPhone app millionaires from not laughing at the concept of me and my devotion to Microsoft.
From a Steve-Ballmeresque point of view, Silverlight was unleashed on the world to destroy Adobe Flash. But the mismanagement of brilliant C++ programmers at Adobe is destroying Flash—one security flaw at a time. When Steve Jobs came out against Flash to save iPhone batteries from burning down, it was only a matter of time to start questioning the “strategic importance” of Silverlight. The blunders of Netflix, bearers of the brightest Silverlight flame, didn’t help matters either…
Now that I’m really, really rambling it may not hurt to mention that being ‘finished’ with my Silverlight BiggestBox “kind of” means that I should be “ready” to move on to the next thing… but, I protest: I would like to have enjoyed a few years of living in a well-respected (well-paid) Silverlight world (with a strong kit like the one I’ve just finished backing me up) before moving on… The political/technical situation pressures me to run on to the next thing without taking professional care to pay my respects to the thing I’m working with now…
And now… my exclamation of confidence:
Meh.