The easiest way to create business applications for the Desktop and the Cloud
When we originally announced Visual Studio LightSwitch, we introduced a series of blog posts that went under the covers to dive into the anatomy of a LightSwitch application. At that time, this encompassed the end to end solution across the Silverlight client, middle tier and data tier. With the introduction of the HTML client, we wanted to follow up with a similar post looking under the hood of this new client offering.
From an architectural perspective, the LightSwitch HTML client isn’t so different from the existing Silverlight client. It adopts the same logical partitioning – data, screens and shell – and contains all the same concepts, such as entities, screens, content items and controls. This should be of no surprise, since it is based on the same conceptual model and design time experience. Of course, the HTML client looks quite different from a practical perspective. We needed to adopt new frameworks and realize the view layer in terms of the standards-based HTML5 model.
It has always been a core LightSwitch tenet to build applications on top of the same solid foundations you would use to build an application without LightSwitch. In the case of the HTML client, this meant seeking out current or upcoming industry standards for building modern, touch-friendly line of business applications.
The HTML client application stack is divided into five layers based on the MVVM pattern:
When we started working on the HTML client, we evaluated many existing applications on mobile devices to get a sense for how these modern applications operate from a user experience perspective. It quickly became clear that the paradigms exposed by the existing Silverlight shell were not going to be appropriate for a mobile client. Using a number of examples of modern mobile applications, we determined that a few fundamental things had to change:
Further evaluation of these applications led us to believe that a few features missing from the Silverlight client were now quite important in the mobile device space:
The above described changes led us to develop a few simple extensions to the existing data workspace and screen concepts as well as a new application navigation model.
In order to more effectively use the real estate on a mobile device, the HTML client splits a screen into independently viewable partitions. A partition comes in the form of a top-level tab or as a dialog. A user can switch between tabs on a screen like a traditional tab control, and all this does is choose which part of the screen is currently visible. A dialog, on the other hand, temporarily constructs the visual content of the dialog and disposes of it when the dialog is closed.
Here are some screenshots of an example screen “Order Detail” with two tabs, “Details” and “Order Details”, and a dialog “Order_Detail”:
The tab and dialog paradigms provide an effective means of navigating through the content of a single screen, even when that screen has lots of content.
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:
The Nested boundary option is applicable when showing a dialog or another screen:
The None boundary option is applicable for all navigation scenarios (and is the only option available when moving between tabs in a screen):
Navigation boundary options are configured by the source, making the target ultimately more reusable. For instance, a screen may be the starting point of a new task if launched with a save boundary, or it may be incorporated into an existing task if launched with a nested boundary.
In the LightSwitch design experience, the underlying boundary options are exposed using terminology that emphasizes the task-related capabilities of the target:
Here, “Save” maps to the Save boundary, “OK/Cancel” maps to the Nested boundary option, and “Back” maps to the None boundary option.
One of the biggest differences between Silverlight and HTML as presentation technologies is how content is laid out. In Silverlight, content is designed to fit into a box with bounded width and height. HTML is rooted in an entirely different strategy that comes from its document-based heritage. It assumes that content starts at the top and flows from left to right, then downwards until no content remains. This means that while the width may be bounded, the height is not.
These two layout controls enable the look and feel of a rich web application without introducing significant complexity into the DOM.
Early on in developing the HTML client, we placed a bet on an emerging technology that was well positioned to take a lead in the HTML-based mobile application space: jQuery Mobile. In choosing this library, we gained functionality for interacting with the browser navigation stack, but more importantly, we picked up a pattern for rendering touch-friendly controls in the browser DOM.
The concept of a “control” is not well defined in the HTML world. From the LightSwitch HTML client perspective, a control is implemented by a function that does two things: it adds elements to the browser DOM that represents the visualization of the control, and then it connects these elements to data through a data binding API. Once this is done, standard jQuery Mobile behavior takes over and expands the DOM into the actual set of elements to be displayed. The result may be significantly different from the original DOM if it referenced a jQuery Mobile control, or it may be left unchanged if the content is entirely custom elements.
This version of the HTML client has a set of built-in controls that are implemented in this fashion, and it also exposes an entry point for LightSwitch developers to provide their own function that implements a new control in the same manner. This does not provide end-to-end integration of specialized control libraries like we had for Silverlight, but almost all HTML control libraries can be easily instantiated and wired up through this custom entry point.
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.
In this post, we poked inside the HTML client and discovered how its architecture differs from the existing Silverlight client. Many aspects remain the same between the two runtimes, but the HTML client introduces a few new concepts that were necessary to embrace the target platform.
For more HTML Client resources please see the LightSwitch Developer Center and please continue the great discussions and give us feedback in the LightSwitch HTML Client Forum.
Stephen Provine Senior Developer, LightSwitch Team
Stephen, Thanks for the overview and the introduction to the new concepts that the HTML client embraces. Keith
Nice, Ill take a look soon to compare how this shapes up against the web client.
It's possible download this project?
@Arenaut, I assume by "project" you mean the development tool itself, not the code snippets I include in this post. You can try out the latest version by downloading a trial of Visual Studio 2012 at www.microsoft.com/.../downloads, and then installing Update 2 which is the first release to include the LightSwitch HTML client.
angularjs ? knockout?
sorry for duplicate post
@GHR_ARASH, the LightSwitch HTML client came into existence before any specific client MVVM/MVC frameworks were available or were considered "mainstream" enough for us to take a bet on the technology. For this reason, the components you might consider as participating in a MVVM architecture are mostly LightSwitch specific pieces - the data binding and view model systems in particular. However, we do use a well-known framework for the UI and application navigation - jQuery Mobile - as this was rapidly up and coming at the time we started development on the HTML client.
Hope that answers your question.
Any changes in VS2013?
@W12345, there are no major changes to the architecture with VS 2013. The foundational libraries we use are the same, as is the application stack. The control approach and asynchronous coding patterns have also not changed. There has, however, been changes to the UX model since this post that were already part of the product before VS 2013. I would suggest you take a look at the following posts to get up to speed on our latest UX models:
Hope that helps!
Please correct me if I’m wrong: LightSwitch is being touted as the tool for RAD development on SharePoint for end-users; it 'replaces' Access (web apps with limited functionality now). In the demos my end-users noted how easily an app could be built. They were sold, so I built my first simple app – look up a customer and display that customer’s invoices (only 2 tables in SQL Azure with a simple relationship).
Turns out that:
1) LightSwitch assumes table relationships based on columns that are not null – so I had to create views that faked the correct not null columns. ** Lesson: Unless your tables are set up just right, users will shoot themselves out of frustration.
2) I thought I’d create calculated fields as the tables had numeric ‘date’ columns … sounded easy in the demo; however, it requires someone skilled in VB or C#. Turns out that the derived columns are only visible to the server side and not the client … back to the SQL views – once again, this is not for end-users. In the demos it was easy to change how a column was displayed e.g. ‘number’ to a money field. Was very surprised to discover that this only works for a narrow band of data types – back to the SQL. ** Lesson: Unless the data in your tables is as you want it exposed to the client, you’d better be good at SQL.
3)I set up some screens finally – they worked, but the default looked clunky, so I attempted to tweak them. Once the default screen is created, many changes (simple ones that in Access would have taken seconds) require coding. ** Lesson: The screens are clunky except for the most simple of forms, and are not easily maintainable/changeable. Data-over-form sounds good, but end-users often mandate how they want to see things – often because it makes sense and is simpler.
4)I then decided to add another column to an existing screen. For me it wasn’t that difficult – for most of my users it would be impossible. ** Lesson: Once the app is done, changing the data content is not RAD; it would have been quicker in a standard C#, VB or HTML application … Not for end-users.
5) I then attempted to deploy the application to SharePoint (365 hosted) and discovered that I needed site-administrator privileges – To mimic an end-user I had only team-site administration privileges. ** Lesson: So tell me again how users are going to deploy this tool. No way will they be given site administration rights.
6) I decide to deploy onto another SharePoint site where I have full rights … but the code that prepares the app for SharePoint is site specific and can’t rolled back. So what happens when you deploy to a test site, and after testing you want to redeploy to another site? ** Lesson: This cannot be deployed by users – And ignore how simple this looks on the demos (they don’t actually deploy on most of the demos).
Conclusion: Except for the most simple of screens where the tables and columns are set up just right – this is not a tool for end users; they would be better off creating web-apps in Access. Please let me know if I’m wrong.
Thanks for your feedback and constructive comments. I wanted to start off by acknowledging that you are correct. The LightSwitch technology is not an appropriate replacement for Access and is not targeted at the same information worker audience; most of whom lack the necessary coding skills for building applications using this technology.
The term RAD had come to be overloaded and means different things to different audiences. The LightSwitch technology provides developers with a set of experiences that makes building data centric applications more productive than when doing the same with code alone.
Again, thanks for your feedback and for giving LightSwitch a test drive.