LightSwitch achievements: Chapter two (Events) – Classic events: “The observer”

In this blog post series, we’re going to create a fun extension that will stimulate the users of our LightSwitch applications by rewarding them with points and achievements when they use the application…

Also, in this particular post, I wrote my first VB.NET code ever, which seems to be the .NET language of choice of about 1/3rd of my readers… All comments on the VB.NET code will be considered positive feedback, no matter what you write or how you write it!

Functional POV

Conceptually, when talking about events in .NET, where are talking about a message that one object sends to zero-to-many other objects to let them know that something happened.  There’s four important elements here:

  • the sender (aka the source): the object that sends the message
  • the message: what happened
  • the timing: when did it happen
  • the event handlers (aka the listeners): the objects that want to take an action for the event

Most events will find their use in the presentation layer of our applications, where we want to execute code when the user clicks a button, hover the mouse cursor over an image, …

Semantics POV

It’s hard to talk code without a small example..

using System;

namespace ConsoleApplicationCSharp

    //1. Define the event "signature", usually (but NOT required) has two arguments: sender & event arguments.
    public delegate void ChangedEventHandler(object sender, EventArgs e);

    public class ClassWithEvent
        //2. Define the event.
        public event ChangedEventHandler Changed;

        public void InvokeTheEvent()
            Console.WriteLine("Firing the event");
            // 3. Invoking the event (can only be done from inside the class that defined the event)
            if (Changed != null)
                Changed(this, EventArgs.Empty);

    class Program
        static void Main(string[] args)
            var classWithEvent = new ClassWithEvent();
            //4. Adding an event handler to the event
            classWithEvent.Changed += new ChangedEventHandler(classWithEvent_Changed);


        static void classWithEvent_Changed(object sender, EventArgs e)
            Console.WriteLine("The event has fired");

And the same example in VB.NET (I think…)

Imports System

Namespace ConsoleApplicationVB

    '1. Define the event "signature", usually (but NOT required) has two arguments: sender & event arguments.
    Public Delegate Sub ChangedEventHandler(sender As Object, e As EventArgs)

    Public Class ClassWithEvent
        '2. Define the event.
        Public Event Changed As ChangedEventHandler

        Public Sub InvokeTheEvent()
            Console.WriteLine("Firing the event")
            ' 3. Invoking the event (can only be done from inside the class that defined the event)
            RaiseEvent Changed(Me, EventArgs.Empty)
        End Sub
    End Class

    Module Program

        Sub Main()
            Dim classWithEvent As New ClassWithEvent
            ' 4. Adding an event handler
            AddHandler classWithEvent.Changed, AddressOf classWithEvent_Changed
        End Sub

        Private Sub classWithEvent_Changed(sender As Object, e As EventArgs)
            Console.WriteLine("The event has fired")
        End Sub
    End Module

End Namespace

