LightSwitch Conclusion

Over the past few weeks I have been taking a look at Microsoft LightSwitch HTML client “framework”. I have reviewed the basic components of a LightSwitch project, written an application and come to my own conclusions on where LightSwitch fits and where it doesn’t.

These are my opinions based on my study and nothing more.

What LightSwitch is…

LightSwitch is an excellent tool if you want to create a phone or tablet application with a minimum investment in time and resource. It is also an excellent tool if you wanted to add phone/tablet touch capable modules to your existing enterprise application.

LightSwitch can provide a tool to rapidly prototype a touch based application prior to making a significant investment in a touch enabled mobile device platform.

What LightSwitch is not…

LightSwitch, of course, is not a replacement for an enterprise application nor is it a replacement for any data entry centric application. This is not even because LightSwitch is not cool tech but simply because the touch interface is not the right platform for these type of applications. Yes, this is more a statement on the state of touch interfaces than it is an indictment of LightSwitch but this is the space that LightSwitch has presented itself as a tool in the solution stack.

The wrap up…

I will use LightSwitch HTML Client as a tool in my toolbox when I need to develop touch based mobile applications. I think it fits very well in that space. There is very little doubt in my mind that used in the right space and for the right application LightSwitch HTML Client will be an awesome tool.

It like so many other technologies needs to be positioned in the overall stack properly. Just like JavaScript/jQuery is for behavior in the user interface, HTML is for structure, CSS is for style and presentation and server side code is for the heavy lifting each component must be placed properly or it will fail to meet our client’s needs.

The Series…

LightSwitch HTML Client (Part 1)
The LightSwitch Software Stack (Part 2)
The User Interface (Part 3)
Asynchronis Pattern (Part 4)
WinJS Part(5)
datajs (Part 6)

Next…

Real Time Web coming soon to a site near you…

WinJS Part(5)

Part 5

The Windows Library for JavaScript provides a set of new controls designed for Windows Store apps using JavaScript, such as the WinJS.UI.DatePicker, WinJS.UI.FlipView, WinjS.UI.ListView, and WinJS.UI.Rating controls. It also includes two style sheets (one with a dark color scheme and one with a light) that give your app the look and feel of Windows 8.

The WinJs.UI has the following controls available.

  • AppBar
  • DatePicker
  • FlipView
  • Flyout
  • ListView
  • HtmlControl
  • Menu
  • PageControl
  • Rating
  • SemanticZoom
  • SettingsFlyout
  • TimePicker
  • ToggleSwitch
  • Tooltip
  • ViewBox

The one problem that I have with the WinJS library is that it only works with Windows 8 Windows store applications.

The WinJS namespace provides special Windows Library for JavaScript functionality, including Promise and xhr.

The challenge with WinJS is that many of the features only work on Windows 8 applications.

Additional Reading

Asynchronis Pattern (Part 4)

Part 4

The Event-based Asynchronous Pattern makes available the advantages of multithreaded applications while hiding many of the complex issues inherent in multithreaded design.

Using a class that supports this pattern can allow you to:

  • Perform time-consuming tasks, such as downloads and database operations, “in the background,” without interrupting your application.
  • Execute multiple operations simultaneously, receiving notifications when each completes.
  • Wait for resources to become available without stopping (“hanging”) your application.
  • Communicate with pending asynchronous operations using the familiar events-and-delegates model. For more information on using event handlers and delegates, see Events and Delegates.

By using the Asynch pattern in the LightSwitch HTML client the developer can build responsive user interfaces that are capable of doing a lot of work. Typically we use a BackgroundWorker component when building simple multi-threaded applications but as we start to build more complex solutions we will want to build a set of methods, generally analogous to the ones working on the current thread, to handle the computing. The biggest challenge that I have found in doing this kind of work is the lack of ability to update across threads. With some ingenuity you can overcome this nicely. LightSwitch HTML client solves many of those issues for you as it generates the application.

In the HTML client, we chose to expose promise objects to represent asynchronous work. Promise objects provide the most flexible set of options when working in an asynchronous environment and make it easier to structure code in its logical order of execution.

There are a number of promise object implementations available. We chose to utilize the WinJS implementation of promise objects as it was one of the more complete offerings and provided technical alignment with the Windows 8 development experience.

Additional Reading

Event-based Asynchronous Pattern Overview on MSDN
Using Promise objects with LightSwitch

The User Interface (Part 3)

Part 3

The Microsoft LightSwitch team chose to change the paradigm associated with the user interface of the HTML client.

