You might have noticed the very flashy shell that was part of the LightSwitch launch demo recently. Infragistics Services group had the pleasure of working on this project to build a compelling and unique shell for the platform. This is just the latest in a growing list of awesome projects that Infragistics Services group has built for our clients.
My colleague posts can be seen here Jason Bares (Overview) Amy Quinn (UX Prospective)
Those of you who haven’t had the pleasure of playing with LightSwitch for over a month might be wondering what lives under the hood. I would like to take this opportunity to let you know what you can expect when you start developing for LightSwitch. Please note that I said developing for and not developing with, as this post is aimed at developers who will write add-ins, not apps. This is just a high-level appetite wetter for several more detailed posts coming soon to a browser near you.
Those of you who like MVVM will feel right at home in the LightSwitch environment. The view models which LightSwitch provides for you should be enough to get most shell developers up and running. For shell developers, here is a quick rundown of the view models you will be working with, as well as what they will do for you:
· ActiveScreensViewModel – This view model tells you the screen with which the user is currently working.
· CommandsViewModel – This view model has a list of your various commands, complete with everything that you would need to display and invoke them, including the image for the command.
· NavigationViewModel – This view model contains a list of navigation items broken down into groups.
· ScreenValidationViewModel – This view model is used to keep you informed of validation issues on a screen.
Given how much LightSwitch does to keep the UI thread free of long-running commands (such as loading data or activating any screen) you will find that you will be using a dispatcher that will keep the UI that you build responsive, while LightSwitch’s framework does the user’s bidding in the background.
Calling a command is accomplished as follows:
var button = sender as Button;
var shellCommand = (IShellCommand)button.DataContext;
IBusinessCommand businessCommand = (IBusinessCommand)shellCommand.ExecutableObject;
IDispatcherObject dispatcher = (IDispatcherObject)businessCommand;
Above you can see how to handle a button click from a button that has a data context of one of the commands from the collection of shell commands from the CommandsViewModel. This is how to launch screens with LightSwitch.
LightSwitch Earns points on Services
In LightSwitch, almost anything that you want to know can be figured out through one of the many services or providers offered by the SDK. LightSwitch has one interface with which you will be spending a lot of time. This interface offers up the above-mentioned view models, as well as the ModelService, NotificationService, and ScreenViewService.
In a nutshell, LightSwitch offers an eventing system with the notification service. This is used to inform the shell and framework when a user changes the active screen, a screen changes (data entered), or a new screen is activated.
As tech lead on this project for Infragistics, I got very close to the LightSwitch framework and I have to say that while many people are calling this a reboot of Access, I can assure you that this is not the case. It could certainly be said that LightSwitch leverages many new and powerful tools from Microsoft to accomplish a lot of what Access could be stretched to do. However, Access was clearly not designed to stretch as far as many developers have stretched it in the past.
Over the next few weeks, several of my colleagues on this project will blog about their perspectives and lessons learned during development of our recently built shell.
I will be posting more details later but feel free to ask questions and I'll do my best to answer them all.