Just as the functional POV, the code samples reveal that when dealing with events, there are four important elements:

  1. What happened: the first step is to define the event “signature”, which happens in the form of a delegate.  There’s a lot of “standard” event signatures provided by the .NET framework and I would advise you to use them over custom events, but as the samples show, it’s really easy to roll your own.  Event signatures will often have two arguments: sender (a reference to the source, the object that raised the event), and (a subclass of) EventArgs (additional information about what happened).
  2. The sender: we add a property to the class that exposes the event, and add the .NET keyword “event”.  Conceptually, it’s ok to think of this property as a “collection of method references” that all match the signature from step1.  From a technical POV, what we actually do is add a property which is an empty delegate, aka method pointer that has no value yet.  On a traditional property, the compiler will generate two “subroutines”: “get” and “set”.  When we add the keyword “event” to the property declaration however, the compiler will add two “subroutines” called “add” and “remove”.  In the generated “add” subroutine, the value (new delegate) will be combined with the existing value, as opposed to a normal property, where the “set” will replace the existing value, and ofcourse the opposite happens in the “remove” “subroutine”.
  3. When it happened: raising the event is quite simple: do a null-reference check then call the delegate (C#, more technical) or use the (VB.Net, more descriptive) keyword RaiseEvent.  Conceptually, each method in our “collection of method references” from step 2 will be called.  Raising the event can only be done from inside the class that defined it, although often you will see classes that expose this functionality to anyone ( depending on the access modifier: private/public/…).
  4. The event handlers: these are the classes that subscribed to the event, in other words: told the sender they want to be notified when the event occurs, in the form of a method being called.  To do this, use the VB.Net keyword AddHandler, or the C# operator +=.  Both ways are just semantics that when compiled, result in the “add” subroutine from step 2 being called.

There’s a lot more technical aspects of events that I could discuss, the most important ones would be Garbage Collection (or more specifically: the prevention of GC on the event handlers) and thread safety, but let’s not forget that this is a LightSwitch blog, so let’s find out why this information is important for the Achievements extension that we are building in this blog post series…

LightSwitch POV

I wanted to take you in this shallow dive in events in .NET, because for our achievements extension, where most of the code resides in the model layer, not in the presentation layer, we’ll choose not to use this classic observer pattern, and use the event mediator pattern instead.  To justify exactly why we’ll go with a different pattern, it’s important to understand the conceptual and technical differences between the two…

However, the achievements extension will have a little bit of graphical artwork to it, and for this code (/XAML) there’s one event in particular that could use some special attention: INotifyPropertyChanged.

What’s INotifyPropertyChanged?

INotifyPropertyChanged is an interface that exposes just one property: the PropertyChanged event.  This event is extremely important in the MVVM pattern, because the bindings that we define in XAML recognize this event and will subscribe to it.  A Binding instance will update its value (“refresh the view”) if the source raises the event.

The viewmodel that implements this interface can use the PropertyChangedEventArgs in two ways:

  • Fill in the PropertyName: by doing this, the sender signifies to the listeners that one particular property has changed, and that all bindings on this property should update.
  • Leave the PropertyName blank: by doing this, the sender signifies to the listeners that the object changed so radically, that all bindings to any property on this object should update.  It’s basically requesting a general “refresh” of the view.
INotifyPropertyChanged has a brother called INotifyCollectionChanged, also recognized by bindings, useful for “ItemsSource” properties, …

An easy base class…

If you are using EME, (if you’re not: what the hell?) then there’s an easy base class included in the framework for your LightSwitch development convenience…

The ExtensionsMadeEasy.ClientAPI.Utilities.Base.NotifyPropertyChangedBase (source code here, it has been included for a while but never got around to blogging about it)  is a base class (based on the beautiful work by Rob Eisenberg) for your (/my) ViewModels. It exposes three (undocumented, sorry) methods:

namespace LightSwitchApplication
    public class SomeViewModel : ExtensionsMadeEasy.ClientAPI.Utilities.Base.NotifyPropertyChangedBase
        private int myProperty;

        public int MyPublicProperty
            get { return myProperty; }
            set {
                myProperty = value;
                base.Refresh(); //Refresh all bindings
                base.OnPropertyChanged("MyPublicProperty"); //Classic approach
                base.OnPropertyChanged(() => MyPublicProperty); //Approach with lambda expression


Or, in VB equivalent (I think…)

Public Class SomeViewModel
    Inherits ExtensionsMadeEasy.ClientAPI.Utilities.Base.NotifyPropertyChangedBase

    Private myProperty As Integer
    Public Property MyPublicProperty() As Integer
            Return MyProperty
        End Get
        Set(ByVal value As Integer)
            myProperty = value
            MyBase.Refresh() 'Refresh all bindings
            MyBase.OnPropertyChanged("MyPublicProperty") 'Classic approach
            MyBase.OnPropertyChanged(Function() MyPublicProperty) 'Approach with lambda expression
        End Set
    End Property

End Class

The first method (Refresh) raises the PropertyChanged event without a PropertyName on the EventArgs, all bindings on “SomeViewModel” will be refreshed.

The second method raises the PropertyChanged event with a hardcoded PropertyName (“MyPublicPropertyName”) on the EventArgs, all bindings on this property will be refreshed.  The string must match the actual property name exactly…

The third method does exactly the same as the second, but uses a lambda expression.  The major advantage is that the property is not hardcoded (ie: not a string), which gives you compile-time safety: you can not misspell the property name by accident or it won’t compile (happened to me many times before), but will also be updated automagically if you decide to refactor your class a bit, and rename the property.

To each his own of course, but I definitely prefer the latter.  Anyways, let’s see what this event mediator pattern is all about, and why it’s more suited for the model layer of our extension…

MyBizz Portal: The “smallest” LightSwitch application you have ever seen (LightSwitch Star Contest entry).

Dear blog reader, thank you (again) for taking the time to come to my blog and read about my LightSwitch adventures.  In this blog post series, you find my (elaborate) submission to the CodeProject LightSwitch Star Contest.  If you enjoy this article, it would like it if you tweet about it, link from your site to it or send me your firstborn daughter as a token of gratitude, however it would also mean a lot to me if you hopped over to the CodeProject site and voted on the submission as you see fit.  You can also leave any questions, remarks or comments there, however there’s a very good chance that (especially in the distant future) I’ll get your feedback much quicker if you just post on the bottom of this blog post.

Link to CodeProject submission

Addicted to the power of LightSwitch since the first time I ever saw a demo of it, I immediately realized that LightSwitch offered me a window of opportunity to found my own software company, which will officially be born on April 2nd 2012 (after office hours at first)…  LightSwitch is a truly unique tool to write small to medium-sized business applications in virtually no time, with enough flexibility to avoid hitting a “brick wall”, which is all-to-often the case in classic RAD frameworks.  The previous sentence contains a lot of LightSwitch praising and loving, but also contains one of my biggest worries.  What about large enterprise application?  What if my applications start off small, but become giant successes?  Will my beloved technology become a burden once business starts growing?

  • Can LightSwitch handle extremely large applications?  Is there a limit on how much functionality I can fit in one LSML?  Will an enterprise LightSwitch application load fast enough?
  • Can LightSwitch handle horizontal scaling scenarios?  Can I do a distributed installation of a LightSwitch application over several servers to support a massive amount of simultaneous users?
  • How can I reuse screens and entities between my customers when they have similar needs?  Is a VSIX extension really the only way?  And will I be able to partially update one functionality without fear of breaking other parts of the application?
  • LightSwitch can help me develop at lightning speed, but is that the only aspect of a smooth running company?  How can LightSwitch help me to align customers, developers, salesmen, …   Or help me keep track of versions, servers, feature requests, installations, …
  • How are multiple developers going to work on the same LightSwitch application?  Merging the LSML file on a daily bases will be a hell…

Will LightSwitch not only lift me up my feet, but still carry me once I hit cruise speed?

One night – for some reason, my best ideas always hit me about 4-5 hours before my alarm clock tells me to get up and get ready for work – I remembered an essay which contained the statement that “our vision on reality is shaped, and thus limited, by the language that we use“.  By simply using a different lingo (the one used when talking about enterprise service oriented architecture taxonomy), my vision of LightSwitch, and thus its limitations, drastically changed.

LightSwitch taxonomy 1o1

LightSwitch application (LS APP)

To try to speak the same language again, let’s have a quick look at the anatomy of one of the most “complex” LightSwitch applications that we can develop today.  Not mentioning cosmetic extensions, a LightSwitch application itself will generate three core components: a single SilverLight application, that connects to a single WCF service, which in turn connects to a single SQL database, and perhaps you’ll use one of three other datasources: an external database, a sharepoint database, or an external WCF RIA Service.

This is what we formerly called a LightSwich application, however from now on a LightSwitch app will be considered no more than a LightSwitch project structure in Visual Studio

When creating a new LightSwitch application, you can choose to think about the result as a “module”.  A LightSwitch “module” should immediately shape the mental picture that what you are designing is a well-scoped, reusable part of a greater organism.

LightSwitch Entity Module (LS EM)

A LightSwitch Entity Module is a LS APP that has the only responsibility to design simple database entities on which other modules can perform CRUD operations.  It contains no business logic or validation.  (Note: a LS APP will generate a WCF service and a rather empty SilverLight component as well, we’ll just never use them.)

External Process Module (EX PcM)

An External Process Module is any module that can provide access to external processes to the end-user, or to our LightSwitch Process Modules.  By external I am not necessarily trying to indicate that the source code of those modules is not under our control, but merely referring to the fact that they are not written in LightSwitch.

LightSwitch Process Module (LS PcM)

A LightSwitch Process Module is a LS APP that implements a particular business process.  It (optionally) contains its own entities, logic, screens, and references whatever LS EM, EX PcM or other LS PcM it needs to materialize that business process.

Any LightSwitch Module needs careful scoping / designing before development, but this is especially easy to violate when talking about LS PcM.  Consider the functionality of managing customers for my software company.  My sales force needs software to work with those customers, so that they can schedule meetings to talk about improvements or new feature requests.  The development team will need software to work with these customers as well, so that they can implement user stories for them, contact them to discuss that implementation, …  Engineering will also need software to work with these customers, as they’ll want to keep track of the installed software versions, the servers, staging areas, …  And finally, the accountant will need these customers in his accounting suite, so that he/she can bill the customer correctly.  Although it might seem a good idea to create a “Manage Customers LightSwitch Process Module”, it’s a much better and maintainable idea to create four separate LS PcM, because you are dealing with four separate business processes, each with its own logic, references and screens, and most likely with a shared “Customer LS EM” containing common “Customer” entities.  The four separate LS PcM will not only be smaller and more maintainable, but they will load faster too.

LightSwitch Utility Module (LS UM)

A LightSwitch Utility Module is a non-application specific module that provides some reusable functionality.  Ideally, but not always, you can package these as a VSIX extension.  Good examples are generic reporting extensions, logging functionality, or the built-in LightSwitch security module (users, groups & rights).

LightSwitch Portal Module (LS PtM)

A lot of the popular application frameworks, such as PRISM or Caliburn, implement the concept of a “shell”, which blends together different modules or subsystems into a single UI at runtime.  Even after numerous attempts I still haven’t succeeded to implement this runtime weaving in LightSwitch.  However, you can still create a LS APP that provides a rather similar experience to the end-user, considering you can host a web browser in a LightSwitch (desktop) app (thanks Tim Leung for that article, you’re a genius!), and a SilverLight application (LS PcM) is hosted in a normal web page:

Above is my first succeeded attempt to create a LightSwitch Portal Module.  I was working on a proof-of-concept of two interacting LightSwitch applications (hence the “student”/”teacher” entities) when I read Tim Leung’s article.  I just had to try it right there right then.  If you click on the image and pay attention to the web page property, you’ll see that you could create and test your own LS PtM with two simple LS APPs, right from the Visual Studio debugger!

A LightSwitch Portal Module is a LS APP that provides a user a single entry point into a Business Network and the ability to “portal” to the process module of his choice.  

Business Network.

A Business Network is a collection of different modules that support a company in its business.  This network can be partially or completely private (not accessible outside the company domain for example). It can contain numerous External and LightSwitch Modules.  Business networks of allied companies could also partially overlap.

MyBizz network

In the picture above you can see a (simplified) example of such a network.  Two actually.  The network on the left is the network that will fulfill my startup’s needs, the network on the right is one that I created for demo purposes…  Let’s just say – to avoid legal matters – that “a certain real estate company” already saw this “demo that I just had lying around” and “might” become my first paying customer on April 2nd.  Both networks happen to be distributed over both a private (Windows 2008) and a public (Windows Azure) server, totaling 4 servers…

What the picture doesn’t show, is that both networks actually overlap.  It would be more obvious if I’d draw the dependencies between the different components, but that quickly turns the overview into a messy web…  The demo customer’s skinrepository pulls resources from my business (central) skin repository, my STS (see later: single-sign-on) is a trusted STS of the demo customer’s STS, and his MITS (My Issue Tracking System) reads and writes to my PITS (Public Issue Tracking System).  Our two Business Networks contain over 235 entities, hundreds of screens, about every extension I could think of writing (including the Achievements extension to encourage my sales force to write up decent specs for each customer requirement, for which they earn points, which could be materialize in a bonus plan, meanwhile making the work for the developer easier…  and a very early alpha version of the skinning extension), almost all of the free extensions I could get my hands on (thanks to all the community contributors!), and some commercial extensions.

MyBizz Portal

I’m still playing around with the portal application at the moment, but have come to a point where I am satisfied enough to “reveal it to the public”.

Getting started with MyBizz Portal…

Upon a “clean” install, an administrator user can start the application, and after logging in is greeted with the main – and only – screen of the application…

To explain what you are seeing here… I have a LS EM that contains the core data, one of the entities is called a “MyBizzModule”.  In my portal application, I connect to that data, and show it in a custom Silverlight Control.  Because there are no other screens, and no commands, I opted to use a blank shell extension.

Because there’s only one module configured (in other words: only one MyBizzModule record in the database), the only option this application offers us now is to click the lonely red box icon at the bottom…

When clicked, the module opens and displays it’s login screen to us… (You might have to enlarge the image to see that it’s actually a LightSwitch application being shown IN another LightSwitch application).


After logging in, we can see the main screen of the module.  This LS PcM allows us to manage all the modules in a Business Network, only one is configured at the moment.

Name, Image and Portal site should need no explanation, but the fourth one is a very special one which will take more than an hour to explain in detail.

In my Business Network, I have a WCF service that fulfills the role of a Security Token Service.  The login screens used throughout the Business Network are actually all “hacked” custom implementations. Instead of authenticating with the current LightSwitch application, they request an encrypted token from the STS, and use that token as a key to log in – or, and only if automatic authentication fails, present the login screen to the user.

When I logged in to the portal application, the portal application kept the token in memory.

Now, if I check the “Include Security Token” checkbox, and portal to the module, the encrypted token will be passed in the query (I did the same thing with the “LightSwitch Deep Linking“) to the module.  The “hacked” login screen will pick up the token and try to use that token to log in automagically.  This functionality will be really important for the end-user, we do not want him to enter a username & password every time he/she portals to a different module, hence the “single-sign-on”…

Another major benefit is that one STS can “trust” another STS.  This means that I can log on to my Business Network, and navigate to a “public” module from an allied company’s Network.  That module will recognize that the token I’m trying to use was issued from my STS, and map my claims (permissions) accordingly.

Another thing that I’m trying to pass through, is information about the “default skin” that should be used.  This feature is in an EXTEMELY early alpha stage, so I wont go into it too deep.

Last property, the required claim, simply allows the administrator to indicate that only users with the given permission (claim) can view / use the module, allowing fine-tuning of users&groups at a much higher level than the classic screens & entities level that we LightSwitch developers have been doing so far…

Moving on

Enough explaining, let’s give that module some values & restart the application (changes in the configured modules still require a restart at this point… ).

You can see that the “Cosmopolitan.Blue” skin has been loaded (unfinished, based on a Silverlight theme and the LightSwitch Metro theme sources), and that I did not need to log on a second time to enter the module… (Well, kind of hard to post a screenshot of the latter.)

Let’s have some fun and add two sample modules, one portal to Twitter and one to MSDN.

Clicking the bird in the middle shows that the portal application is (obviously) not limited to LS PcM alone, any link that can be shown in a web browser will do…

Finally, just to show my custom SilverLight control – 3 icons really don’t do it justice, these screenshots below are from my Business Network as it is today, roughly 2 months before my company will actually be born…

Which results in this layout…

And for bonus points…

Basic questions

What does your application (or extension) do? What business problem does it solve?

From a technical point of view: it’s a webbrowser wrapper with an advanced URL management system.

From a LightSwitch point of view: it’s a LightSwitch application that manages my LightSwitch applications.

From a functional point of view: it’s an application that allows a user to portal anywhere he wants ( / is allowed to ) inside my LightSwitch Business Network…

From a personal point of view: it’s the last of the missing pieces of the puzzle, it will help me manage my startup (customers, sales force, expenses, keeping track of projects & LightSwitch applications, …) , and gave me the confidence that truly anything is possible with LightSwitch.

How many screens and entities does this application have?

The application has 1 screen and 1 entity.

Additional questions

Did LightSwitch save your business money? How?

Not yet, but I strongly believe it will save me loads once my company is born…   I can however say that without LightSwitch, the chances of me starting a company after my day job, and actually produce working software, would pretty much be zero.

Would this application still be built if you didn’t have LightSwitch? If yes, with what?

Most likely, it wouldn’t have been built.

How many users does this application support?

In theory, over 7,023,324,899; especially since the modules can be deployed on and load balanced over seperate servers.  The databases would be the only bottleneck.

How long did this application take to actually build using LightSwitch?

Less than a week.  Most time was spent trying to make a radial ItemsControl.  I have limited experience as a developer, and none as a designer…  Another two evenings were spent to write this article & take the screenshots.  The LightSwitch part took me 15 minutes.

(Developing both Business Networks took me 6+ months, ofcourse)

Does this application use any LightSwitch extensions? If so, which ones? Did you write any of these extensions yourself? If so, is it available to the public? Where?

The LS PcM in the Business Networks also use…
  • LightSwitch Achievements – homebrewn and part of a blog post series, so available to public soon.
  • LightSwitch STS – homebrewn and won’t be available to public anytime soon, however I’m porting the ability to inject a custom login screen to EME soon.
  • LightSwitch Skin Studio – homebrown and available to public later this year… Much, much later…
  • Many, many, many commercial and free extensions – a special thanks to the LightSwitch crew, Allesandro, Tim, Yann, Bala and Michael for contributing so much to the community! (So sorry in advance if I forgot anyone special!!)

How did LightSwitch make your developer life better? Was it faster to build compared to other options you considered?

LightSwitch gave me an incredible passion & energy to build applications that support the customer’s process, I wouldn’t find the energy to do this in any other technology that I know of at the time of writing…  It does all the tedious and boring tasks for you with a few clicks, and let’s you focus on what really makes your application stand out.

Additional additional questions

Can LightSwitch handle extremely large applications?  Is there a limit on how much functionality I can fit in one LSML?  Will an enterprise LightSwitch application load fast enough?

Yes, if you find any way to split your extremely large applications in many different modules, and bring them all together, there should be no limits for any LightSwitch developer.  The solution I choose (using a webbrowser control) fits my business’ needs perfectly, and because modules are only loaded when you actually access them, drastically reduces the load time of the application.

Can LightSwitch handle horizontal scaling scenarios?  Can I do a distributed installation of a LightSwitch application over several servers to support a massive amount of simultaneous users?

Yes, it does!

How can I reuse screens and entities between my customers when they have similar needs?  Is a VSIX extension really the only way?  And will I be able to partially update one functionality without fear of breaking other parts of the application?

A VSIX is one way, and sometimes the best way.  If you truly want to reuse screens & entities, distributing your application over multiple, reusable modules, adds a whole new dimension of benefits to the LightSwitch way of development.

LightSwitch can help me develop at lightning speed, but is that the only aspect of a smooth running company?  How can LightSwitch help me to align customers, developers, salesmen, …   Or help me keep track of versions, servers, feature requests, installations, …

LightSwitch helped me build several LS PcM to keep track of my business process in just a couple of days…

How are multiple developers going to work on the same LightSwitch application?  Merging the LSML file on a daily bases will be a hell…

Not if they work on one module each…

Where is the source?

– You wish 😉

(Although parts could be polished, then published on my blog, on demand).

LightSwitch Achievements: Chapter one (Introduction) – The idea

In this blog post series, we’re going to create a fun extension that will stimulate the users of our LightSwitch applications by rewarding them with points and achievements when they use the application…

My profile on MSDN, not too shabby considering I didn't know anything about computers 4 years ago...

 History 1o1

If you want to fight a battle, you need an army.  An army full of brave people, trained, ready to kill, and more importantly, ready to get killed.

It’s not completely unnatural to put yourself into a such a dangerous situation for “the greater good”, however if I would have to live with the decision to be in the front line, that “greater good” better be “damn good, and damn worth the risk”.

The Romans understood that their soldiers needed some additional motivation, besides their scanty wages, and granted any soldier freedom and a substantial piece of land, for four years of their loyalty.

Hundreds of years later, Napoleon needed to motivate his soldiers as well, but quickly found himself running out of land to give away.  He was the first one to create a rewarding system based on medals, which – probably to his own surprise – worked remarkably well.  Medals don’t soften the blow of losing a relative on the field, or ease the pain of having one of your limbs shot to pieces, however the visual aspect of those shiny medal coins on a colorful bow, did motivate his soldiers by meeting their “lower esteem needs” (from the fourth tier of Maslow’s pyramid): the need for the respect of others, the need for status, recognition, fame, prestige, and attention.

Today’s plan

History lessons aside, the rewarding  / motivation system of “Points”, “Achievements” and/or “Medals” is anything but history, it is used today in all kinds of areas, from employee retention management, games (MMORPG, XBox gamer profile, …), community sites (MSDN, forums, …), that obnoxious web site that stimulates users to spam their connections on social media, each time they “check in” somewhere, … to even the boy scout badges…

As old as the system may be, it is effective, motivating and fun for the rewardees, so why not make a reusable LightSwitch extension that any developer can set up and start using in no time, to give his/her users some extra incentive.  We will keep track of events that happen in our LightSwitch application, create a system to reward those events to our users, create a visual effect to show each time a medal is awarded, a summary page per user and a “Hall of fame”.

In this blog post series, we will continue our LightSwitch hacking quest, explore some of LightSwitch’s undocumented areas and have a lot of fun in the process…