SDI (Single Document Interface) instead of MDI (Multiple Document Interface) aligns with the ‘Responsive Design’ philosophy of starting with the mobile application and adding functionality for larger view ports. The SDI interface also provides a task oriented UI that works well with phones and tablets.

One of the things that was most difficult for me was to overcome my focus on packing as much on a screen as functionally possible. I focused on minimizing the number of clicks and screens/pages/forms that a user was required to interact with. On a mobile phone or table I really needed to change this philosophy and focus every touch on accomplishing something of significance.

The LightSwitch team also focused on screen reuse, tabbed documents and functional interaction to create the compelling user interface of the HTML client.

Navigation boundaries is another new, at least to me, concept that presents some interesting opportunities and challenges. The Save boundary, the Nested boundary and the None boundary have been defined to provide interaction context within the LightSwitch application.

Navigation Boundaries

Each time a user moves between tabs in a screen, shows a dialog or shows another screen, a navigation boundary is crossed. There are three boundary options that may be applied at a navigation boundary that affect both the navigation to the target and the return from the target to the source.

The Save boundary option is only applicable when showing another screen:

Before navigating to the target, if there are changes in the data workspace the user is prompted to save or discard these changes.
While showing the target, the shell exposes “Save” and “Discard” buttons.
Before returning from the target, if there are changes in the data workspace the user is prompted to save or discard these changes.

The Nested boundary option is applicable when showing a dialog or another screen:

Before navigating to the target, a new nested change set is started on the data workspace.
While showing the target, the shell exposes “OK” and “Cancel” buttons.
Before returning from the target, if there were changes made the user is prompted to keep or cancel these changes.

The None boundary option is applicable for all navigation scenarios (and is the only option available when moving between tabs in a screen):

Before navigating to the target, no specific behavior occurs.
If the target is another screen tab, the shell exposes the previously visible buttons.
If the target is a dialog or another screen, the shell exposes a “Back” button.
Before returning from the target, no specific behavior occurs.

Additional Reading

Responsive Web Design with Ethan Marcotte

The LightSwitch Software Stack (Part 2)

Part 2

In this installment of the series we will be looking at the software stack of LightSwitch HTML Client.
LightSwitch Software Stack

The LightSwitch HTML Client architecture is built on the MVVM (Model View ViewModel) pattern which is an adaptation of the MVC (Model View Controller) pattern. These patterns provide for much better separation of concerns and more maintainable code.

The Stack Components

  • Base. This layer provides functionality used by all the other layers. It mostly builds on and uses the fundamental concepts taken from the WinJS library, such as namespaces, classes, events and promise objects.
  • Model. This layer implements loading, parsing and processing of the LightSwitch application model. The model is converted from its original LSML form into a standard JSON representation for quick and easy consumption at application startup.
  • Shared. This layer implements the concept of a business object, which, represents a base for both entities (data) and screens (view models).
  • Data. This layer implements the LightSwitch data concepts, including entities, data services and data workspaces. It depends on the datajs library for underlying communication with the LightSwitch OData service.
  • View Model. This layer implements the LightSwitch view model concepts, including screens and content items. It also implements the view model for the shell, which includes application-wide commands and the LightSwitch navigation model.
  • View. This layer implements the LightSwitch view concepts, including controls, layout primitives and the visualization of the shell. It depends on the jQuery and jQuery Mobile libraries for DOM manipulation and other browser communication.

The layering of the LightSwitch HTML client architecture provides a solid foundation for enterprise applications that are highly maintainable and scalable. I will be reviewing each of the library components individually in subsequent installments of this series.

LightSwitch HTML Client (Part 1)

Part 1

The new path forward?

I have been surveying the landscape recently trying to decide where to spend my professional development time for the next 12 to 18 months. I have shied way from LightSwitch in the past because it was based on Silverlight and XAML and I didn’t think that either of those technologies were worth any investment of my time. Recently I have been encouraged to take another look at LightSwitch in the HTML client version. I have decided to pursue this since it fits directly inline with my desire to master the HTML5 stack.

The following series of articles will chronicle my learning and evaluation experience.

The Overview

LightSwitch HTML Client is a HTML5 and JavaScript based application development “framework” environment for building touch based applications. Using a responsive design philosophy you can develop applications starting with the handheld device and increasing functionality based on the client environment. Using Visual Studio you can point and click your way to a functional application within minutes. I personally have done it in as little as 30 minutes.
LightSwitch Architecture

As you can see from the above graphic the application developer has a variety of options at their finger tips with the promise of new levels of productivity. Substantially gone are the days of spending hours and hours on plumbing code.

I am excited to embark on this journey and hope that you enjoy coming along with me.

Additional Reading

LightSwitch HTML Client Architectural Overview