SilverlightShow: Silverlight Community

Windows 8 Development + Blendability

editorial@silverlightshow.net (Braulio Diez ) — Thu, 15 Nov 2012 13:50:00 GMT

Download the source code for this article

Introduction

Expression Blend is a “black unknown tool” for many XAML developers. Many geeks (including myself) tended to say things like “Hey ! I’m happy just coding XAML”, “This is for graphic designers”, “It doesn’t generate clean code”.

In this video article we are going to try to demystify this tool for developers, we will learn some basic features that will show us how we can boost our productivity. As a vehicle to explain the concepts and techniques here exposed we are going to write from scratch the following dummy puzzle app:

Don't miss...

All SilverlightShow Ebooks

Video: Win8 Puzzle App - Intro

Takeaways from this article:

How to create your UI using Expression Blend without having to manually code a single line of XAML.
How to assign data binding via properties tab (no more typo-bug when adding a binding).
How to display sample data to allow you fine tune your layout without having to run the app to check the visual aspect.
How to drop controls and customize them (ListView + GridView).
How to visually create and customize controls templates.
How to assign Converters via properties.

Step 1 – Creating the App + Display the list of pieces

In this step we will check how we can apply data binding and display sample data in design mode. We will start by creating the project, and adding a list with the pieces of the puzzle.

We are going to follow the next steps:

Create the project (we will use Visual Studio, we are geeks).
Create an entity that will identify a puzzle piece.
Create a ViewModel that will hold the list of pieces (we will add to it more properties and methods in later steps).
Drop a List View.
Assign Data Context… plus Design Data Context
Apply Data Binding to a control.
Modify items template.
Apply Data Binding to a control template.
Run the app same results as design.

Video: Win8 Puzzle App - CreatingProjectListView

Step 2 – Adding a canvas to build the puzzle

We are going to learn how to customize a GridView using the properties panel and define custom templates. In order to setup the puzzle canvas, we will drop a GridView control, establish the right size and aspect and setup the data binding.

Note: a GridView won’t be the ideal control to be used for a Puzzle Canvas, but I have rather chosen it to get us familiar with this standard control (the goal of the article is to let us learn about Win 8 + Blendability).

We are going to follow the next steps:

Add the plumbing in the ViewModel to hold the puzzle canvas info.
Drop a GridView.
Configure Items container to hold a 2x2 pieces canvas.
Configure the Items Template to be binded to a single puzzle slot + binding.

Video: Win8 Puzzle App - PuzzleCanvas

Step 3 – Drag & Drop Behavior

One cool feature that we get when we develop a Windows 8 app it’s the “AllowDrop” “CanDragItems” properties that are already included into the controls. In this snippet we will setup the drag & drop operations for different combinations of controls (puzzle list >> puzzle canvas, puzzle canvas >> puzzle list view, puzzle canvas >> puzzle canvas).

We are going to follow the next steps:

Create the ViewModel methods to update the puzzle canvas and pieces bucket.
Add Names for the controls (some code in the view going on).
Setup Drag & Drop list view.
Setup Drag & Drop elements of the GridView.
Drag from the Piece’s available list into the puzzle canvas.

Video: Win8 Puzzle App - Drag and Drop #1

Dragging and Dropping other cases

Drag & Drop puzzle canvas to puzzle canvas.
Drag & Drop puzzle canvas to piece’s list view

Video: Win8 Puzzle App - Drag and Drop #2

Step 4 – Notifications, Converters & Blend

In this final step, we will learn how automatically refresh the user interface when a property changes (via INotifyPropertyChange), and how to apply a converter without having to type a single line of code. We will add a boolean property that will notify the user interface when the puzzle has been solved ad we will map the original viewModel property value from bool to visibility (display or hide a textblock).

we are going to follow the next steps:

ViewModel, create a function to check if the puzzle is solved and expose it via property.
INotify Property Changed plumbing.
Adding a Textbox to notify the user… Visibility to Bool?
Adding a converter, assigning it via properties.

Video: Win8 Puzzle App - Converters

Summary

In this article we have learnt how we developers can take benefit of using Expression Blend, letting us design our user interface by dragging and dropping and having available test data in design mode. Most of the topics covered in this article can be applied to the newest Visual Studio 2012 IDE as well.

Near Field Communication in Windows 8: Part 2

editorial@silverlightshow.net (Walter Ferrari ) — Wed, 10 Oct 2012 19:33:00 GMT

In the first part of this article series we have described the main concepts of Near Field communication and how Microsoft has provided support for this technology in Windows 8. Then we have seen how to set up two Windows 8 virtual machines with a proximity driver, i.e something which allows us to simulate a tap gesture. In this second part we will learn how to use the sample proximity driver and explore the functionalities exposed by the Proximity API.

Don't miss...

All SilverlightShow Ebooks

NetNfpControl: a testing tool to simulate a proximity event

As already described in the first part, we can use a sample proximity driver to simulate a tap gesture. We found the sample netnfp solution in the Windows 8 Driver Samples package. In this solution, together with the driver and the package for the driver projects, there is also a project, NetNfpControl, containing a testing tool to simulate proximity hardware.

This project creates a command-line app “NetNfpControl.exe” with three operating modes depending on the command-line parameter used.

1) NetNfpControl.exe []
→ this operating mode allows us to specify either a remote machine name or an IpV6 address which the local machine can connect with and simulate a proximity event.

2) NetNfpControl.exe [/k]
→ in this operating mode the app registers a Ctrl-F1 hotkey at the startup. Since there is no remote machine specified, you have to run the app on both the machines you want to be in proximity. The two machines know each other by using a private share where they have written its network name in a file. Since the file lifetime is 2 seconds, you have to press CTRL-F1 more or less at the same time on both machines. The share is hardcoded, as you may see in the code snippet below. This means you have to change it and recompile it in order to use your share.

void Proximity()
{
    wprintf(L"Checking For Proximate Device\n");

    SYSTEMTIME sysTime = {};
    GetLocalTime(&sysTime);

    wchar_t szDirectory[MAX_PATH];
    StringCchPrintf(szDirectory, MAX_PATH, L"\\\\scratch2\\scratch\\travm\\proxrendezvous\\%u%02u%02u-%02u", 
                    sysTime.wYear, sysTime.wMonth, sysTime.wDay, sysTime.wHour);
    
    CreateDirectory(szDirectory, NULL);
    
    wchar_t szLockPath[MAX_PATH];
    StringCchPrintf(szLockPath, MAX_PATH, L"%s\\lock.txt", szDirectory);

    HANDLE hLock = AcquireFileLock(szLockPath);
    
    wchar_t szOtherMachine[MAX_PATH] = {};
    if (hLock != INVALID_HANDLE_VALUE)
    {
        wprintf(L"looking for available devices in proximity.\n");
        wchar_t szFindPath[MAX_PATH];
        StringCchPrintf(szFindPath, MAX_PATH, L"%s\\*.available", szDirectory);
        WIN32_FIND_DATA findData;
        HANDLE hFind = FindFirstFile(szFindPath, &findData);
        
        wchar_t szFilePath[MAX_PATH];
        bool fClient;
        if (hFind != INVALID_HANDLE_VALUE)
        {
            fClient = true;
            
            wprintf(L"Proximate device found: ");
            StringCchPrintf(szFilePath, MAX_PATH, L"%s\\%s", szDirectory, findData.cFileName);
            HANDLE hFile = CreateFile(szFilePath, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
            if (hFile != INVALID_HANDLE_VALUE)
            {
                DWORD ignore;
                (void)ReadFile(hFile, szOtherMachine, sizeof(szOtherMachine) - sizeof(wchar_t), &ignore, NULL);
                szOtherMachine[MAX_PATH-1] = L'\0';
                CloseHandle(hFile);
            }

3) NetNfpControl.exe [] [/k]

→ this operating mode allows us to simulate a near-field proximity event with the remote machine specified by pressing CTRL-F1, even if the app is in the background. The proximity is simulated for 1 second, then the app exits proximity.

Since these operating modes don’t seem to be very comfortable for my needs I slightly modified the code to allow a fourth operating mode:

4) NetNfpControl.exe [] [/k]

→ this modified operating mode allows us to simulate a near-field proximity event with the remote machine by pressing CTRL-F1, the proximity keeps on until you press CTRl-F1 again. You can re-enter proximity by pressing CTRL-F1 once again. In this way it is very easy to simulate the arrival or departure of a proximity device. The modified solution is available here

To recap, if you follow the steps in part 1 of the article you should have two VMs with Windows 8 with the proximity sample driver installed and working on both. The two VMs should be in the same network to allow communication. Having checked this, you can emulate the proximity event by launching NetNfpControl on one of the two VMs as shown below:

NetNfpControl.exe remoteVM_name /k

and press CTRL-F1 when you run your (proximity enabled) Metro app on the other VM (or both VMs if it is the case).

Building Metro apps “proximity enabled”

To enable your Metro app to use proximity classes, simply add the following capability in the Package.appxmanifest file:

and add the appropriate using directive in your code files:

using Windows.Networking.Proximity;

That’s all: you are now ready to use the Proximity API. In the next paragraphs we will learn how to use the classes in the API by simulating some of the “Tap And Do” scenarios that Microsoft described in its “Windows 8 Near Field Proximity Implementation Specification”.

Simulating Tap And Use

In the “Tap And Use” use case (see first part of the article for further details), a user running an app on his PC will be able to trigger collaboration with the same app running on another machine when the two users tap their machines.

First of all, what we need is something which notifies us when a device is in proximity. The ProximityDevice class contains all the necessary elements to accomplish that. In the code snippet below we obtain a reference to the default proximity device installed in our machine and we use that reference to create two event handlers for the device arrived and departed events.

proximityDevice = ProximityDevice.GetDefault();


if (proximityDevice != null)
{
    proximityDevice.DeviceArrived += ProximityDeviceArrived;
    proximityDevice.DeviceDeparted += ProximityDeviceDeparted;

    WriteMessageText("Proximity device initialized.\n");
}
else
{
    WriteMessageText("Failed to initialized proximity device.\n");
}

Since a machine can potentially contain more than one proximity device (i.e. 2 devices positioned on two diagonally opposite corners of a tablet) there are also methods to enumerate the devices but it is not our case since we are using a proximity sample driver.

Now that we know how to be notified of devices in close proximity, we need to know when one of the two users initiated a tap gesture. To learn this, we can use the PeerFinder static class which exposes some useful methods and properties. First of all, let’s see which discovery options are available in our machine. The PeerFinder.SupportedDiscoveryTypes() method suits us: it can return None if we don’t have any proximity device installed, Browse if we have a WiFI-Direct enabled device, or Triggered if we have a proximity device on board. In our VM with the proximity sample driver installed this method returns the third option, Triggered. This means that we can use the PeerFinder.TriggeredConnectionStateChanged event to intercept a Tap gesture but we cannot use the PeerFinder.PeerFinder.FindAllPeersAsync() for browsing for Peers in the neighborhood.

In the code snippet below we attach the callback handler and start listening for proximate devices.

if(PeerFinder.SupportedDiscoveryTypes == PeerDiscoveryTypes.Triggered)
              PeerFinder.TriggeredConnectionStateChanged += PeerFinder_TriggeredConnectionStateChanged;
PeerFinder.Start();

In the TriggeredConnectionStateChanged event handler we can check what is going on through the State property of the TriggeredConnectionStateChangedEventArgs object. This property can assume five values: PeerFound, Listening, Connecting, Completed, Failed. The image below shows the progress of a proximity connection when a tap gesture is made on one of the two devices in proximity.

When a user makes a tap gesture on one of the two devices in proximity, a first event is triggered and the state property assumes the “PeerFound” value. After this stage it is no longer necessary for the two devices to be in the proximity range since the incoming connection will be established over TCP/IP or Bluetooth. By the way, this is exactly one of the features of NFC, i.e. a technology that can act as an enabler agent for more capable wireless connections.

In the following event triggered, the State property can be “Connecting” if the tap gesture occurs on your device or “Listening” otherwise. The final event indicates us whether the connection was established or not. If it is, then we can get a reference to a StreamSocket object to communicate with the other device.

That’s all: our app can be a game (for instance, a battleship game) , a chat or whatsoever that requires exchange of information between the two devices. With a StreamSocket we can manage this kind of requirements.

Returning to the title of this section, how can we simulate the scenario above using the two virtual machines we have configured in the first part of the article?

I prepared an application skeleton which I called “Tap And Do”: it collects four Tap And Do use cases as shown in the image below:

You can find the source code here.

Follow the steps below to simulate this scenario:

1. Run the virtual Machines. For simplicity, let’s suppose that their network name is VM1 and VM2.

2. Build the NetNfpControl app using the source code modified as described in the previous section and launch it on one of the two VM, for instance VM1 using the following command-line parameters:

NetNfpControl.exe /k VM2

3. Open the Tap And Do solution on both VMs, compile and launch the app

4. Click on “Tap And Use” title on both VM, the apps are ready to communicate

5. Press CTRL-F1 on VM1 (remember this is a hotkey registered by NetNfpControl) to simulate a tap gesture from VM2

6. If it is all OK, you should see an output similar to the two below for VM1 and VM2:

The log in yellow is particularly interesting because it reveals the temporal sequence of the events. First, the local proximity device is initialized, then the simulated tap gesture is caught by the “device arrived” event handler. In this handler we launch PeerFinder.Start() as we have seen in the previous paragraph. The TriggeredConnectionStateChanged event is then triggered twice, one for “PeerFound” and one for “Listening” or “connecting” depending on which device initiated the gesture. At this stage it is interesting to notice that I pressed CTRL-F1 again to exit proximity and this happened before the connection was fully established. This did not hinder the completion of the connection on both devices, because as we have already seen, after the “PeerFound” message the connection is performed over TCP/IP (or Bluetooth).

Simulating Tap And Launch

In the “Tap And Launch” use case (see first part of the article for further details), the user running an app can invite another user to run the same app by tapping his PC to another device. The second user will be invited to launch the same app.

This use case is simpler to simulate than the previous one. The steps are the same as above except for step 4 where you have to start the TapAndDo app just in one of the two VMs. If you do so and PRESS CTRL-F1, you should see an invitation popup asking you to start the TapAndDo app as appears below:

If you look at the log in yellow on VM1 you notice the “Device arrived” event and then the “PeerFound” and “Listening” states of the TriggeredConnectionStateChanged event. If at this stage you press CTRL-F1 again to exit proximity, you will notice that the connection will not be lost until either a timeout is reached or the user of VM2 clicks on the invitation to launch the app.

When the app in VM2 starts, it receives a TriggeredConnectionStateChanged event with a reference to the socket created by the app in VM1. At this stage the two VMs are connected and can start the information exchange. In the yellow log of the image below you can see some details of the streamsocket created on both VMs.

Simulating Tap And Acquire

Tap And Acquire use case regards the case where one user invites a friend to start the same app, but his friend does not have the app installed and he is invited to acquire the app (maybe from the Windows Store). Simulating this is fairly simple with the tools described in the previous paragraphs, therefore it is left to the reader as a challenge (see the dedicated box below).

Simulating Tap And Share and Tap And Receive

Tap and Share describes the case when a user taps his device to another device to share content such as the URL of a webpage or a document. Tap And Receive is similar: in this case the user taps his device to another device (such as a PC or phone) or object (such as a tag) to receive its shared content upon user confirmation. In both cases the communication is established by using a publish/subscribe model. When an app publishes a message, it is put at the disposal of other apps in other devices. When these devices enter proximity, they can subscribe to that message and receive it. Both the publisher and the subscriber have to use the same message type. The ProximityDevice class exposes some methods to use this model such as PublishMessage(..) and SubscribeForMessage(...).

Simulating these scenarios is left to the reader as a challenge (see the dedicated box below).

Conclusion

In this second part of the “Windows Near Field Communication in Windows 8” we have learned how to use the proximity sample driver described in part one and we have simulated some scenarios included in the “Tap And Do” Microsoft interpretation.

Want to test your understanding of this article? Walter Ferrari challenges you to prove you got it all right! Take the two challenges below:

Establish a proximity connection
between virtual machines
Simulate a "Tap and Share"
scenario

Challenges powered by

Near Field Communication in Windows 8: Part 1

editorial@silverlightshow.net (Walter Ferrari ) — Thu, 27 Sep 2012 17:03:00 GMT

Near fied communication (NFC) is a breakthrough technology aimed at facilitating communication between two devices in close proximity, within a 4-cm distance. In Windows 8 the support for this technology has been included in a broader application scope that Microsoft named Near Field Proximity. This article will give you a general view of NFC explaining how Microsoft has reinterpreted it, and we will learn how to build an environment by using 2 virtual machines to test the classes contained in the namespace Windows.Networking.Proximity.

Don't miss...

All SilverlightShow Ebooks

What is NFC?

In a nutshell NFC is a short range wireless communication system between two NFC enabled devices. The communication occurs at a 13.56 Mhz frequency, the same as the Radio Frequency Identification (RFID). As opposed to RFID, NFC works only in conditions of proximity, i.e. few centimeters.
The difference lies in the fact that NFC enabled devices can be mobile phones, tablets, PCs, NFC readers and NFC passive tags. This variety of devices opens the door to various applications and services like identification, access control, e-payment, e-ticketing, health data access and so on. In other words Near fied communication (NFC) is a technology with a potentially major impact on people’s economic and social life. It can be seen as something that simplifies the daily human life.

Let me describe a possible scenario: imagine to wake up in the morning for another workday, take your NFC enabled mobile phone and go to the train station, and to open the turnstile just put your mobile phone close to a NFC reader. To enter your office building you simply use your mobile to punch the clock. In the morning you have a meeting with a new customer: you can swap your business cards by simply approaching your card to his/her NFC-enabled mobile. Then if you wish to offer him/her a coffee from a vending machine, simply approach your phone to the NFC symbol exposed on the machine and you can process the payment

One of the primary information source on NFC is the NFC Forum (http://www.nfc-forum.org).

The NFC Forum was established to specify the NFC standards based on ISO/IEC standards and to promote the NFC technology thus providing guidance on the interoperability among devices and services. In the “specifications” section of the forum you can find all the technical documents which describe protocols, data exchange format and so on.

Regarding the NFC core capabilities, and consequently the interoperability amongst devices, three methods are foreseen for applications using NFC:

Card emulation Mode
This mode allows a NFC device to work as a contact-less smart card (i.e. a credit card). This feature can be used in applications for payments, e-ticketing and so on.
Peer-to-Peer Mode
This mode enables two NFC devices to exchange data using a bidirectional half duplex communication. From the point of view of the users, this mode simplifies information sharing: they just have to tap together their NFC devices with no need for any prior setup.
Reader/Writer Mode
This mode allows an active NFC device to read from/write to a passive NFC tag. Typical examples are applications for smart posters.

The image below shows the underlying layers:

(source: http://www.nfc-forum.org)

The question that may come to mind is now: is this technology widely adopted, or will it be? is it worth learning more about this topic from the point of view of a developer? Judging from the list of

NFC phones already on the market (http://www.nfcworld.com/nfc-phones-list/#available) and the list of newer phones coming soon (http://www.nfcworld.com/nfc-phones-list/#soon) the answer is yes. Let’s learn how Microsoft is addressing this topic in the next paragraph.

The Microsoft interpretation: “Tap and Do”

According to first rumors Microsoft may be including NFC support in Windows 8 raised in September 2011 as announced by NXP. Later, in February 2012, Microsoft published a document entitled “Windows 8 Near Field Proximity Implementation Specification”, available here. It is mainly intended for system integrators and it provides guidelines and requirements that reveal the “Microsoft vision” on NFC. It is worth giving it a read. In this white paper Microsoft defines the communication between two devices in close proximity using a level of abstraction called “Tap and Do”.

Literally the definition of “Tap and Do” is:

“A gesture that is a natural interaction between people in close proximity used to trigger doing something together between the devices they are holding.”

It sounds very similar to the general concept of NFC but in the vision of Microsoft it is something more general. It stands on a system called Near Field Proximity (NFP) provider model. This NFP provider model is a common surface for all the NFP scenarios and use cases, and hides the underlying technology which could be NFC, WI-Direct, Bluetooth or something else. the image below shows the three layers:

The NFP scenarios taken into consideration are the “Ad-Hoch interaction in the Real World” and the “peripheral Wireless Device Setup”. The first fills a gap of Windows and provides an easy way to make two devices communicate together. The second one regards the user experience while installing wireless peripheral devices in Windows. With “Tap and Do” it is stated that this has been extremely simplified.

What about the use cases? “Tap and Do” gesture is the “compendium” of the case uses in the table below:

Use case	Description
Tap and Setup	Tap and pair and set up a peripheral wireless device with Windows
Tap and Reconnect	Tap and reconnect a previously paired and set-up device with Windows
Tap and Use	Tap and connect your app with one running on another machine
Tap and Launch	Tap and invite a user on another machine to launch an app you’re running
Tap and Acquire	Tap and invite a user on another machine to obtain an app you’re running
Tap and Share	Tap and share content you have selected to another device
Tap and Receive	Tap and receive content from another device or poster

Here is a short description of each of these:

Tap and Setup e Tab and Reconnect -> two use cases for installation and unidirectional pairing of wireless peripherals; placing a peripheral (a wireless keyboard or headphone etc) near a PC triggers the device setup or reconnection.

Tap and Use -> it occurs when for instance two users are running the same app (say a battleship game) and tap their PCs toghether; this action triggers an event that can be handled by the two apps to communicate toghether.

Tap and Launch -> this case is particularly intriguing because, when in proximity, one app running on one PC can invite the user of the other PC to start the same app, if installed.

Tap and Acquire -> similar to the previous case but here the second user does not have the app installed and so he is invited to acquire and install the app.

Tap and Share -> imagine you are visiting a website and want to share it with your friend; just tap your PC to the PC (or phone or tablet) of your friend and he will receive a confirmation request to accept the shared

URL.

Tap and Receive -> with this user case a user can tap his PC to another device (a PC, phone or even a passive tag) which is exposing content, and he is invited to receive that content.

The Windows.Networking.Proximity namespace

In the previous paragraph we have seen that a unique Near Field proximity (NFP) provider model is expected for all the underlying wireless technology used. For developers this means good news: there is a common API set to deal with all these technologies (including NFC) and it is available in all the languages that can use WinRT, currently C#, C++ and JS.

Windows.Network.Proximity namespace includes six classes that we can use to realize the use cases described above:

ProximityDevice
ProximityMessage
PeerFinder
PeerInformation
ConnectionRequestedEventArgs

In the second part of this article we will give a close look at the proximity API and we will provide some examples. But before that we need to build a test environment, and this is what the next paragraph is about.

A simulation environment to test Proximity API

At the time of writing this article there is just one device, to my knowledge, available on the market with NFC enabled: Samsung slate PC. Does that mean that we should buy two of these devices for trialling the Proximity API? Fortunately not, there is another way to get a kick out of it. We can use a proximity driver sample included in Windows Driver Kit (WDK) to simulate a tap gesture over a network connection. To do this we can use two virtual machines with Windows 8 onboard and install the driver on both machines. In the following pages you find all the necessary steps to realize that. But before that let's take a look at the recipe needed to build the environment:

Windows 8 Release Preview build
→ I suggest a 64-bit version, you can download it here
Virtualization software capable of running the above build
→ I used VirtualBox 4.1.8 available here
Visual Studio 2012 RC
→ available here
Windows Driver Kit 8.0 (WDK)
→ available here
Windows 8 Driver samples
→ download the full package (C# & C++) from here
Windows Driver Frameworks (WDF) Co-Installers
→ download from here

1. Setup of virtual machines

Using VirtualBox is fairly easy to set up a virtual machine. Just pay attention to name the two VM differently and to choose network settings that allow the VM to communicate together. I used “Bridged adapter” as network adapter as in figure:

Then install Windows 8 and proceed with the installation of Visual Studio 2012, Windows Driver Kit 8.0 and the WDF coinstallers on both VM.

The Windows 8 Driver samples includes a sample called NetNfpProvider which contains the proximity driver. In sample description page there is some guidance for installing and using the proximity driver but the installation is a bit tricky because some steps are skipped. To bring it to a successful conclusion I suggest you follow the steps below.

2. Extract NetNfpProvider sample package

Unzip Windows 8 Driver Samples package in a directory and explore it to locate “NetNfpControl” subdirectory. Open the “netnfp” solution that you will find in the “C++” subdirectory. The solution contains 3 projects:

- NetNfpProvider that contains the driver

- NetNfpControl that contains a command-line executable to interact with the driver

- Package contains driver package

In the Solution Explorer window, right-click Solution 'netnfp' and choose Configuration Manager: make sure that all the projects are configured for x64 platform, as in figure below:

3. Sign the driver

To install a driver on a 64-bit version of Windows, you must sign the driver package. The following procedure helps you to test signing the driver, which is a simplified procedure useful for testing purposes.

Right-click the driver package project, and choose Properties as in figure below:

In the Properties window expand the “Configuration Properties” branch in the tree on the left, click on “Driver Signing” and select Test Sign in the Sign Mode drop-down list as below:

Then click on Inf2Cat > General. In the Run Inf2Cat drop-down list, select Yes as below:

If we now try to build the solution, a catalog file (.CER) will be created.

4. Export the certificate

Now we have to share our signing certificate. Still in Properties, for the package select Configuration Properties > Driver Signing > General and in the Test Certificate choose Select From Store as below:

In the Select Certificate dialog box, select the certificate named “WDKTestCertyourUserName” as in figure below:

Click on Properties of the certificate selected and from the “Details” tab click “Copy to File” as in figure below:

An export wizard will open to guide you to export a .pbx file :

Click on Next to proceed; then you will be asked to choose the export format of the file; choose .PFX as in figure below:

Click Next and protect your private key with a password. Don’t forget your password since you will need it when you import the certificate into your local machine:

Click Next and name the file to be exported as below:

click Save to get the final summary view:

5. Import the certificate into your local machine

Obviously the local machine is one of the 2 VM. Go to the directory where you exported your pfx file and right-click the file; the contextual menu should look like in figure below:

Click Install PFX and in the “certificate Import wizard” dialog box select “Local Machine” as Store location as below:

Click Next and in the next screen , browse for the .pbx file you previously created:

Click Next and type in the password you previously set for your private key:

Click on “Browse” to specify a location for the certificate:

Click on “Show physical stores” check box as in figure below then select “Trusted Root Certification Authorities\Registry” and click OK.

Finally, click the Finish button to complete the import:

5. Install the driver

To sum up, we have test signed the driver, exported the certificate and imported it into the local VM. Now we can install the driver. Create a directory (for instance c:\NetNfpprovider) and copy the following files from the output directory of the VS solution ( i.e. : ..\NetNfpProvider\C++\Package\x64\Win8Release\Package):

driver binary and inf: NetNfpProvider.dll, NetNfpProvider.inf
coinstaller: WdfCoinstaller01011.dll
wdfupdate: WudfUpdate_01011.dll

since you have to run the device console devcon.exe, copy it from \Program Files (x86)\Windows Kits\8.0\Tools\x64 or add the path to the environment variables.

Disable the Windows Firewall or, as suggested by the official guide create an inbound rule to allow incoming requests to NetNfpProvider to the port 9929.

Open a command-line windows as Administrator in the directory in which you copied the files and launch the following command:

“devcon.exe install NetNfpProvider.inf WUDF\NetNfpProvider”

If everything is OK you should be notified that the driver has been succesfully installed as in figure below:

You can now install the driver onto the second virtual machine by importing the certificate driver, copy the directory you created above and launch devcon.exe with the same parameters as above.

In the second part we will learn how to use the driver.

Summary

We have introduced Near field Communication technology highlighting how it could be applied to the everyday life. We have then seen the Microsoft concept of Proximity intended as something more general. With “Tap and Do” Microsoft has summed up with a slogan the communication between two devices in close proximity. In this first part we have minutely described how to install a sample driver onto two virtual machines in order to simulate a tap gesture over the network and have the possibility to test the Proximity API. In the second part we will see how to use the driver and how easy it is to use the Proximity API.

Want to test your understanding of this article? Walter Ferrari challenges you to prove you got it all right! Take the challenge below:

Create Two Virtual Machines with Windows 8

Challenges powered by

Windows 8 Metro Apps: The 8 Must-Know Tricks! Day 2

editorial@silverlightshow.net (Samidip Basu ) — Mon, 16 Jul 2012 21:57:00 GMT

This is Day # 2 in the Windows 8 development article series on common tips & tricks towards developing real-world Metro apps. Over the next several weeks, you’ll see 8 articles talk about some must-do things for Windows 8 Metro app developers. Simple & to the point, with some code examples on XAML/C# stack. Here’s the indexed list for the series:

Don't miss...

All SilverlightShow Ebooks

Day 1: Know the ecosystem; Start
Day 2: Layout, Navigation & Visual States
Day 3: Semantic Zoom
Day 4: Controls & Styling
Day 5: Search, Share & Settings Contracts
Day 6: Data Persistence & Application Life-Cycle Management
Day 7: Use of OData or Web Services
Day 8: Live Services integration

Day 2: Layout, Navigation & Visual States

App Layout:

So, you have the next big app idea. The real question is – will it delight the user? All Windows 8 Metro apps should and it is critically important to plan towards it. One curse for us developers is how easy it is to get started with an idea and go File->New Project in Visual Studio. As the Metro design principles stated again & again, let’s sweat the details. Pen & paper can be a wonderful companion to plan out the overall application layout. How will you slice & dice your content? Is the app content going to laid out in an information hierarchy or in a flat system? How would the app support Metro design principles & integrate with the rest of the OS?

There are two places I personally start out at. One would be OS features or other applications, to be inspired by how others have done it & then give my app it’s own brand. If on Release Preview, the Windows 8 Store is starting to get a lot of very well designed apps that should inspire. Second, are the VS project templates. Although not a good idea to start a project right away, take a peek at the templates; this tells us what some common page layouts are and helps us plan the breakdown of information in our app. Some example layouts below:

The above page templates help us see through the planning of our app: Is it going to a Hub & spoke model with Hub, Section & Detail pages? Or a Flat system of content pages with linear navigation? Your call, but chose well.

Page Layout:

Similar to Windows Phone, Windows 8 Metro apps in XAML/C# stack are made up of multiple pages. These pages are hosted inside of an Application Frame, and constitute the canvas on which we lay out the content of our Metro style apps. When a Metro app is in full mode (taking up the whole screen), edge-to-edge of the display is filled by the current application page, thus immersing the user in content. The real estate is yours to shine in or mess up .

The three basic ways to lay out content in a XAML page still stay the same using the generic container Panel controls – Grid, StackPanel & Canvas. The goal is to make this container support a flexible layout system so that our app looks great in varying screen resolutions, pixel densities & orientations. So, you can see why Dynamic layout system using Grid/StackPanel is more flexible than the Absolute X-Y positioning in a Canvas.

Canvas has a distinct place & use, when we need to absolute-position controls using Canvas.Left & Canvas.Top. If there is a genuine need for absolute positioning, you may consider different pages for supporting various screen resolutions or opt for scaling.

In the dynamic layout containers, we specify child elements in terms of relative position & how they should wrap inside their parent controls. The use of auto or star sizing in control height/width inside the container is the most flexible way to auto-adjust control layout as the size of the parent container changes. Just as in any XAML UI, we lay out our controls in a Grid using RowDefinition & ColumnDefinition; while StackPanel stacks controls horizontally or vertically using the Orientation property.

Control Layout:

So, by now you have your application & page structures laid down roughly. Congratulations! Pat yourself on the back & indulge a little, since you have done the hard part. Now, what comes next isn’t hard; just take meticulous patience. What do we need to remember as we plant controls on a page inside their containers?

Turns out, basic Metro principles help. The key is to be consistent across the application; nothing should be jarring to the user. So, we’ll try to stick to a consistent Metro-inspired pattern of control margins, page headers, app bars, gutter widths and other elements to achieve unity in the app silhouette. Absolutely positively stick to the Grid, in terms of laying out text & controls:

Invest in making a common Page header or App/Nav Bar user control that can be leveraged all across the app, if applicable. Content region on every page needs to strive for consistency in margin & padding of child controls.

Navigation:

Once the application ‘information architecture’ has been laid out in full, navigation between parts of the app should be natural. Content is king; so let us allow the user to use content to manipulate the view presented to him/her. This form of direct manipulation demands that navigation mechanisms be available through the content canvas itself.

Check out this little piece of code from the OnLaunched event handler in App.xaml.cs. It shows how the root Frame of the application is loaded up by the OS on app launch, followed by navigating to the first page:

protected override void OnLaunched(LaunchActivatedEventArgs args)

{

    // Do not repeat app initialization when already running, just ensure that the window is active.

    if (args.PreviousExecutionState == ApplicationExecutionState.Running)

    {

        Window.Current.Activate();

        return;

    }

  

    // Create a Frame to act as the navigation context and associate it with a SuspensionManager key.

    var rootFrame = new Frame();

    SuspensionManager.RegisterFrame(rootFrame, "AppFrame");

               

  

    if (rootFrame.Content == null)

    {

        if (!rootFrame.Navigate(typeof(FirstPageClassName)))

        {

            throw new Exception("Failed to create initial page");

        }

    }

  

    // Place the frame in the current Window and ensure that it is active.

    Window.Current.Content = rootFrame;

    Window.Current.Activate();

}

Navigation between pages in the application frame can be very simply done like this:

   1: this.Frame.Navigate(typeof(SecondPageClassName), CustomParameters);

As you can see, it is easy to carry any custom object or information from one page to another. One caveat would be that if you find yourself doing a lot of this, may be it’s time to consider using some global variables (defined in App.xaml.cs) to have consistent access to the same data across multiple pages.

There is one deviation to creating navigation elements on canvas. And that is around not recreating the wheel and integrating our app with the rest of the Windows 8 OS. The user is already used to using the App Bar & Charms bar; so why give them another way of doing the same thing?

App Bar is perfect for providing context sensitive commands on a given page. It stays tucked away until the user needs to manipulate the view that he/she is on. And application features like Search, Share & Settings should absolutely utilize the app-to-app Contracts in Windows 8 through the Charms – clear, consistent & easily available on right edge swipe. Flyout & Context menus are also a great way to provide navigation hints without inadvertently acting on the user’s touch interaction.

Visual States:

While Windows 8 is meant for all types of form factors, heavy usage of touch-based Metro apps will be from tablets/slates. And that means, we app developers need to be understanding and supporting the various orientation & visual state changes for our app. Supporting orientation changes should be relatively easy if using flexible design layouts of Grid/StackPanel. If your page isn’t too busy, simply allow the controls to flip & support the new orientation; with auto sizing on, the content should flow/wrap as needed. You can select your supported orientations from the application manifest UI editor as below:

Now, as for the Visual State changes, Windows 8 has this wonderful feature of being able to run two Metro applications side by side. This is NOT an optional feature to support since Metro app users will always be able to do this; and not supporting it means we would provide a crappy UX when our app runs side by side with another application.

There are three simple visual state for a Metro application – Full, Filled & Snapped. While the names are explanatory, the image below explains the states even better. Left to right, are Full, Filled & Snapped Visual States of any given application:

If you are using a flexible design layout & data binding through standard controls, supporting this change of visual state is not very difficult at all. And there is plenty of help from the VS generic project templates. Let’s say we were building a Windows 8 Metro app for perusing SilverlightShow article content. A listing of latest articles in Full, Filled & Snapped mode could look something like this (we would walk through the building this sample later in the series):

The beauty of supporting the change in Visual State is the fact that the page could retain it’s state and be bound to the same collection or object behind the scene. We only switch out the UI element that is bound to the data, to fit the much smaller width of the snapped state. The easiest way to get this done is by using one of the default project templates in Visual Studio 2012 for Metro apps. It drops a file called LayoutAwarePage in the Common folder. Inherit your pages off this & voila – you have ready-made hooks into the system events as to when the visual states change. The whole switch can be done purely in XAML using Visual State Manager. Watch how seamlessly we switch the display from a GridView to a Listview , both bound to the same list of article objects:



     

     

         "FullScreenLandscape"/>

         "Filled"/>

  

         "Snapped">

             

                 "itemListScrollViewer" Storyboard.TargetProperty="Visibility">

                     "0" Value="Visible"/>

                 

                 "itemGridScrollViewer" Storyboard.TargetProperty="Visibility">

                     "0" Value="Collapsed"/>

                 

                 "snappedHeader" Storyboard.TargetProperty="Visibility">

                     "0" Value="Visible"/>

                 

                 "regularHeader" Storyboard.TargetProperty="Visibility">

                     "0" Value="Collapsed"/>

                 

             

         

     



In the code above, you’ll see very quickly how named Visual States define the state of the UI. My Full & Filled Visual States are the same; you can choose however your application needs. The Snapped state however, defines a StoryBoard, containing several animations. This is where the simple magic lies – we toggle the visibility of UI elements to adjust to the shorter width of the Snapped state. You’ll notice that the view changes from using a GridView to a ListView and we adjust the page header section to fit. The built-in Frame animations ensure that the whole translation is not jarring; but UI elements ease into place.

We’ll discuss the GridView display in Full mode in the next article; let’s talk about the ListView which is displaying the list of grouped SilverlightShow articles in Snapped mode. Here’s the XAML for it:





    x:Name="itemListScrollViewer"

    AutomationProperties.AutomationId="ItemListScrollViewer"

    Grid.Row="1"

    Visibility="Collapsed"

    Style="{StaticResource VerticalScrollViewerStyle}">

  

    

        x:Name="itemListView"

        AutomationProperties.AutomationId="ItemListView"

        AutomationProperties.Name="Grouped Items"

        Margin="10,-10,0,10"

        ItemsSource="{Binding Source={StaticResource groupedItemsViewSource}}"

        ItemTemplate="{StaticResource SLShowSnappedArticleTemplate}">

  

        

            

                

                    

                        "7,7,0,0">

                            

                        

                    

                

            

        

    



This ListView is fed it’s data in the code-behind. Notice the ItemTemplate? To keep the XAML clean, this is actually defined separately as a style in the StandardStyles.xaml file in the project Common folder. Take a good look at this file to see how the VS templates use all of the styles defined in various layouts & visual states. If you need to customize, it is highly recommended that you make a copy of the built-in style & make it your own, rather than risking the styles used in the generic page templates. Here’s our data template feeding the ListView in snapped mode:



"SLShowSnappedArticleTemplate">

    "6" Width="320">

        "#99FFDD" Opacity="1">

            "10,0,0,0">

                "{Binding ArticleName}" Foreground="#6655FF" TextWrapping="Wrap" FontSize="16" Width="250" Margin="-55,0,0,0"/>

                "Horizontal">

                    "{Binding AuthorName}" Foreground="Orange" FontWeight="SemiBold" TextWrapping="NoWrap" Margin="0,10,0,0"/>

                    "{Binding DisplayablePublishDate}" Foreground="Black" TextWrapping="NoWrap" Margin="10,10,0,0"/>

                

            

        

    



Now, one other thing: What if you had an App Bar or Nav Bar on the Full view of a page? Would you like to change the appearance if either Bar or do some custom manipulation? Can you listen in on the Visual State changing events yourself? Absolutely. That is exactly what the LayoutAwarePage does; we only need event-handlers to listen in. Here’s some code:

using Windows.UI.ViewManagement;

  

// Do this in the Page Constructor.

Window.Current.SizeChanged += VisualStateChanged;

  

private void VisualStateChanged(object sender, WindowSizeChangedEventArgs e)

 {

     string visualState = DetermineVisualState(ApplicationView.Value);

  

     if (visualState == "Snapped")

     {             

         // Custom logic.

     }

     else

     {

         // Return to normal UI.

     }

 }

So, nothing to fear – just a few moving pieces to keep in mind to support Layout, Navigation & varying Visual States in our Windows 8 Metro applications.

PS: Several imagery used courtesy of MSDN Documentation starting @ http://msdn.microsoft.com/library/windows/apps/hh465424.

Conclusion

That’s it for today. The crux of this article was to talk about all the different Layout options for Windows 8 Metro apps and how to navigate between parts of a well-laid out application. We ended with ways to support various orientations & Visual States that Metro applications may need to go through for a enjoyable UX for the user.

See you next time as we dive into some real-world Semantic Zooming in Windows 8 Metro apps. Thanks for reading!

About Author

Samidip Basu (@samidip) is a technologist, gadget-lover and MSFT Mobility Solutions Lead for Sogeti USA working out of Columbus OH. With a strong developer background in Microsoft technology stack, he now spends much of his time in spreading the word to discover the full potential of Windows Phone/Windows 8 platforms & cloud-supported mobile solutions in general. He passionately helps run the Metro Developer User Group (http://themetrodeveloperusergroup.com/), labors in M3 Conf (http://m3conf.com/) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com.

Metro style applications – designing for the user

editorial@silverlightshow.net (Lazar Nikolov ) — Wed, 02 May 2012 12:21:00 GMT

It has been months since Windows 8 is available for developers and the need for new applications is growing in a fast pace.

Don't miss...

All SilverlightShow Ebooks

And nothing is more exacting than a computer user in 21^st century. It’s quite difficult to build the right application, moreover – it’s even more difficult to stay on top and not to be, metaphorically, stepped over by the big players. They always know what exactly the user wants and have the resources to provide it to him. But that’s not always what has to happen after all.

You have the power to build what the user wants and even build it so that s/he would feel it so natural to use your Metro application. That is to design the application in a way that using the fingers on the display seems to be a pleasure, but not a challenge.

Okay, let’s make our Metro applications look great!

Designing the Metro application is different from designing the common and straightforward desktop application. Obviously, using fingers on touch instead of mouse cursor is a big difference. And the Metro style applications will soon become the mainstream.

Here you can find design assets for creating great Metro application mock-ups. The download contains layered PhotoShop files representing common controls and components, project layouts and templates.

In the download you will find lots of .psd files that you can use to build a sketch or mocked prototype of your application. It seems that everything you would ever need is in:

Common controls. A variety of styles of all controls in dark and light Metro themes.
Common components. Tiles with the 1x1 and 2x1 ratio, contracts – the charms bar, search, share and settings side menus and more, and the keyboard.
Base layouts. For fill, full, portrait and snap views.
Project templates. For light and dark themes.

Microsoft provides you with all you could need, but you are, of course, not limited only to the list. All files are layered and fully editable to stick with your mock-up design needs.

User experience design patterns

Here come the UX design patterns. They encapsulate the most important principles in Windows 8 Metro applications and guide you to the ultimate design. Using the patterns helps you in finding answers to questions related to content organization in pages, placing buttons and commands and the touch gestures and interactions.

Navigation design

The navigation design patters guide developers in organizing application content in pages, subpages, sections and categories so the users feel it comfortable and intuitively to switch between application screens and navigate through different views. It focuses mainly on two types of navigation.

The Hub design pattern, or hierarchical system of navigation, is the most commonly used in the consumers preview. It is appropriate when the application consists of large amount of data that also varies a lot. The content is organized in levels and each level is responsible for a specific context. The top-most page – the Hub page, also referred as initial page, is where the content is presented in different sections with different contexts. The Hub page usually provides very different categories of content and less functionality. Its main focus is the content presentation. Each section of the Hub page is associated with a Section page that is more specific in its content presentation. It often contains a number of data items. Each item is then presented in details in the Details page – the third and last level of content.

The Flat design system is used mostly in applications that have a single purpose and clear interaction and process flow. Such an application is document creation tool that has small number of pages that have to be executed all in a specific order.

On the navigation design documentation page here you can also find guidelines and basic navigation concepts for Metro applications.

Commanding design

The commanding design guidelines that you can find here describe the best practices in Metro applications for placing and using command buttons in all possible ways. The focus is on what the user should be able to do and how this should happen. When possible you must allow manipulating items and executing commands directly from the canvas and not by the charms and the application bar. The command buttons have to be consistently used in all application views so it is the same and intuitively for users to execute commands from everywhere. To avoid complexity limit the number of commands and always consider the placement of the button – this could improve the speed a command can be acted upon.

Touch interaction design

On the Microsoft Build conference last year Jensen Harris of the Windows User Experience team announced the results from usability research conducted from Microsoft in their dedicated labs for the comfortable zones of interaction and behavior when using a touch screen device like the Metro tablet. Everyone uses the touch device in a slightly different way in different postures – on the knee, on tables, with two hands on the side, etc. The last turned to be the most common posture.

The touch interaction guidelines (that you can find in details here) describe how to provide good touch interaction experience with your application partly relying on researches among users.

Interaction comfortable area: Because the Windows 8 tablets are most often held along the side, the bottom corners and sides are ideal locations to put your interaction elements. To comfortably reach the center of the screen it takes you a posture change – put the important interaction interface close to the edges in the user’s comfortable zone.

Reading comfortable area: Content in the top half of the screen is easier to read than content in bottom half or the middle because it is often partly covered by your fingers.

Windows 8 has several standard touch interactions, which effects shouldn’t change when the display is touched with more fingers than expected.

Elements from your interface that could be moved around should follow the finger direction while the display is touched. Just like in real world – the pen is in your hand while you don’t put it on the desk. All interactions should be observed, i.e. user should feel or see a feedback from his actions. It’s not acceptable to press a button with your finger and don’t see any flash or any kind of feedback. You could be misled that your touch hasn’t been registered from the device. And last but definitely not least – always consider the size of the things. The error rate increases with the size getting smaller. The recommended minimum size for a touch target is 7x7 mm (40x40 pixels) with at least 2 mm padding. Of course, when the accuracy matters, the size gets bigger.

Touch interactions are important. Think if the interactions as the language that your application uses to communicate with the user. You need this language fluent!

Conclusion

Designing your application in a way that you put yourself in the user shoes is a key factor for the vitality of a future product. In a world where the user is ruling and defines the standards, the design and feel of your application is also the packaging. And the bad pack is even not considered as an option. This article is about attracting users with nice and intuitive user experience in Windows 8 Metro applications. To keep a user, though, you need also the content and value. Harnessing the power of the navigation, commands and touch interactions guidelines and patterns parallel with the content may be the key of your success!

Windows 8 Metro: Create your apps with simplicity in mind

editorial@silverlightshow.net (Andrea Boschin ) — Wed, 04 Apr 2012 01:30:13 GMT

In the recent days an epocal change is becoming evident. If you tried to download the new Windows 8 Consumer Preview, available for free on Microsoft website, you know what I mean. The change, that is greatly focused on a new user experience, is driven by the growing power of portable devices that are becoming prevalent on common desktop and laptops. Up to the day before today, tablet PCs, smartphones, and generically speaking touch-enabled devices was expensive and not effective, but they are now something that common people start to take in serious consideration from the effectiveness perspective and also from the economical point of view.

Don't miss...

All SilverlightShow Ebooks

As said, this change is mostly focused on a new user experience due to the fact that there is a shift of the attention from the business software to the consumer market. Never like today the wide availability of consumer application have been important and this, joined with the new touch paradigm requires a completely new set of rules to design the experience and the interaction of the user with your software.

Starting with this article, I aim to begin a new series based on my evolving experience with the new Windows 8 Metro Applications. As few people knows I have a graphical background that lives side by side with my programmer soul. During this series I would like to discover most of the wonderful tools behind Metro applications but in this article I would like to briefly switch off my programmer side to take in serious consideration the design aspects behind Metro.

The art of remove instead of add

Antoine de Saint-Exupéry, a french writer and aviator lived in early 1900, one day pronounced a famous sentence: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.". There is a deep truth behind these words and I know very few people that is able to embrace this concept when he is working on a project, no matter if he is drawing a furniture item or designing the user interface of the latest application.

Focusing on the software industry, what commonly happens is that a series of features are put togheter, they becomes a software with a complex user interface and most of the times the end-user is unable to use all these powerful features because they are hidden by the complexity or in the worst case they are simply unuseful. Have you ever asked yourself if all the features of your software are fully understand and used by your customers? I did this exercise and the result is mostly disappointing.

So, probably the "art of remove instead of add" is something you have to carefully evaluate. Generally speaking this does not apply only to the user interface of your next application, but it has to deeply permeate it with a careful evaluation on each single feature to understand if it is really useful and if it can be part of the whole. The question you have to ask yourself is simple: is it really useful? And the hard part is being brave considering unuseful something that people usually think as required.

As an example, think at an advanced search form, with lot of fields each one dedicated to the filtering of a specific property. You can search for the title, the abstract, the creation date and (why not?) for the deletion date, for the author, for the contributors, for the collection to which the item is part, etc... Omitting that a similar form can't be subject of an effective functional test, I guess that probably the end-user, after a moment of confusion, will write a word in the title field and then, pressing "Search", he will be unable to find what is searching for.

Google embraced simplicity and converted this complex form in a single field. Behind this field there is a complex syntax and logic, made of operators and of algorithms to effectively search, but people usually write one or two words in the textbox and it find what they need in the first ten results. Simple but not trivial. Embracing simplicity does not mean being trivial. It only mean to have the ability of hide the complication.

Watching to the consumer market, the simplicity become a must. The reason is that if your customer is a business company he will patiently call your helpline to ask you a question, but if the customer is a consumer he will simply delete your app to select another that does exactly what he need. To me, this is the main reason because, with the proposal of Windows Phone 7 and now with Windows 8, Microsoft worked on a series of guidelines that aim to become the standard of a new user experience language, a language that prefers the simplicity. Behind the "Metro Guidelines" there are a number of"pillars" that easily explain the way to the zen of the usability.

The pillars of Metro Style

Embracing a new style in designing an applications may be very hard, primarily because we are used to write our code leaving the aspect of the user interface to a set of "standard" components that leverage an user experience coming from ages ago. Few years ago Microsoft already tried to introduce a new way to design interfaces without a clear success, with WPF and Silverlight. I still remember the moan from people that just discovered the absence of a datagrid control in the Windows Presentation Foundation.

The proposition in leaving controls like the datagrid out of the games was a clear indication to people to search for a completely new user experience but unfortunately this call falled on a dry ground. The reason is to search in the absence of a proper guideline able to drive people to seamless change the feel about user experience.

With Windows Phone and now with Windows 8, Microsoft changes the strategy, proposing a slim set of rules called "Metro Design Principles". These guidelines are based on five pillars that can easily drive in embracing the change. Here is these pillars in my personal order of priority:

Be authentically digital

The first, and to me most significative pillar of Metro, is to be Authentically Digital. To understand the meaning of this sentence you have to recall the look and feel of applications in Windows, and of a number of websites still existing on the net. The problem is that you have to finally recognize the digital nature of the screen surface and this must only drive to the removal of every type of skeuomorphic design. Under this strange term is hidden a number of tecniques used to render the feel of materials, embossing, light effect and whatever else that imitate the real world. iOS devices like the iPad make a deep use of skeuomorphism and this pose them on the very opposite side of the Metro guidelines. The direction instead it to remove every kind of chrome in favor of content to valorize is together with the empty space between parts. Just remember the sentence from Antoine de Saint-Exupéry an recognize the emptiness as a value that isolate and point out your content.

Do more with less

If being digital is the most important pillar, doing more with less is probably the most difficult to achieve, and nothing more that removing instead of add may be the way to this pillar. I think it is important to stop yourself every time you decide to add something to your application and, instead, brainstorming to understand if the same feature cannot be added slightly changing something that still exists. This is to me the essence of doing more with less, having the ability of regroup your features in a way that remove the need of additional graphic elements. But please avoid to add strange semantic to the gestures of the user, just for the reason of omitting an element in the interface.

Be fast and fluid

Often, the key to make more with less is being fast. Having a number of elements on the screen, can be easily exchanged with having few elements if you can navigate through the application fastly and fluidly. Being fast make your screen larger and Metro offers a number of controls that leverage the use of fingers to improve fluidity without neglect the use of mouse. Thanks to these control it is really easy to create amazing interfaces, expand the size of the screen and adapt your content to the target resolution. Also you can use a set of transitions that helps to join together fluidly the various parts of your application.

Show pride in craftsmanship

I admit it take long to really understand what this means, but finally I've got the point. It simply states that your app must be polished and complete in every single feature. Complete does not only mean "working" but you have to care about details. The right margin, a perfect size for your fonts, a polished palette, a subtle animation to give the right feedback to the user. Every single aspect of the user interface contributes to the overall quality.

Win as one.

And finally, you have to be aware that your app live into an ecosystem. Thanks to a number of interfaces, a Metro application can easily share, search and pick, taking advantage of other applications and providing services to others. It is important you implement these interfaces to give an additional gear to your work.

Don't be afraid of emptiness

I know, lot of people when is about to create a user interface ask himself: what can I do to fill this hole? The problem isn't the hole per se, but probably its positions, the disposition of elements on the screen. Make things bigger, use the right color and positions and the hole easily becomes space. Your eye needs it at a degree you may be surprised.

I hope I've touched you curiosity with this long article and now you can experiment the new Metro principles by yourself. From the next time I will return to my programmer role to explore the beautiful features behind Metro.

Working with Prism 4 Part 4: Region Navigation

editorial@silverlightshow.net (Brian Noyes ) — Thu, 16 Feb 2012 16:02:00 GMT

This is part 4 in the series Working with Prism 4.

Introduction

At Microsoft ASP.NET Connections March 26- 29 2012 I’ll be presenting a session on Prism development that includes the capabilities covered in this article – the URI-based navigation capabilities of Prism.

More resources...

All SilverlightShow Ebooks

In this article I am going to right some wrongs in the code from the past couple articles that I put there to keep things simple and focused on other things for the first few articles. When using the MVVM pattern, one of the major goals is to maintain loose coupling and separation of concerns between views and their view models. But even more important is that different view models should not be coupled to each other unless it is a parent-child kind of relationship, and view models should not be coupled to other views or their own view either. When I set up the code in the previous article to load and switch CustomerEditView instances and their view models, I did it all from the CustomerListViewModel. That code involved using the Prism RegionManager to do the view loading and switching, but it required me to create instances of CustomerEditView and CustomerEditViewModel in the code of CustomerListViewModel. That is a violation of the decoupling goals of MVVM.

To fix this I am going to leverage one of the other features of Prism 4 – view switching navigation. In the previous articles, you have seen two parts of the API of the RegionManager service. One involved the Add and Activate methods of the IRegionManager interface. These allow you to explicitly add a view to a region and activate (or show) it at the appropriate times. You also saw in the last article that the AddToRegion method simplifies the process of adding a view if it will be the only. However, these approaches require you to have a view instance available to pass to the methods. That means the code that makes those calls is inherently coupled to the view instances. If you also need to initialize some state of the view model at the point where you are adding the views, that means you might also be coupled to the view model class in that same code. This is the code I placed in the CustomerListViewModel that really should not have been there.

The sample code for this article builds on the code from the last article. You can download the completed code from Part 3 here. You can download the completed code for this article here.

View Switching Navigation

In Prism 4 the capability was added to have a more implicit and loosely coupled form of view switching that mimics the URI-based navigation of the web. If you think about what a user is doing when they navigate to a particular page on a web site by putting in an address, they are not really requesting a specific implementation of a page, they are requesting a named view that is the relative portion of the URI (minus the site address at the root). Through mechanisms like the ASP.NET Routing Service, that URI could map to any kind of implementation behind the scenes, and the requester need not know what or where it is. They just need to know the logical name of the view they are trying to get to in the form of a URI. Additionally, the web addressing scheme allows you to pass additional information as part of the URI, including parameters to be passed to the receiver of the request.

If a view model or other code is going to cause views to switch out in the user interface, it would be nice if that code had the same degree of decoupling from the implementation of the target views as well as a similar logical addressing mechanism. Prism added a great capability that mimics this to load and switch views within a region based on an extension method that was added to the IRegionManager interface, called RequestNavigate. This method has several overloads, but they all take two key parameters: the region name in which you want navigation to happen (similar to the site root address in the web browser analogy) and the logical name of the view you want to navigate to. The caller of the method does not have to know what view type or instance the request for navigation maps to, it just knows there is a logical view out there that is wants to see.

This capability includes more than just the ability to load a view into a region. You can pass parameters to its view or view model as part of the navigation request, and the view or view model can use that information to initialize itself or to refresh its state. The view or view model can participate in the decision of whether to create a whole new view or to reuse one that has been shown before. The view can also participate in deciding if and when the navigation can be completed, so that it could for example prompt the user to save changes or to allow the view switching. I’ll be showing you how to leverage all of this in this article.

Step 1: Export the views by logical name

The first modification to make is to declare the logical name of the view as it will be requested by a piece of code wanting to navigate to it. The way this is done with MEF is by using the [Export] attribute with a contract name. When a view is first requested within a region, Prism will create a new instance of it, add it to the region, and activate it. Subsequent requests to navigate to that view type will either get a new instance or will reuse the existing instance, base on some interfaces I’ll discuss a little later in the article.

The modifications to the views look like this:

   1: [Export("CustomerListView")]

   2: [PartCreationPolicy(CreationPolicy.NonShared)]

   3: public partial class CustomerListView : UserControl

   4: {

   5: ...

   6: }

Notice the association of the logical name with the class. In this case, they happen to be the same. But there is no requirement for them to match. The PartCreationPolicy is required because by default, MEF creates singleton instances of any class it exports unless you change the CreationPolicy to NonShared as shown. This allows us to have multiple instances of the view if desired.

Do the same for the CustomerEditView:

   1: [Export("CustomerEditView")]

   2: [PartCreationPolicy(CreationPolicy.NonShared)]

   3: public partial class CustomerEditView : UserControl

   4: {

   5:     public CustomerEditView()

   6:     {

   7:         InitializeComponent();

   8:     }

   9: }

Step 2: Switch to “View First” construction of the CustomerEditViewModel

In the previous article’s code, the CustomerEditViewModel and CustomerEditView were being constructed and married together by code in the CustomerListViewModel. That is part of what we are trying to fix. It is much easier and better from a development tools perspective (Visual Studio and Blend designers – aka “Blendability”) and code simplicity perspective if the view creates the view model declaratively in the XAML. The CustomerListView and OrdersView were already doing this, but I needed to switch the CustomerEditViewModel so that it is structured the same so that when the view gets constructed (which will happen in the Prism framework with the navigation features we are looking at), the view model is also created and wired up as the view’s DataContext.

   1: <UserControl x:Class="Prism101.Modules.Core.CustomerEditView"

   2:              xmlns:local="clr-namespace:Prism101.Modules.Core"

   3:              ...>

   4:     <UserControl.DataContext>

   5:         <local:CustomerEditViewModel />

   6:     UserControl.DataContext>

   7: UserControl>

Step 3: Request navigation to the CustomerListView on initial load

This step is not explicitly required, but just want to show an alternative to the initial adding of the CustomerListView to the main region. In the previous few articles, the Core module’s IModule.Initialize code looked like this:

   1: public void Initialize()

   2: {

   3:     var view = new CustomerListView();

   4:     RegionManager.AddToRegion("MainContent", view);

   5: }

Instead, using the navigation features, we could do this:

   1: public void Initialize()

   2: {

   3:     RegionManager.RequestNavigate("MainContent", "CustomerListView");

   4: }

Not a huge savings there, but at least this code no longer has to be coupled to the CustomerListView type and worry about its instance lifetime. In the next few steps you will see how it can really start to shine in other areas.

Step 4: Remove the view model coupled code

In the last article, I had the following code invoked when the Edit button was pressed in the CustomerListViewModel:

   1: private void OnEditCustomer()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     bool alreadyExists = false;

   5:     foreach (var view in secondaryContentRegion.Views)

   6:     {

   7:         var custView = view as CustomerEditView;

   8:         var custViewModel = custView.DataContext as CustomerEditViewModel;

   9:         if (custViewModel.Customer == SelectedCustomer)

  10:         {

  11:             secondaryContentRegion.Activate(view);

  12:             alreadyExists = true;

  13:         }

  14:     }

  15:     if (!alreadyExists)

  16:     {

  17:         CustomerEditView editView = new CustomerEditView();

  18:         CustomerEditViewModel viewModel = new CustomerEditViewModel { Customer = SelectedCustomer };

  19:         editView.DataContext = viewModel;

  20:         secondaryContentRegion.Add(editView);

  21:         secondaryContentRegion.Activate(editView);

  22:     }

  23: }

This is the code that not only has coupling to the CustomerEditView and CustomerEditViewModel types, it is also doing instance management of those objects, which is really just wrong. Remove all the code in this method.

Step 5: Request navigation to the CustomerEditView for the right customer

Replace the code that was handling editing with the following code:

   1: private void OnEditCustomer()

   2: {

   3:     var uriQuery = new UriQuery();

   4:     if (SelectedCustomer != null)

   5:     {

   6:         uriQuery.Add("customerId", SelectedCustomer.CustomerID);

   7:     }

8:

   9:     var uri = new Uri("CustomerEditView" + uriQuery.ToString(), UriKind.Relative);

10:

  11:     RegionManager.RequestNavigate("SecondaryContent", uri);

  12: }

Not only is this code much simpler, you can see that there is no type coupling in there at all. The first part of the method uses a helper object from Prism called UriQuery to formulate a query string with a name of customerId and the value from the selected customer. It then concatenates this with the logical view name it wants to request navigation to, and then calls the RegionManager.RequestNavigate extension method, identifying in which region it wants the view to be shown (SecondaryContent in this case). Could not be simpler, right?

Because SecondaryContent happens to be a tab control, it means that each time navigation happens, it could do one of several things:

Add a new tab to the control on every navigation, regardless of what customer is selected
Add only one tab and replace its content with the information for the customer identified in the query string (in which case there would not be much point in having a tab control)
Add a new tab when the customer identified does not already have an active tab, and if it does just activate it

The last option is the one that will be most intuitive for the user, so that is the one we will go with here. But just realize with the mechanisms I’ll be showing shortly, you could do any of these with the exact same RequestNavigate call.

Step 6: Let the CustomerEditViewModel control its own initialization and instancing

In the code that I stripped out of the CustomerListViewModel, the code was not only managing the instancing of the edit view and view model, it was also initializing the state of the view model by setting the Customer property to the SelectedCustomer. Now that Prism is going to take care of creating the view (and implicitly the view model with the view-first construction), you still need a way to initialize the state of the view model. This can easily be done with an interface defined in Prism called INavigationAware. This interface has three members which allow your view or view model to

Known when it has been navigated to and get access to the query string parameters to initialize state
Known when it is being navigated away from (to do something like persist its state to a cache, service, or DB)
Influence whether the view is the target of the navigation or should be reused for navigating to that view type but with different contents

When RequestNavigate is called for a region, the navigation service that does the handling will check the views that are currently contained by that region. If one matches the URI for the view being requested, it will invoke the IsNavigationTarget method to allow that instance to decide whether it should be activated for the navigation to complete. If the view or view model returns true from that, it will be activated if its URI path matches the one being requested. If it returns false, Prism will create a new instance of the view type and place it in the region and activate it. The method is passed a NavigationContext object that contains the URI and parameters for the request to help guide it in its decision to answer the question “are you the one?”

To accommodate the MVVM pattern but not force you to adopt it, whenever Prism looks for an interface implementation on a view, it also checks to see if the DataContext of the view (which should be the view model if doing MVVM) implements it. This allows you to put the logic that supports the interface only on the view model and leave the view as just the structural definition of the visual aspects of the view.

After IsNavigationTarget is called, if it returns true, then the OnNavigatedTo method is called with the same NavigationContext object. This is the chance for the view or view model to initialize itself (possibly based on URI parameters).

The implementation of the INavigationAware interface in the CustomerEditViewModel looks like this:

   1: bool INavigationAware.IsNavigationTarget(NavigationContext navigationContext)

   2: {

   3:     string custId = navigationContext.Parameters["customerId"];

   4:     if (!string.IsNullOrWhiteSpace(custId) && Customer != null && Customer.CustomerID == custId)

   5:         return true;

   6:     return false;

   7: }

8:

   9: void INavigationAware.OnNavigatedTo(NavigationContext navigationContext)

  10: {

  11:     // Choosing to not refresh the customer every time the view is loaded

  12:     if (Customer != null) return;

  13:     // Initial load - Load customer based on ID passed in

  14:     string custId = navigationContext.Parameters["customerId"];

  15:     if (string.IsNullOrWhiteSpace(custId)) return;

  16:     CustomersDomainContext context = new CustomersDomainContext();

  17:     EntityQuery custQuery = context.GetCustomersQuery().Where(c => c.CustomerID == custId);

  18:     context.Load(custQuery, OnCustomerLoadCompleted, null);

  19: }

20:

  21: private void OnCustomerLoadCompleted(LoadOperation obj)

  22: {

  23:     if (obj.HasError)

  24:     {

  25:         MessageBox.Show("Error loading customer: " + obj.Error.Message);

  26:         obj.MarkErrorAsHandled();

  27:         return;

  28:     }

  29:     Customer = obj.Entities.FirstOrDefault();

  30: }

31:

  32: void INavigationAware.OnNavigatedFrom(NavigationContext navigationContext)

  33: {

  34: }

You can see that the logic for IsNavigationTarget checks to see if the query string parameter customerId matches the CustomerID property of the Customer that the view model is managing. If you simply wanted to reuse the view and view model instance and only have one instance of that view type (for containment in a ContentControl for example), you could just hardcode a true return value from the IsNavigationTarget. But in our case we are going to have multiple instances of this view type in a tab control, so we want to use the IsNavigationTarget to drive the logic that if the navigation request is for a customer for which there is already a view, just activate that view. If not, create a new instance of that view type and initialize it based on the customerId.

So the OnNavigatedTo method checks to see if the Customer is already set, this view would not be navigated to unless the IsNavigationTarget had found that the Customer matched the request, so there is no initialization needed (unless you wanted to always refresh the customer data from the back end for example). But if the Customer is null, it is the first time activating this view for a given CustomerId, so the code uses RIA Services to load a Customer from the back end. This approach has the additional advantage that the views are more self-deterministic – instead of requiring some other code to know how to get a Customer and shove the right one into the view, the view (or better yet its view model) knows how to go get the right state based on nothing more than a state identifier of some sort that is placed in the query string. This allows you to move the views around within the app, change who their parent view/view model is, and not have to change anything about how the view gets initialized.

If you are concerned that this pattern will make you make more round trips to the back end, all you need to do is adopt the Repository pattern and have your view models call the repository with their state identifiers, and have the Repository cache the data client side and encapsulate what the cache invalidation scheme is so the views don’t have to worry about it and can just request their current state at any time.

Finally, in this case, we have no logic to perform in the OnNavigatedFrom method so we can just leave that one blank.

Step 7: Let the view decide when navigation happens

There is a very important but subtle point in the way the RequestNavigate method is named. It is a request for something to happen, but it doesn’t say when it should happen or make the implication that navigation will be complete when the method returns. Navigation needs to be a non-blocking request because the view that is currently presented might need to do something (such as prompt the user to save) before allowing the navigation to complete. That is inherently a non-deterministic and potentially long-running block (the user might be distracted tweeting in another window for example). Additionally, a view needs to be able to reject navigation because it may be in the middle of an operation it cannot cancel immediately or you may want to let the user decide whether to dismiss a view for example.

So the RequestNavigate method is a non-blocking asynchronous call. If the caller needs to know when navigation is complete, there is an overload that takes a callback reference that will be invoked by the Prism navigation service once the navigation happens or is rejected. If the view does want to decide if and when navigation should occur, it (or its view model) implements an interface called IConfirmNavigationRequest. This interface has one method, ConfirmNavigationRequest, which is passed a NavigationContext like the INavigationAware methods, and a callback for the method to invoke when it has decided to either allow the view to be deactivated (navigated away from) or to reject the navigation.

In the same application, I chose to demonstrate this by using the IsDirty state of the edit views (the same one that is enabling and disabling Save commands as discussed in the last article). If the view state IsDirty, then the view model will prompt the user with a message box to let them confirm or deny navigation with an OK/Cancel action.

The implementation of this interface is shown below. You can see that is IsDirty is true, it prompts the user. If they press OK, the callback is invoked with a true argument, meaning navigation can proceed. If Cancel, then it gets invoked with false.

   1: void IConfirmNavigationRequest.ConfirmNavigationRequest(NavigationContext navigationContext,

   2:     Action<bool> continuationCallback)

   3: {

   4:     if (IsDirty)

   5:     {

   6:         string prompt = "The view's state has changed and has not been saved, do you want to allow view switching?";

   7:         var result = MessageBox.Show(prompt,"Confirmation",MessageBoxButton.OKCancel);

   8:         if (result == MessageBoxResult.OK)

   9:         {

  10:             continuationCallback(true);

  11:             return;

  12:         }

  13:         else

  14:         {

  15:             continuationCallback(false);

  16:             return;

  17:         }

  18:     }

  19:     continuationCallback(true);

  20: }

Now the one hitch in the sample application is that because these views are presented in a tab control, the user can click on a tab header at any time and cause view switching to occur and the Prism navigation service would not be involved at all, so your view implementations of the INavigationAware and IConfirmNavigationRequest interfaces would not be called. To intercept and prevent tab switching would require a lot lower interception of events on the tab control. So this mechanism for preventing navigation is better suited for containment in a ContentControl where the user does not have a direct user interface mechanism to cause views to swap. But as long as the changing occurs through the navigation controls you put in place that call RequestNavigate, life will be good.

Summary

In this article, you learned how to leverage the navigation capabilities of Prism in a more loosely coupled and flexible way with the IRegionManager.RequestNavigate method, INavigationAware and IConfirmNavigationRequest interfaces. These capabilities allow you to compose a much more loosely coupled application where no code is explicitly tied to view or view model types. The view models can be designed to operate independently of their containers and the code that causes navigation or view switching to happen does not have to be coupled to what the specific implementation of the view is or how it needs to be initialized. This approach still gives you control over when views are created and added to regions and activated, but puts the control in the hands of the views themselves instead of the code that triggers the navigation.

This capability can also be mixed in with the Silverlight navigation framework as shown in this article by Karl Shifflet.

You can download the completed code for this article here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Silverlight MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, VSLive!, DevTeach, and others. Brian worked directly on the Prism team with Microsoft patterns and practices and co-authored the book Developers Guide to Microsoft Prism 4. He is also the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on Twitter @briannoyes.

Working with Prism 4 Part 3: Composite Command and Pub/Sub Events

editorial@silverlightshow.net (Brian Noyes ) — Tue, 24 Jan 2012 10:10:00 GMT

This is part 3 in the series Working with Prism 4.

Introduction

In the last article, I showed how to structure your Prism application to use the MVVM pattern and use DelegateCommands to communicate between the view and view model. Additionally, I showed how to pull some data in using WCF RIA Services and display it in the view, as well as using Prism Regions and the ability to add and activate different views in a region to accomplish simple navigation for the user (view switching).

More resources...

All SilverlightShow Ebooks

In this article, I’ll extend that sample application a little farther and show you how to leverage two other loosely coupled communication features of Prism 4: CompositeCommands and Prism CompositePresentationEvents (aka pub/sub events). The code presented in this article builds on what was the completed code from the last article.

You can download the complete code from the last article that acts as the starting point here. You can download the completed code for this article here.

Note: Now that Silverlight 5 has released, the code for this article uses an updated version of the Prism 4 code recompiled to Silverlight 5 as a target. That code can be downloaded from prism.codeplex.com and is included in the completed code sample for this article.

CompositeCommands

CompositeCommands are another implementation of the ICommand interface defined by Silverlight and WPF. There are several differences about the CompositeCommand implementation and the DelegateCommand implementation. The first is that the CompositeCommand is an aggregation of other commands – a list of ICommand references internally. It allows you to hook up multiple command targets to a single root command that itself can be hooked up to a command source such as a button or menu item. Figure 1 shows this relationship. The CompositeCommand can hold references to any ICommand object, but typically you will use it in conjunction with DelegateCommands. When the CompositeCommand.Execute method is invoked, it will invoke the Execute method on each of the child commands. When CompositeCommand.CanExecute is called to determine whether the command is enabled, it polls its child commands for their result from CanExecute.

Figure 1: CompositeCommands contain other commands

Child commands register themselves with the composite command and can also unregister if appropriate. In this way, it is very similar to a subscribe/unsubscribe of an event, but with the additional functionality of commands to enable and disable the commands based on custom logic.

Another thing different about CompositeCommands is that they can be hooked up to a source control ahead of time, before any child commands have registered. DelegateCommands have to be pointed to their target methods through a delegate at the point where they are constructed. As a result, CompositeCommands allow an extra layer of separation between the source (i.e. toolbar button or menu item) and the target (handling method) – decoupled in lifetime. Because they can target multiple child commands, they also work well for distributed logic such as a Save All command that needs to be dispatched to multiple open documents, each of which has their own handling logic in their view model.

You will see both of these aspects at work in the sample code for this article – separated hook up of the command, and multiple handlers for command execution.

Pub/Sub Events

Another form of loosely coupled communications offered by Prism are pub/sub events. Normal events in .NET are fairly tightly coupled – both the publisher and subscriber objects have to be alive at the same time, the subscriber needs explicit type information and a reference to the publisher to hook up their event handler, and once subscribed, the publisher maintains a reference back to the subscriber through the delegate.

Pub/sub events are designed to break that tight coupling. The idea is that you really want publishers and subscribers to not need either type information or coupled lifetimes. They should be able to come and go independently, and different types of subscribers and publishers should be able to participate in the same event scenario. The event is what is important, not the specific parties who raise or handle the events. To achieve this, you need a middleman or mediator between the publishers and subscribers. The Event Aggregator pattern is a means of achieving this. Prism provides an implementation of the Event Aggregator pattern that is easy to use and that provides several options including strong or weak references for subscribers, thread dispatching, and event filtering.

Figure 2 shows the basic architecture of using the EventAggregator service in Prism. Publishers and Subscribers make calls directly against the EventAggregator to obtain references to event class instances. The EventAggregator is really nothing more than a Registry for event types. Publishers then use those event classes to publish an event with a strongly typed payload and subscribers hook up a listener through a delegate to a method that will accept the payload and handle the event for that subscriber. The event classes are derived from CompositePresentationEvent and do not need any implementation themselves, the class declaration is really just a way to tie together a base class reference with the strongly typed payload through the generic type definition. The CompositePresentationEvent base class provides all the infrastructure to maintain the list of subscribers, dispatch the calls on the appropriate thread, maintain weak or strong references, and filter the calls if desired.

Figure 2: Event Aggregator Architecture

Step 1: Add the Prism Libraries and Recompile for Silverlight 5

The first step for this article is that I downloaded a recently added source code release of Prism 4 from the CodePlex site and added the projects to the solution, as well as changing their compilation target to Silverlight 5. This is because there were a few incompatibilities discovered in using the Silverlight 4 versions of the libraries with Silverlight 5. And I actually stumbled upon one of those incompatibilities in putting together the sample for this article.

Step 2: Modify the application to present multiple edit views

To demonstrate the use of CompositeCommands, I wanted to have a reasonably realistic scenario of where you might use them. As mentioned earlier, CompositeCommands let you separate the hook up of the invoker from the hookup of the receiver in terms of the Command pattern. They also let you have multiple handlers for a given command, to address a Save All kind of scenario, which is what I will be putting together in this article.

To do this, I need more than one thing open at a time to save. I added a TabControl to the MainPage shell view and made it a Prism Region so that multiple CustomerEditView instances could be opened in tabs there instead of swapping out the MainContent region view as was done in the last article.

   1: <sdk:TabControl prism:RegionManager.RegionName="SecondaryContent"

   2:                 Grid.Row="2">

   3:     <prism:TabControlRegionAdapter.ItemContainerStyle>

   4:         <Style TargetType="sdk:TabItem">

   5:             <Setter Property="HeaderTemplate">

   6:                 <Setter.Value>

   7:                     <DataTemplate>

   8:                         <StackPanel Orientation="Horizontal">

   9:                             <TextBlock VerticalAlignment="Center"

  10:                                         Margin="3"

  11:                                         Text="{Binding Title}" />

  12:                             <Button VerticalAlignment="Center"

  13:                                     Margin="3"

  14:                                     Content="X"

  15:                                     Command="{Binding CloseCommand}" />

  16:                         StackPanel>

  17:                     DataTemplate>

  18:                 Setter.Value>

  19:             Setter>

  20:         Style>

  21:     prism:TabControlRegionAdapter.ItemContainerStyle>

  22: sdk:TabControl>

Note the attached property to indicate that this is a Prism Region as discussed in the last two articles, as well as a Style to modify the HeaderTemplate of the TabItems in the TabControl to contain a TextBlock and an X Button to be able to close them. This style gets attached through a custom attached property provided by Prism called TabControlRegionAdapter.ItemContainerStyle. This is needed because the TabControlRegionAdapter is the thing in the Prism toolkit that generates the TabItems as views are added to the region. Also note that the template expects the DataContext to have a Title property for the text in the tab header, as well as a CloseCommand for the button Command. Those will be present on the view models for the individual views which are set as the DataContext based on the MVVM pattern.

To populate the tabs, the EditCommand handling code in the CustomerListViewModel changed to the following:

   1: private void OnEditCustomer()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     bool alreadyExists = false;

   5:     foreach (var view in secondaryContentRegion.Views)

   6:     {

   7:         var custView = view as CustomerEditView;

   8:         var custViewModel = custView.DataContext as CustomerEditViewModel;

   9:         if (custViewModel.Customer == SelectedCustomer)

  10:         {

  11:             secondaryContentRegion.Activate(view);

  12:             alreadyExists = true;

  13:         }

  14:     }

  15:     if (!alreadyExists)

  16:     {

  17:         CustomerEditView editView = new CustomerEditView();

  18:         CustomerEditViewModel viewModel = new CustomerEditViewModel { Customer = SelectedCustomer };

  19:         editView.DataContext = viewModel;

  20:         secondaryContentRegion.Add(editView);

  21:         secondaryContentRegion.Activate(editView);

  22:     }

  23: }

This code is very similar to what was discussed in the last article – it determines if there is a view already being presented within the “SecondaryContent” region for the selected customer. If so, it activates it. If not, it adds one. The main difference here is that the code is now targeting the SecondaryContent region, which is the tab control, and it allows more than one view to be created at a time.

The structure of the CustomerEditView itself did not change at all, but the CustomerEditViewModel had to change quite a bit. First, it needed to have the Title and CloseCommand properties expected by the tab item headers.

   1: public string Title { get { return _Customer != null ? _Customer.CustomerID : "Empty"; } }

2:

   3: public DelegateCommand CloseCommand { get; private set; }

Second, the CloseCommand handling needs to simply remove its view from the region, not swap views as the SaveCommand handling did from the last article:

   1: private void OnClose()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     foreach (var view in secondaryContentRegion.Views)

   5:     {

   6:         if (view is CustomerEditView && ((FrameworkElement)view).DataContext == this)

   7:         {

   8:             secondaryContentRegion.Remove(view);

   9:             break;

  10:         }

  11:     }

  12: }

Third, it needed the SaveCommand logic to not swap views but to just manage the “saved” state of the view. In this case, for demo purposes, that meant just modifying the view model to support an IsDirty flag. That flag gets set when the customer is modified (one of its properties change). The flag gets cleared when the SaveCommand fires. Additionally, the SaveCommand was modified to have a CanExecute handler that checks that IsDirty flag. If the view’s state is not dirty, there is no reason to invoke the SaveCommand so its invoker should be disabled.

   1: Customer _Customer;

   2: bool _IsDirty = false;

3:

   4: public CustomerEditViewModel()

   5: {

   6:     SaveCommand = new DelegateCommand(OnSave, CanSave);

   7:     ...

   8: }

9:

  10: public DelegateCommand SaveCommand { get; private set; }

11:

  12: public Customer Customer

  13: {

  14:     get { return _Customer; }

  15:     set

  16:     {

  17:         if (_Customer != value)

  18:         {

  19:             if (_Customer != null) _Customer.PropertyChanged -= OnCustomerChanged;

  20:             _Customer = value;

  21:             if (_Customer != null) _Customer.PropertyChanged += OnCustomerChanged;

  22:             RaisePropertyChanged(() => Customer);

  23:         }

  24:     }

  25: }

26:

  27: public bool IsDirty

  28: {

  29:     get

  30:     {

  31:         return _IsDirty;

  32:     }

  33:     set

  34:     {

  35:         _IsDirty = value;

  36:         SaveCommand.RaiseCanExecuteChanged();

  37:     }

  38: }

39:

  40: private bool CanSave()

  41: {

  42:     return IsDirty;

  43: }

44:

  45: private void OnSave()

  46: {

  47:     IsDirty = false;

  48: }

49:

  50: private void OnCustomerChanged(object sender, PropertyChangedEventArgs e)

  51: {

  52:     IsDirty = true;

  53: }

Notice that the CanSave handler just returns the flag. But since the enablement of the command depends on that flag, that means whenever that flag changes, the command should raise the CanExecuteChanged event. The best way to do that is to encapsulate the call to the DelegateCommand.RaiseCanExecuteChanged method in the setter for the IsDirty property and use that property internally throughout the view model instead of the member variable.

At this point I have the setup to be able to edit multiple customer views at the same time in individual tabs. Next I want to be able to add a “Save All” command invoker at a shell level and have it invoke the SaveCommand on the individual open edit views as shown in Figure 3.

Figure 3: Multiple edit views active in the tab region

Step 3: Add a CompositeCommand for the Save All command

A common way to define a CompositeCommand is similar to how WPF defines the built-in routed commands – as a public static readonly singleton instance of the command. In order for the invoker to be in one module and the handlers to be in different modules, they all need to be able to get to that definition of that command to hook up to it. So you will need to have a common or shared assembly that all the parts of your solution can reference to hold shared types like CompositeCommands and Pub/Sub events.

The sample solution has a Silverlight Class Library project added with a Commands class to contain the CompositeCommand instances you want to define – in this case the SaveAllCommand.

   1: public class Commands

   2: {

   3:     public static readonly CompositeCommand SaveAllCommand = new CompositeCommand();

   4: }

Step 4: Hook up the CompositeCommand Invoker

The invoker is simply a button in the MainPage.xaml:

   1: <Button Content="Save All"

   2:         Command="{Binding SaveAllCommand, RelativeSource={RelativeSource AncestorType=UserControl}}" />

If you are using CompositeCommands in WPF, you can refer directly to the static instance with the {x:Static} markup extension. Because Silverlight does not have that markup extension in the framework, you will have to bind to a property exposed to your XAML. In this case to keep it simple, I expose that property from the code behind of the MainPage view itself and use a RelativeSource binding to get to the root element that corresponds to the code behind class. Then in the code behind I expose the static command variable via the property that the XAML is binding to. Alternatively I could have just hooked up the command in the code behind with a reference to the button.

   1: public ICommand SaveAllCommand { get { return Commands.SaveAllCommand; } }

At this point the invoker is ready to invoke the command, but the button will be disabled because the CompositeCommand, as a container for command instances, is empty. The default logic of CompositeCommand is to be disabled unless all of its child commands are enabled. If there are no child commands, it is disabled because there is nothing to invoke. If you find you want different logic, such as enabling the command if any one of its child commands is enabled, all you need to do is derive a class from CompositeCommand and override the CanExecute method.

Step 5: Hook up the child command instances

As mentioned earlier, CompositeCommand exposes a Register/Unregister API for adding and removing child commands. To add a child command, simply call Register, passing an ICommand reference. Because the CustomerEditViewModel already has a SaveCommand that I want invoked when Save All is invoked, I just need to pass a reference to that in the constructor for the view model:

   1: Commands.SaveAllCommand.RegisterCommand(SaveCommand);

Likewise, when the view is going away (in the CloseCommand handler), you should unregister the command, otherwise the CompositeCommand will keep it, and be indirection, your view model, alive.

   1: private void OnClose()

   2: {

   3:     IRegion secondaryContentRegion = RegionManager.Regions["SecondaryContent"];

   4:     foreach (var view in secondaryContentRegion.Views)

   5:     {

   6:         if (view is CustomerEditView && ((FrameworkElement)view).DataContext == this)

   7:         {

   8:             secondaryContentRegion.Remove(view);

   9:             Commands.SaveAllCommand.UnregisterCommand(SaveCommand);

  10:             break;

  11:         }

  12:     }

  13: }

At this point you should be able to run the application and open several edit views as shown in Figure 3. Initially all of the Save buttons in the edit views as well as the Save All button will be disabled because none of the views are dirty. Go make an edit to each one of the views, and you will see their individual Save button become enabled. With the default CanExecute logic of the CompositeCommand, not until all of the child commands becomes enabled is the CompositeCommand itself enabled. So at the point where you have each of the child views Save enabled through an edit, the Save All button will become enabled. Clicking it invokes the SaveCommand handler in each instance of the CustomerEditViewModel, setting its IsDirty flag to false and raising the CanExecuteChanged handler for that command, which the CompositeCommand will monitor to refresh its own command enabled state.

Step 6: Add an Orders Module

A common usage of pub/sub events is to communicate between loosely coupled module components, particularly from one view model to another, especially if those view models are defined in separate modules. To demonstrate this, I want to add the capability to display the last 10 products ordered by a customer in a side panel whenever a customer is selected. I want this functionality to be decoupled from the customer listing and editing capabilities in the Core module, possibly developed by a separate team or added as a separate pluggable feature of the application.

To do this, I added a new Orders module to the solution following the procedures outlined in the first article for defining a Prism module:

Add a Silverlight Application project
Delete MainPage.xaml and App.xaml
Set the Startup Object in the project settings to Not Set.
Add Prism references, setting the Copy Local property on the references to false so that you don’t get multiple copies of the Prism libraries loaded when the module loads.
Defined an OrdersModule class with a ModuleExport attribute and an implementation of the IModule interface.
Added the Orders module to the Silverlight hosting settings of the Web project so that it is available for download by the module manager in Prism.
Added module information to the ModuleCatalog.xaml in the shell project.

Additionally, since now both the Core module and the Orders module will need to use WCF RIA Services to retrieve data from the back end, it makes sense to move the client WCF RIA Services code out to a shared library so that there is just one definition of the entity types and the DomainContext that lets the client code talk to the server. As a result, I also did the following in the solution:

Removed the RIA Services link from all the client projects.
Added a NorthwindRIAClientLibrary Silverlight Class Library project with the RIA Services link in the project properties set to the hosting web project where the domain services live.
Added a reference to NorthwindRIAClientLibrary to each of the projects, with them all set to Copy Local = false except the reference in the shell application.

Step 7: Add another region for the view to plug into

In MainPage.xaml in the shell application, I added another region named SidePanel to the right of the listing of customers for the order summary to plug into.

   1: <Grid Grid.Row="1">

   2:     <Grid.ColumnDefinitions>

   3:         <ColumnDefinition Width="*" />

   4:         <ColumnDefinition Width="Auto" />

   5:     Grid.ColumnDefinitions>

   6:     <ContentControl prism:RegionManager.RegionName="MainContent"

   7:                     Grid.Column="0"

   8:                     Margin="5" />

   9:     <ContentControl prism:RegionManager.RegionName="SidePanel"

  10:                     Grid.Column="1"

  11:                     Margin="5" />

  12: Grid>

Step 8: Add a View and ViewModel to present the order summary

The view simply contains a DataGrid with three columns: Order date, product name, and quantity. The view model uses WCF RIA Services to retrieve the order information for a given customer and populate a collection of OrderItem data structures to populate the DataGrid with the three columns.

   1: public class OrdersViewModel : INotifyPropertyChanged

   2: {

   3:     CustomersDomainContext _Context;

   4:     public OrdersViewModel()

   5:     {

   6:         if (!DesignerProperties.IsInDesignTool)

   7:         {

   8:             _Context = new CustomersDomainContext();

   9:         }

  10:     }

11:

  12:     ObservableCollection _Orders = new ObservableCollection();

  13:     public ObservableCollection Orders

  14:     {

  15:         get { return _Orders; }

  16:         set

  17:         {

  18:             if (_Orders != value)

  19:             {

  20:                 _Orders = value;

  21:                 PropertyChanged(this, new PropertyChangedEventArgs("Orders"));

  22:             }

  23:         }

  24:     }

25:

  26:     public void OnCustomerSelected(Customer cust)

  27:     {

  28:         Orders = new ObservableCollection();

  29:         if (_Context == null || cust == null)

  30:         {

  31:             return;

  32:         }

33:

  34:         EntityQuery detailQuery = _Context.GetOrder_DetailsQuery();

  35:         _Context.Load(detailQuery.Where(

  36:             det => det.Order.Customer.CustomerID == cust.CustomerID).OrderByDescending(

  37:             det => det.Order.OrderDate).Take(10), OnDetailsLoaded, null);

38:

  39:     }

40:

  41:     private void OnDetailsLoaded(LoadOperation loadOp)

  42:     {

  43:         var details = loadOp.Entities;

  44:         if (details != null)

  45:         {

  46:             var detailsList = details.ToList();

  47:             detailsList.ForEach(det => Orders.Add(

  48:                 new OrderItem

  49:                 {

  50:                     ProductName = det.Product.ProductName,

  51:                     Quantity = det.Quantity,

  52:                     OrderDate = det.Order.OrderDate.Value

  53:                 }));

  54:         }

  55:     }

  56: }

Now the only thing left to do is call the OnCustomerSelected method whenever a Customer is selected in the main listing. But that code lives in a totally separate module that you are trying to keep decoupled. Prism events to the rescue.

Step 9: Add a Prism Event

When working with Prism events, the first thing to do is to declare the event type. You do this by deriving a type from CompositePresentationEvent as described earlier, and indicating through the generic type argument what the payload type will be:

   1: public class CustomerSelectedEvent : CompositePresentationEvent { }

Like the CompositeCommand, this type will need to be referenced by both sides of the communication, even though those two sides need to be decoupled from each other. So this is another one of those types you will want to declare in a shared library that any modules in the solution can reference.

Step 10: Hook up the subscriber

To hook up a subscriber, the subscribing code first needs access to the EventAggregator service in Prism. This is a singleton service like the RegionManager that you can simply obtain by using dependency injection and importing it through the container. Add the following code to the OrdersViewModel:

   1: public OrdersViewModel()

   2: {

   3:     if (!DesignerProperties.IsInDesignTool)

   4:     {

   5:         CompositionInitializer.SatisfyImports(this);

   6:         EventAggregator.GetEvent().Subscribe(OnCustomerSelected);

   7:         _Context = new CustomersDomainContext();

   8:     }

   9: }

10:

  11: [Import]

  12: public IEventAggregator EventAggregator { get; set; }

Because the view model will be constructed in the XAML of the view, the container will not be involved in its construction. To get the container to satisfy the imports in the class, which in this case includes the event aggregator, the CompositionInitializer class can be used. It is put in a guard condition as discussed in a previous article so that the designer does not break since it should not execute that code in the designer.

After the SatisfyImports call, the Import property will be set by the container. So the next line of code can then use that IEventAggregator reference to subscribe. That involves calling the GetEvent() method to get a reference to the event, then calling subscribe on the returned event, which can be done in a single line of code as shown. The Subscribe method just takes an Action delegate, where T is the payload type defined by the event class. The OnCustomerSelected method was shown earlier.

By default, Prism events maintain weak references to the subscribing class method. That means that if all other references to the object go away, the event reference will not keep it alive. This solves a lot of memory leak issues where you either forget or it is difficult to know where in the code to do the Unsubscribe call. If you want the event subscription to keep the object alive, there is an overload to the Subscribe method with a keepSubscriberReferenceAlive bool parameter.

Additionally, by default the event publication will happen synchronously using the publisher’s thread. If you want control over what thread is used to call the target method pointed to by the Subscribe call, you can use another overload that takes a ThreadOption with three choices: use the Publisher’s thread (the default), use the UI thread, or use a background thread from the thread pool.

Finally, there is an overload that also allows you to pass a Predicate delegate for filtering purposes. This allows you to pass a lambda expression or point to a method that returns a boolean. The method or lambda will be passed the payload object of the event. It can use that to decide whether to return true or false. True means to call the subscription method, false means don’t.

Step 11: Publish the event

To publish a Prism event, it is just as simple as subscribing. you first need a reference to the EventAggregator service, which you get through dependency injection as shown earlier. Then you publish at the appropriate point in your code calling the Publish method on the event returned from the same GetEvent() method shown earlier:

   1: EventAggregator.GetEvent().Publish(_SelectedCustomer);

Summary

In this article, you saw how to define multiple modules that can communicate with each other through a combination of CompositeCommands and Prism events. CompositeCommands let you have handlers registered or unregistered in a loosely coupled fashion, and allows you to have multiple handlers (child commands) that will be used by the CompositeCommand. Prism events are for situations that are not necessarily an action->reaction kind of set up where enablement and disablement is needed. You simply define the event type with its strongly typed payload and then subscribe or publish by obtaining the event reference through the EventAggregator. Both of these mechanisms give you a really powerful combination for having loosely coupled communications between composite parts of your application.

You can download the finished code from this article here.

About the Author

Windows 8 XAML Metro Apps with OData - Part 2

editorial@silverlightshow.net (Samidip Basu ) — Thu, 08 Dec 2011 10:57:00 GMT

So, you have heard the buzz about the brave new world of Windows 8 from MSFT’s BUILD Conference!

Don't miss...

All SilverlightShow Ebooks

May be you even attended the wonderful SilverlightShow webinar about “Getting Started with XAML Development in Windows 8” by Gill Cleeren. Ready to get your hands muddy? In this short 2-part article series, we talk about how to get started towards writing data-driven (specifically OData) Windows 8 Metro apps with XAML & C#. Here’s what we’ll cover:

Part 1 – Handling of OData from our XAML Metro App [Consumption & Updates to OData source]
Part 2 – How to make your XAML App a well-behaved Windows 8 citizen [Artwork, Snapped Views, Contracts, Application Bar etc]

As always, the demo solution, along with all code samples is available for download through the link below:

Download Source Code

Introduction

At the BUILD Conference in August 2011, Microsoft launched Windows 8 .. the next iteration of Windows. It isn’t a forked world between desktop & mobile/tablet Operating Systems; rather “One OS to rule them all..” which runs on variety of form factors with touch-based interaction being a first-class citizen. We could obviously talk a lot about Windows 8; but for the sake of the length of this post, let me refer you to 2 valuable resources:

BUILD Website @ http://www.buildwindows.com/. Great place to start would be the 5 Keynotes, followed by tons of recorded Session content.
Windows 8 Developer Home @ http://msdn.microsoft.com/en-us/windows/home. On this site is a link to download the Windows 8 Developer Preview – the latest Windows 8 bits along with Development tools. Also, as you get into serious Windows 8 Metro development, the samples from Microsoft & contributions from our fabulous community should be very valuable.

In Part 1 of this article series, we talked about how to get started with building a Windows 8 Metro App with XAML/C# and how to consume OData in our application. While we might have a functional data-driven application, we developers should strive to make our native applications feel at home in the target operating system. Windows 8 is Windows re-imagined with Metro UI, and as such, introduces some new paradigms that most Metro applications should adhere by. In this post, we talk about how to ensure our application does not produce a jarring UX for the Windows 8 user; in essence, how to make our application a well-behaved citizen in Window 8.

Prerequisites

To follow along or to try the Demo or build something similar yourself, you need the following:

Windows 8 Developer Preview running “on the metal” on some laptop/tablet.
Alternatively, you could also run Windows 8 in a VM (VirtualBox being the best fit at this time) or off a VHD.
Visual Studio 11 included as a part of Windows 8 Developer Preview. At this point, the templates to build Metro Apps aren’t available outside the Windows 8 bits.
Curiosity

The Application Bar

Remember our UI to show/manipulate our list of Team members? Here it is again:

You’ll notice that the main UI has been kept clean with minimal controls. You can obviously add much much more to utilize the real estate; but the point is, commonly used actions should be tucked away in what’s called the Application Bar at the bottom & also at the top. If you have a touch-enabled tablet or PC, you could get to the Application Bars in any Metro App by swiping a little from the top or bottom of the screen. If using Windows 8 in a traditional mouse/keyboard computer, we need to right-click in the App to bring up the Application Bars.

Please note that these Application Bars are optional – you can add an Application Bar at the bottom, top, both or none, as per your App’s needs. Commonly used App functionality tucked away in Application Bars like this just makes your App sit well with the rest of the Windows 8 OS & utilizes the UX the end-users are already used to.

Quick Trivia – Why do you think the Application Bar buttons are at either end & not at the center ?? The answer lies is some detailed research Microsoft conducted to figure out what portion of the tablet form-factor’s screen is most accessible with thumbs when holding the tablet in both hands. See the point now?

So, let’s take a look at what we had to do to build our Application Bar. The round Metro-looking icons are nothing but regular buttons with click-handlers behind them. Here’s how we add the Application Bars to our MainPage.xaml UI:

"TeamMetro.MainPage"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

mc:Ignorable="d"

d:DesignHeight="768" d:DesignWidth="1366">

  



"LayoutRoot" Background="Chocolate">

  

    // All the other content stuff ..

  

    

    "BottomAppBar" VerticalAlignment="Bottom" Height="100" Opacity=".8" IsPersistent="False" DismissMode="LightDismiss">

        

            

                "*"/>

                "Auto"/>

            

            "0" Orientation="Horizontal" HorizontalAlignment="Left" VerticalAlignment="Center">

                

                

            

            "1" Orientation="Horizontal" HorizontalAlignment="Right" VerticalAlignment="Center">

                

                

            

        

    

  

    "TopAppBar" VerticalAlignment="Top" Height="100" Opacity=".8" IsPersistent="False" DismissMode="LightDismiss">

        "20,0,0,0" VerticalAlignment="Center">

            "topBarText" Text="You can add stuff here as well .." FontSize="26" />

        

    

  

   

  



And here’s the button template defined in our App.xaml as a global resource. You could obviously have one template for all buttons and include any other styles you want re-used. If you overlook the story-board, each Application Bar is essentially an image icon inside an ellipse. Makes sense?

"http://schemas.microsoft.com/winfx/2006/xaml/presentation"

             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 

             x:Class="TeamMetro.App">

  

    

  

        

            

            

  

        

  

    

  



UI Modes

Windows 8, being a hybrid OS supporting multiple form factors, will have enough hardware horsepower to support true multi-tasking even in Metro UI mode.. And the additional real estate offered by tablets form factors means that people should be allowed to run multiple applications side by side. Yes, you can do that, unlike the competition

So, if are running Windows 8, try a few Metro Apps one after another .. and then swipe from left or hover mouse-cursor on left edge. What you should see pop-out is the last running application, which you can drag out onto the viewable area & also dock it. Accordingly, all Windows 8 Metro applications support three UI modes:

FullScreen – This is when the App has the full center-stage & nothing else is in the foreground.
Filled – This happens when a Metro App consumes about 75% of the screen real-estate and another App has been snapped to one side.
Snapped – This is the mode where the App in question is actually the one that has been snapped and has about 25% of screen real estate.

It is important to note that supporting these modes is very highly recommended for Metro Apps, lest you do not care about the UX when users snap your App. So, we have seen how our Demo application looks in full-screen mode; here’s how it would be if another application was snapped to the side:

And here’s how our App would look if snapped:

So, let’s see what one has to do to support this snapping behavior. First up, in our application, we need to notified as when these layout changes happen so we can take appropriate action. So, let’s subscribe, as below:

#region "Constructor"

  

public MainPage()

{

    InitializeComponent();

    

    // Subscribe to Layout changes.

    ApplicationLayout.GetForCurrentView().LayoutChanged += new TypedEventHandler(MainPage_LayoutChanged);

  

    // Other stuff.

}

  

#endregion

Did you notice the ApplicationLayout object? Yeah, we subtly tap into a WinRT namespace called using Windows.UI.ViewManagement and trust the OS to inform us about layout changes in current view.

And here’s how we respond to the change in Layout:

private void MainPage_LayoutChanged(ApplicationLayout sender, ApplicationLayoutChangedEventArgs args)

{

    if (args.Layout == ApplicationLayoutState.Filled || args.Layout == ApplicationLayoutState.FullScreen)

    {

        this.fullMode.Visibility = Windows.UI.Xaml.Visibility.Visible;

        this.snappedMode.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

  

        this.BottomAppBar.Visibility = Windows.UI.Xaml.Visibility.Visible;

        this.topBarText.Text = "You can add stuff here as well ..";

    }

    else if (args.Layout == ApplicationLayoutState.Snapped)

    {

        this.fullMode.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

        this.snappedMode.Visibility = Windows.UI.Xaml.Visibility.Visible;

  

        this.BottomAppBar.Visibility = Windows.UI.Xaml.Visibility.Collapsed;

        this.topBarText.Text = "Snapped Mode:";

    }

}

A few things happened .. so let’s dig in. For my demo application, I am not really limited in real estate in Filled mode .. so I treat that the same as in FullScreen mode. If however the App is snapped, we swap out controls for a more streamlined look. I chose to bind my results to 2 different ListBoxes in the UI that I toggle based on layout .. if you can have one Listbox & adjust through DataTemplates, that is totally desirable. So, here are my UI elements:

"Transparent" VerticalAlignment="Center" x:Name="fullMode">

"fullTeamList" Margin="40" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Transparent">

    

        

            "400,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">

                "ninja.png" Height="75" Width="75"/>

                "{Binding Name}" Margin="10,0,0,0" FontSize="26" VerticalAlignment="Center"/>

                " -- aka " FontSize="22" VerticalAlignment="Center"/>

                "{Binding TwitterHandle}" Margin="10,0,0,0" FontSize="22" VerticalAlignment="Center"/>

            

        

    





  

"Transparent" VerticalAlignment="Center" Width="320" x:Name="snappedMode" Visibility="Collapsed">

    "snappedTeamList" Margin="5" ItemsSource="{Binding WCFTeam}" Foreground="Blue" Background="Chocolate">

        

            

                "10,0,0,40" VerticalAlignment="Center" Orientation="Horizontal">                            

                    "{Binding Name}" Margin="10,0,0,0" FontSize="26"/>

                

            

        

    



So, I chose to only display Team member names in Snapped mode and adjust the Application Bars accordingly. It is totally up to you & your application to decide on what information you want to display in Snapped mode .. I would guess people would go for either minimalistic views for social media type applications or dense views conveying a lot of information for sustained Snapped view usage. The point is this is totally customizable through the XAML UI .. so let’s make the most of it.

Contracts

Windows 8 introduces this concept of Contracts, which can be thought of as System Interfaces. You may also think of them as Let-Us-Not-Reinvent-The-Wheel mechanisms. If your App needs to let the user share something through Social media, why would you write interface code to post to Twitter/Facebook when another application in the system already knows how to do that? This also results in a consistent UX and less clutter in Apps. This concept of Contracts, when expanded to most common tasks, and the powerful WinRT APIs does give the developer a lot of flexibility. While there are lots of Contracts (details found on doing MSDN searches), let’s look at a couple of contracts which should highly recommended for most Metro Apps.

Sharing

The Share contracts enforces a requester-listener pattern .. one application says “I need to share this”, while another says “I know how to do that”. The application which actually implements the Share contract need to know how to receive data from other applications through the OS and share it through whatever medium the application is built to use.

For our demo application, we will not be actually implementing the Share contract; but do the much easier, frequently needed utilization of the Share pattern. What if we need to share some information about our Team members on social media .. can we get away with simply providing the data to share? Yes .. let’s see how.

First, if you need your application to share some information, please please please (3 times’ the charm ) do not add anything inside your App or the Application Bar to enable this. The key is consistency. You see, there are these shortcuts called Charms accessible to Windows 8 users. Set of quick access tasks accessible when touch-enabled user swipes from the right edge of screen or the mouse user hovers at the left lower corner. Here’s what the user sees:

So, what happens when we have a selected Team member selected & which we wish to share, and then we hit the Share Charm. Well, something like this:

What you see is the list of applications that have implemented the Share contracts .. in other words, declared to the OS that they can handle sharing of information from other Apps. Exactly, what we need! Now, let’s try TwitterRama which is a simple Twitter client for Windows 8 built by some very smart MSFT interns. This App clearly knows how to talk/post to Twitter .. so we may not need to integrate with Twitter API directly. Here’s what we get when we try to share through TwitterRama:

Did you notice that our App passed data to TwitterRama? Let’s see how we do that .. first, let us sign up for sharing by allowing the OS interfaces to request data from our application:

using Windows.ApplicationModel.DataTransfer;

  

#region "Constructor"

  

public MainPage()

{

    InitializeComponent();

  

    // Sign up to Share.

    var dataTransferManager = Windows.ApplicationModel.DataTransfer.DataTransferManager.GetForCurrentView();

    dataTransferManager.DataRequested += new TypedEventHandler(dataTransferManager_DataRequested);

}        

  

endregion

Next, when data is actually requested (this happens when the user hits the Share Charm), we get to respond to the event in our application and make up what data element to share. Here’s how:

private void dataTransferManager_DataRequested(DataTransferManager sender, DataRequestedEventArgs args)

{

    if (this.fullTeamList.SelectedItem != null)

    {

        // Set what to share.

        Team selectedMember = (Team)this.fullTeamList.SelectedItem;

        string textToShare = "Selected Team Member: " + selectedMember.TwitterHandle;

        args.Request.Data.Properties.Title = "Team Member Selection";

        args.Request.Data.SetText(textToShare);

    }

}

That’s it .. easy to share, right? You may learn more about the Share contract from this BUILD sessions HERE.

Implementing Contracts

Now, how would we go about actually implementing a Contract? Simple, most common ones are available in the “Add New Item” project wizard, as shown here:

Now, let us say our application has some interesting data/files to search on. So, if we implement the Search contract, the end user may search for our application’s data directly from Windows Search, even if our application is not running. The user gets to see our App in the list for Search & search query parameters get passed directly into our application. Here’s how:

If our application does implement the Search contract, the App Manifest file gets updated with Declarations .. others can be added from the same screen below along with implementation:

So, now when the user searches contextually within your application from Windows Search, your application gets to respond showing a custom Search results view. The basics of this are added as a SearchResultsPage.xaml when we add the Search contract, as displayed below:

And we get to respond to Search queries from the user within our view as follows:

public sealed partial class SearchResultsPage

{

    public SearchResultsPage()

    {

        InitializeComponent();

    }

  

    public void Activate(SearchActivatedEventArgs args)

    {

        var queryText = args.QueryText;

  

        // Application-specific searching logic.

        // Bind Search results to UI.

  

        // Display the results

        this.PreviousContent = Window.Current.Content;

        Window.Current.Content = this;

        Window.Current.Activate();

    }

}

Much more details about the Search contract can be found in this BUILD session recording HERE.

Artwork

Last but possibly the most important – let’s make nice looking Apps, shall we? Let’s take care of the user’s UX and they in turn, would take care of us developers, right? So, just like in Windows Phone, we developers need to put our Designer caps on, since graphics & artwork is of paramount importance. Let us follow Metro design guidelines to make our application feel right at home in Windows 8. Here’s our demo application on start screen:

Here are some things not to miss:

Inviting App logo on Start screen
Inviting & Contextual App logo in App Store, along with great screenshots & description
Branded Splash screen if using one as your App launches
Rich but minimal graphics & backgrounds in App
Maintain consistency
Enable Live Tiles with Push Notifications (topic for another post someday)
Contract implementations through consistent UI to keep inviting your users back into the App
Metro, Metro, Metro

Still waiting .. c’mon let’s get started! Let’s play a part in Windows re-imagined.

Summary

In this 2 part article, we talked about how to get started with Windows 8 Metro Apps with XAML/C# and we went on to consumption/updates of OData from a Windows 8 Metro application. In Part 1, we looked at a few techniques on how to do asynchronous programming in Windows 8 using the new C# 5.0 constructs of Async-Await. In Part 2, we talked about taking the first steps towards making your Metro Apps feel at home in the Windows 8 Operating System.

I would appreciate any comments or concerns or how things could be done better. Thanks for reading & happy coding.

Cheers SilverlightShow!

About the Author

Samidip Basu (@samidip) is a technologist & gadget-lover working as a Manager & Solutions Lead for Sogeti out of the Columbus Unit. Having worked on WP7 since CTP days, he now spends much of his time in spreading the word to discover the full potential of the Windows Phone platform & cloud-based mobile solutions in general. He passionately runs the Central Ohio Windows Phone User Group (http://cowpug.org/), labors in M3 Conf (http://m3conf.com//) organization and can be found with at-least a couple of hobbyist projects at any time. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com/.

Simulating rain in Silverlight Part 4 - Adding sound effects

editorial@silverlightshow.net (Lazar Nikolov ) — Fri, 30 Sep 2011 19:21:00 GMT

This article is compatible with the latest version of Silverlight.

Introduction

More resources...

($9.99)

All SilverlightShow Ebooks

This article is part 4 of my article series, Simulating rain in Silverlight. After I added wind effect in the previous article, now I add some “color” in the whole scene. Besides the sound effect, I also put in some visuals to control the wind speed. You can choose between three different rates that will alter the angle of the rain drops. To better react when changing the speed I had to do some minor changes in the simulation algorithm. You are free to download and play with the code from the link below.

It may seem very unfamiliar to you to have sound in your Silverlight application, but it, actually, is not that hard. Silverlight provides you with tools for handling sounds and videos in code and XAML. How? Just in a few seconds...

First, here is a demo:

View live demo

As you might see, you can choose between three different speeds that affect respectively the angle of the rain. Obviously, the stronger the wind is, the bigger the angle is. In nature, having summer rain with 40 kilometers per hour, results in approximately 10 degrees of inclination of the rain. Respectively, 60 km/h yields 30 degrees and 80 km/h – 60 degrees. Again, it depends on the intensity and rain density, but we can use this rule for orientation marks in our simulation.

You can download the source from the following link:

Download source code

How to add sound in your application?

Rain and wind simulation is not complete without any sound effects.

The MediaElement class is the key. It allows you to play a number of audio and video formats. For a complete list of supported files, read here.

The first thing you need to do is to find (or create the sounds) you are to use. There are a bundle of websites on the net offering free sound effects in any audio format. For example, check these out: http://www.partnersinrhyme.com/soundfx/Weather.shtml and http://www.shockwave-sound.com/.

My rain simulation uses two audio files – one for the rain and one for the wind. You need to add the files in the project and change the build action to Resource to ensure the media file gets copied in the ClientBin folder.

I declare my media elements in the XAML that control the both effects:

<MediaElement x:Name="WindSound"

Source="wind.mp3"

AutoPlay="False">MediaElement>


 
<MediaElement x:Name="RainSound"
                Source="rain.mp3"
                AutoPlay="False">MediaElement>


I set AutoPlay=”False” to prevent the media element from playing as soon as the app starts. I control this on my own:

private void WindSound_MediaOpened(object sender, System.Windows.RoutedEventArgs e)
{
    this.windMarker.Time = TimeSpan.FromMilliseconds(this.WindSound.NaturalDuration.TimeSpan.TotalMilliseconds - 1000);
    this.WindSound.Markers.Add(this.windMarker);
    this.WindSound.Volume = 0.3;
    this.WindSound.Play();
}

To loop the audio, I use markers. Markers are marks in the audio/video that you can jump to when needed. I create a marker one second before the end of the media file and I use it to mark the end of the file and loop the media. The alternative, to handle the media ended event, is not the best choice here since the sound is getting silent and silent in the very end:

private void WindSound_MarkerReached(object sender, TimelineMarkerRoutedEventArgs e)
{
    this.WindSound.Stop();
    this.WindSound.Play();
}

To change the rain angle on the fly, I must abstract the rain in maximum rate. The improvement that I make here is in the way I initialize the rain and all it dependencies. The drop settings are constructed in the rain constructor, so is the slice and the fall distance.
Having all this in mind, we have this method:

public void ChangeAngle(int angle)
{
    int fallDistance = (int)((double)this.Height / Math.Cos(Math.PI * angle / 180));
    this.FallDistance = fallDistance;
    this.Angle = angle;
    this.Slice = (int)(this.Height * Math.Tan(Math.PI * angle / 180));
    this.sliceCoef = (this.FallDistance * Math.Sin(Math.PI * angle / 180)) / this.Width;
    this.DropSettings = new DropSettings(0, fallDistance, Constants.ANIMATION_DURATION);
}

It changes not only the angle, but every aspect of the rain that depends on the angle.
Now, it’s easy to change the wind speed:

// Speed changed handler
private void SpeedSelector_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    this.HideArrows();
 
    switch (this.SpeedSelector.SelectedIndex)
    {
        case 0:
            {   // Light rain
                this.light1.Visibility = this.light2.Visibility = this.light3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.lightAngle);
                this.WindSound.Volume = 0.3;
                break;
            }
        case 1:
            {   // Medium rain
                this.medium1.Visibility = this.medium2.Visibility = this.medium3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.mediumAngle);
                this.WindSound.Volume = 0.6;
                break;
            }
        case 2:
            {   // Rough rain
                this.rough1.Visibility = this.rough2.Visibility = this.rough3.Visibility = System.Windows.Visibility.Visible;
                this.rain.ChangeAngle(this.roughAngle);
                this.WindSound.Volume = 0.9;
                break;
            }
    }
}

Of course, changing the wind speed affects the Volume property of the media file. That’s how you volume up or down an audio.
Conclusion
In this article I add sound effects to my rain simulation. Moreover, I build some visuals to change the wind speed. I strongly encourage you to use MediaElement when dealing with media files. It provides you with all you could need. Or solid base for all you could ever need!
Feel free to ask or comment!



Simulating rain in Silverlight Part 3 - Adding wind effect
editorial@silverlightshow.net (Lazar Nikolov ) — Wed, 28 Sep 2011 11:47:00 GMT

This article is compatible with the latest version of Silverlight.
Introduction
This is the logical continuation of my article "Simulating rain in Silverlight Part 2 - Optimization". 

More resources...

    Free SilverlightShow Webinars 
    Get Started with Silverlight 4 
    'Getting Ready for Microsoft Silverlight Exam 70-506' Ebook 



($9.99)
     All SilverlightShow Ebooks 


In this publication, I will add wind effect to the rain. And why is this wind effect the logical extension of the rain? Obviously, the nature rarely brings us the rain without a wind. Furthermore, it is not that trivial to add the wind effect...

 
Ок, let's take a good look at the phenomenon, just to make sure we have a solid understanding of what we're trying to simulate. Our simulation will assume the wind is constant. This way we avoid the random fluctuations of the rain drops. Why is this? Since Silverlight does not limit you, just experiment with it by yourself. Clear, we have rain drops, constant wind blowing the scene, and that is...just deal with the angle the drops are falling. 

From this point on, I will expect you to have read my previous articles, "Simulating rain in Silverlight" and "Simulating rain in Silverlight Part 2 - Optimization" since I am going to build over them.
Before I begin with the problem, here is a demo:
View live demo - 30 degrees angle
Download source code
What is the problem?
What are we up to now? In the previous articles we have the rain with the falling straight down drops. Now we will alter the angle of the drops to simulate the wind effect. You would say “Okay, that’s easy, just change the angle in the RotateTransform in the algorithm and it’s over”. I wish it was that easy. 
Changing the angle in the transformation does actually resemble the wind effect, but having the scene in the Canvas, we have to slice two portions to keep the picture consistent. First, we have drops from the left of the scene that need to be hidden after reaching the scene border. And then, we have the drops from the right that need to be hidden until reached the scene border.
And,
What is the solution?
Not that hard, actually, I promise. Just simple math...trigonometry. 
We have three types of drops in this simulation. One that falls all its way in the scene. Other that starts in the scene and falls until hits the left border of the scene. And last, the drops that start their way outside the scene and, at some moment, enter the scene until they fall.
We don’t need to pay any special attention to the first type of drops since they just need to have their angle set. It is rather different with the rest of the drops. First, we need to calculate what the point in the scene that distinguishes the first from the second type is. I call this property Slice. Having the height of the scene and the angle you simply use the tangent of the angle. Based on Slice, I need the slice coefficient:

 

this.Slice = ( int )( height * Math.Tan( Math.PI * this.Angle / 180 ) );
this.sliceCoef = ( this.FallDistance * Math.Sin( Math.PI * this.Angle / 180 ) ) / this.Width;

Having this information, it is easy to determine what type is a drop. Of course, the third type is easily distinguishable using the right border of the scene.


int leftMargin = Convert.ToInt32( rand.NextDouble() * ( this.Width + this.Slice ) );
this.sceneDrops[ currentDrop ].Margin = new Thickness( leftMargin, 0, 0, 0 );
double coef = ( double )leftMargin / ( double )this.Width;

The drop is Type 1 if the coefficient is less than the slice coefficient:


if ( coef <= this.sliceCoef )
{
    int newFinalHeight = ( int )( ( leftMargin ) / ( Math.Sin( Math.PI * this.Angle / 180 ) ) );
    this.sceneDrops[ currentDrop ].FallDistance = newFinalHeight;
    this.sceneDrops[ currentDrop ].FallTime =
        TimeSpan.FromMilliseconds( Constants.ANIMATION_DURATION.TotalMilliseconds *
        ( ( double )newFinalHeight / ( double )this.DropSettings.FallDistance ) );
}

To calculate the new length of the fall, that is the fall height, we use trigonometry. Of course, we also must alter the duration of the fall.
Similarly, to calculate the way of Type 3 drops, we use this code:


if ( coef >= 1 )
{
    int newInitialHeight = ( int )( ( double )( leftMargin - this.Width ) / Math.Sin( Math.PI * this.Angle / 180 ) );
    this.sceneDrops[ currentDrop ].FallInitialHeight = newInitialHeight;
    this.sceneDrops[ currentDrop ].FallTime =
        TimeSpan.FromMilliseconds( Constants.ANIMATION_DURATION.TotalMilliseconds *
        ( ( double )( this.FallDistance - newInitialHeight ) / ( double )this.FallDistance ) );
}

And voila! That was the main part of it all. Wasn’t that hard, right?
Conclusion
To summarize, in this article we’ve simulated wind effect applied to the rain effect from my previous article - "Simulating rain in Silverlight Part 2 - Optimization". In my next article, I will add visuals to harness and change the speed of the wind through UI. I will also create sound effects for both wind and rain to “color” the scene. J








Book Review: 101 Windows Phone 7 Apps
editorial@silverlightshow.net (taabello ) — Wed, 07 Sep 2011 15:13:00 GMT

This review is on the book '101 Windows Phone 7 Apps: Volume I: Developing Apps 1-50', and has been submitted by a member of the Windows Phone 7 User Group - a user group supported by SilverlightShow.

We support user groups with books, swag, events promotion, free event passes and others. Contact us to get support for your user group. 

 

Don't miss...

    Article series: Getting ready for Microsoft WP7 Exam 70-599 
    WP7 article series by Andrea Boschin 
    Windows Phone 7 for Silverlight Devs Ebook (also in MOBI and EPUB format): 



($4.99)
     All SilverlightShow Ebooks 

I think 101 windows phone 7 apps is a great book. It’s a great book if you're new to programming with Silverlight or to windows phone 7. It can also serve as a great reference material for intermediate programmers and veterans alike.
The last time I got this excited about a book was when I got head first java, but unlike head first java, 101 windows phone 7 apps doesn't try to take you into deep technicalities of what a class is or what an object is, neither does it try to take you into the technicalities of Silverlight or c# or xaml, but rather takes you straight to the point by building simple and practical windows phone apps, teaching you the design (xaml) and programming (c#) concept of the platform as you go along, though I will add here that it might not be as easy if you are completely new to programming.
This approach of using real life apps to teach means that by the time you get midway through the book, you would have been involved in the building of 25 fairly standard and practical apps and also would have touched on a lot of features and functionalities of the windows phone 7 platform. This would involve both the user interface design and also the code behind.
I think there's no better way to teach sometimes than by example, and in this case we've been offered 50 great examples. The author has managed to write a book that walks you through the code line by line thereby giving you the reader greater understanding of the role of what each line does.
For those of us who are not newbies to windows phone 7, it comes in handy as a reference material. In my case I needed to incorporate a longlistselector or jumplist in my app and found it so easy to just lookup an app in the book that does this.
Though the size of the book might seem daunting initially, don't be scared to have a go at it since its not one massive book that goes on and on about the same thing but rather it contains isolated chapters that treat on functions and features that are enough to build a fully functional standalone app.
I highly recommend his book for beginners, and intermediate programmers alike, and I think even the veterans might find this a great addition to the tech bookshelf.


WP7 for iPhone and Android Developers - MVC and MVVM
editorial@silverlightshow.net (Kevin Hoffman ) — Thu, 01 Sep 2011 13:41:00 GMT

Don't miss...

    Free SilverlightShow Webinars 
    WP7 series by Andrea Boschin 
    The WP7 for iOS and Android series now available as an Ebook:



($2.99)
     All SilverlightShow Ebooks 

So far in this series of articles, we have been taking topics that might be second nature to iOS developers and relating them to the relatively new feature set found in the Windows Phone 7 SDK. Typically this involves talking about a few classes and code samples as they might appear in iOS and then relating them to classes with a similar purpose in the WP7 SDK. 
This article focuses more on a set of design patterns to illustrate that patterns themselves are universal and the code used to implement them is secondary to the pattern and its purpose. In this article we’ll take a look at the Model – View – Controller pattern and a variant of it, the Model-View-ViewModel pattern.
In a typical data-bound user interface you generally have a view composed of controls and these controls are usually bound to some underlying source of data. For example, if you have a customer edit form you might have controls like text fields for editing the customer’s name and address and other types of controls for editing additional customer data. The model in this scenario might be an object called Customer (which could be a regular Objective-C or C# object or it could have been served up by a database access library or an Object-Relational Mapper).
If this were an iOS application you might have created a class called CustomerEditViewController which inherits from UIViewController. The view is actually a view hierarchy composed of controls that allow a user to edit customers. Because iOS doesn’t actually support bindings the way the full desktop version of Cocoa does (or WP7 for that matter) the controller has to do an awful lot of work to react to user input and manually force values into control properties. 
A typical Model-View-Controller interaction looks like the following diagram:

In a bindings-capable environment, the model is bound to the view and the model is loaded and updated by the controller. Additional properties of the view are dealt with by the controller and user interaction events are passed on to the controller for handling.
This works out pretty well in many scenarios and it’s original goal of separating concerns to make our applications easier to maintain and debug is still valid. Unfortunately what happens quite often is that with the MVC pattern we only have a single model. In order to keep bindings working, we end up making changes to the model to accommodate things that only have relevance in the UI. For example, we might add an isSelected property to the Customer class so that we can modify the background color of currently selected customers or, we’ll add a CurrentCustomer object to some other model and use that to help our UI maintain navigational consistency.
In a typical iOS scenario, we might have a UITableViewController subclass. This class is responsible for handing instances of custom view cells to the UI subsystem. It performs the customization of these cells by pulling information from a model. 
What we really need are two different types of models. The first type is a model that represents the actual source of data which will more than likely be some kind of POCO (Plain-Old C# Object) that came from a database, an XML file, a Web Service, or somewhere else. The second type of model is a model whose properties and behaviors are designed specifically to support the view with which the user interacts. This type we call a View Model, and it is part of a variant of the MVC pattern called Model-View-ViewModel.

In a Model-View-ViewModel pattern, we take advantage of the fact that virtually all aspects of our user interface can be controlled via data binding. We wouldn’t really need to add the complexity of this pattern to our iOS applications because we don’t have bindings support but it comes in extremely handy when building large Windows Phone 7 applications.
Notice that this pattern doesn’t actually have a controller – there is no single over-arching all-powerful class that is responsible for coordinating everything. This takes a little getting used to at first, but, once you’ve gotten into the habit of building highly data-bound UIs in Windows Phone 7, the use of MVVM seems like a natural evolution.
As mentioned, MVVM is a pattern, it is a way of doing things and, as such, there is no single right way of doing it. For example, one thing people strive for in MVVM is to have as little code in a view’s code-behind as possible (it’s really not possible to avoid this entirely). If you ask folks building MVVM applications today about code-behind, you will probably start an argument.
One concept that is especially hard for iOS developers to let go of is the idea of the controller. If you find yourself writing code that looks like this:
myControl.Text = myModel.Property;
Then you need to stop right there – this isn’t MVVM. Your view needs to be bound to a view model and the properties of the various controls and sub-controls should all be set via bindings and converters wherever possible. The trick with MVVM is figuring out how your view needs to get instances of view models. You can do this by creating factory methods, or you can use a view model locator, which is a static helper class responsible for doling out instances of view models to views.
Take a look at the following XAML, which illustrates how you might create a single customer view that is bound to a view model object:


   1: "MyApp.CustomerPage"

   2:   ...

   3:   DataContext="{Binding Customer,Source={StaticResource Locator}}">

   4:   ...

   5: 


Basically what we’re saying is that there is a view model object called Customer to which this entire page is bound. This is also a very common practice with MVVM – try and make the binding as wide in scope as possible. It might be hard at first, but try and match your view models directly to pages and user controls. The benefit of having a view model in addition to a data-centric model is that you can have multiple view models for a single model, with each view model tailored specifically for a given control or page.
Inside our App.xaml we can declare a global resource that points to the view model locator:


   1: <Application.Resources>

   2:  <vm:ViewModelLocator x:Key="Locator" />

   3: Application.Resources>


Here “vm” is the namespace prefix of the CLR namespace where we have our view model locator defined. This class really just has public properties on it that allow our XAML to obtain instances of view models. This is also unfamiliar territory for iOS developers and developers who traditionally follow a more MVC style. Instead of having a controller object that knows about the view and knows about the model that is responsible for hooking the two up, the view declares its intent via bindings. In the sample case, the view says that it should be bound to a view model called Customer which can be found on the view model locator class. The view model locator is responsible for instantiating the view model. During this instantiation, the view model also typically has an initialization method which is called directly or indirectly (again, this is a source of difference and debate depending on how you decide to implement your MVVM pattern).
So the flow of control and instantiation might go something like this: Customer View Page –> Locator –> Customer View Model –> Customer Model (database or web service source).
The UI intentionally has absolutely no idea how the bound data is actually persisted on disk (or in the cloud). All it cares about is how the data is represented visually to the user and made available for interaction – this is the job of the view model. Many of the tasks we traditionally keep in controllers, such as responding to user input and manipulating model values, all take place within the view model whenever possible.
At first you might be thinking that MVVM seems a lot more complicated than just having code-behind in your WP7 views that manipulates controls directly, especially when this looks a lot like the code you may have been writing in iOS. For really small applications, this may be true. However, once you start writing applications that have several pages and these pages have multiple controls, different states, and need to respond to when users navigate to and away from those pages and finally when you try and attach an asynchronous data source (such as web services in the cloud) to your application – the small increase in complexity of code is well worth it in the long run.
Bindings is only a small part of MVVM, it is far more than that. Let’s take another very common scenario – navigating between pages. In iOS, you might write code in a method that is invoked when a user selects a row in a table view. Here, you might create an instance of the view controller responsible for the next screen and then pop it into the stack via the navigation controller. If this view controller needs a model in order to prep the UI, the parent controller is often responsible for creating an instance of this model, loading it from some source, and then passing it as a parameter to the child controller.
With MVVM we do things a little differently. A user might tap a button which results in the execution of a Command object that is actually a property of the view model (view models encapsulate both behavior and data!). As a result of this execution, a message might be broadcast indicating that Customer 123 has been selected. The CustomerViewModel class is listening for such a message. When it receives this message, it loads Customer 123 from disk, populates all of its properties accordingly, and then tells the WP7 navigation system to navigate to the CustomerView.xaml page. As you can see, the “concerns” here are even more separate than in MVC – the parent controller doesn’t actually know what happens when someone selects a customer and many proponents of MVVM argue that it shouldn’t. The view model that backs the view that should appear upon selecting a customer is responsible for listening for the event (or events, and this is key to re-usability) that trigger the appearance of that view.
It might seem like a minor detail but if you go back into an application written MVC style a few months after writing it – it could take you a very long time to figure out all of the different paths through an application. If you’re looking at an MVVM view model, then a quick glance at the message subscribers on that model will tell you exactly the list of actions that can cause that view to appear.
In this article I’ve tried to explain the basics of the MVVM pattern and how it differs from the MVC pattern that iOS developers are familiar with. I have deliberately avoided talking about any one MVVM implementation because the decision as to which MVVM library you use (or whether you roll your own) is entirely up to you. 
MVVM isn’t limited to just Windows Phone 7, and there are implementations on just about every platform you can imagine. For Windows Phone 7, the library that I have used most often is MVVM Lite. If you don’t feel like writing your own view model locator classes, your own pub/sub messaging system, and your own command helpers, then using a library like MVVM Lite will save you a lot of time and effort.
At one point, the installation process for MVVM Lite was so cumbersome that many people just wrote their own stuff rather than attempting the install. Recently, they have released an automated installer that makes adopting MVVM Lite much easier. You can find the code for MVVM Lite, the downloader, and related documentation here: http://mvvmlight.codeplex.com/.
In closing, iOS developers are very used to having to manually fetch objects from a data source via a controller and then, using that same controller, instantiate custom views and set view properties and manually build view hierarchies programmatically. Using the MVVM pattern on Windows Phone 7 allows developers to take full advantage of bindings, resource dictionaries, templating, and the flexibility of Xaml-based object hierarchies. As an iOS developer if you ever find yourself writing code like this:
myControl.Text = myModel.TextProperty;
Then you should take a step back and see if the MVVM pattern and possibly an MVVM toolkit might help you.


TIP: Transformations explained
editorial@silverlightshow.net (Andrea Boschin  ) — Fri, 10 Jun 2011 19:26:00 GMT
Placing elements on the page is really simple but many times the six types of shapes available in Silverlight do not suffice to satisfy all the needs. Also often, especially in junction with animations, the need of moving elements on the screen means transforming basic shapes, applying the rules of the simmetry that in Silverlight go under the name of transform. 
Applying a trasform means setting the value of the RenderTransform property that is exposed by every class that implements UIElement. Differently from WPF in Silverlight it is possible to apply transform only during the render phase but unfortunately, the LayoutTransform is missing. This is an important limitation of Silverlight because applying the transform during the Rendering pass implies that, the transformed elements, have already been positioned during the layout pass, so this can lead to unwanted overlapping of shapes. However if you need the Layout Transform (e.g. to present a vertical text) you can rely on the LayoutTransformer that is available into the Silverlight Toolkit.



<Border Width="100" Height="100" Background="Red">

    <Border.RenderTransform>

        <RotateTransform Angle="40" />

    Border.RenderTransform>

Border>



In Silverlight there is 4 types of possible tranform:

    
    Rotation: used to rotate the element around a given point. It is implemented by the class RotateTransform that allows the user to specify an angle in degrees.
    
    
    Translate: used to move an element along the x and y axis of a given amount. The TranslateTransform may seem unuseful since the Canvas layout element appear to allow the same transform but please remember that positioning using Canvas is strongly discouraged
    
    
    Scale: Used to change the size of an element along the x and y axis. Interesting to know that using the ScaleTransform class you can also apply mirror effects using negative values
    
    
    Skew: Used to distort a figure along its axis. SkewTransform allows to bend the shape to which it is applied
    

Obviously it is absolutely possible you have the need of apply more that a transform to an element. To solve this question there are two possible ways to follow. Before the release 4.0 of Silverlight the sole way was using a TransformGroup class that is a transform that can collect multiple other transformations and make a logical sum of them. Blend 3.0 was known to creates a single TransformGroup with an instance for every type of transform also if you are applying a single type. However here is a sample: 



<Border Width="100" Height="100" Background="Red">

    <Border.RenderTransform>

        <TransformGroup>

            <RotateTransform Angle="40" />

            <ScaleTransform ScaleX="2" ScaleY=".5" />

        TransformGroup>

    Border.RenderTransform>

Border>



After the release 4.0 it was added a new type of transform, called CompositeTransform, that is a single class gathering all the properties of the four original transformations. So, Blend 4.0 now creates a single instance of CompositeTransform and it tunes the various properties according with the transformations you applied. Here is how you can convert the previous sample:
 



<Border Width="100" Height="100" Background="Red">

    <Border.RenderTransform>

        <TransformGroup>

            <CompositeTransform Rotation="40" ScaleX="2" ScaleY=".5" />

        TransformGroup>

    Border.RenderTransform>

Border>



It is important, however, to note that the two samples of code, also if the properties have the same values, does not led to the same result. This is because the TransformGroup apply the transformation separated, one following the other in the order of appearance, but the CompositeTransform apply the properties in a sole passage. It is all up to you to know if your expectations are in a way or in the other.
Finally, especially when you are applying a RotationTransform, but really with all the other kind of transform, you may want to define the reference point from which the transformation will be applied. The best is to use the RenderTransformOrigin property that allows you to specify the point using a percentage value. The RenderTransformOrigin can contain two coordinates, expressed with a value from 0 to 1, where 0 means 0%, 0.5 means 50% and obviously 1 means 100%. Many transformations have similar properties that are instead specified with absolute coordinates and this makes them difficult to be used.



<Border Width="100" Height="100" Background="Red" RenderTransformOrigin=".5,.5">

    <Border.RenderTransform>

        <TransformGroup>

            <CompositeTransform Rotation="40" ScaleX="2" ScaleY=".5" />

        TransformGroup>

    Border.RenderTransform>

Border>



Please remember that RenderTransformOrigin is not of type string, but when you specify it in codebehind you have to use the Point class to express the couple of cordinates.


Simulating rain in Silverlight
editorial@silverlightshow.net (Lazar Nikolov ) — Mon, 14 Mar 2011 10:58:00 GMT
This article is compatible with the latest version of Silverlight.


Don't miss...

    Free SilverlightShow Webinars 
    Getting ready for Silverlight Exam 70-506 series 
    ClassifiedCabinet: A Quick Start 
    Pro Business Apps with SL4 book: 

          
           Show more books


Introduction

In this article I will try to simulate rain in Silverlight application that can be programmatically configured to meet your expectations. Although Silverlight at the time being is very CPU consuming, rain effect may be a common challenge for a developer or designer.
I believe that there are many computer graphics techniques, such as Particle system, to simulate realistically processes that involve tiny particles interacting with each other. However, in this article I will show you how to simulate rain with almost no effort with some very simple algorithm.
Here is a little demo and source code of what we will have done at the end in just a few minutes:
View live demo - with a small amount of raindrops to avoid performance issues
Download source code
Also check the second part of this series - "Simulating rain in Silverlight Part 2 - Optimization"!


The idea

Before looking at the algorithm, let me make the main flow clear. As I wrote a few lines above, the designer adjusts programmatically the rain on his own. That is – the height and width of the scene, the interval of falling drops and the amount of drops animated at a time. This all is achieved with a couple of classes that form the rain nature:

    Drop – holds the drop view 
    DropSettings – describes a drop and its settings; currently only the height that the drop pours is implemented; this act as a view-model as I use it to bind in the drop view when animating the motion from top to bottom part of the scene 
    Rain – this is my main object to maintain the rain process; it uses a simple algorithm, I will next describe, to simulate drops falling randomly through scene 



The algorithm

Now it’s time for the algorithm. It, actually, is really very simple one. What determines the average rain? Yes, you are right and this is what I was looking for – direction and intensity.
First, to simulate the rain, we need to perform the algorithm exactly as many times, as we had previously defined to be the amount of drops to fall simultaneously. Furthermore, this should be done exactly as many times as we have specified to be the interval between the raindrops. 
We start with the following:

for (int i = 0; i < this.DropsPerInterval; ++i)
{
}

To distinguish between UI elements in the scene, when constructing the Rain object, a canvas is specified, and this panel is where the rain will be simulated in. Every drop that we create should be a child of this panel.

Drop drop = new Drop(this.DropSettings);
this.Scene.Children.Add(drop);

Next step is to generate the depth in which the drop is shown in the scene. Depth visually controls the scale and further you go deep in the scene, drops become smaller.

double depth = rand.NextDouble();
drop.RenderTransform = new ScaleTransform
{
    ScaleX = depth,
    ScaleY = depth,
};

The direction of the rain affects directly on the angle which drops fall the ground in. In the demo this angle is fixed to be between 0 and 10 degrees clockwise rotation.

double angle = rand.NextDouble() * 10;
drop.LayoutRoot.RenderTransform = new RotateTransform
{
    Angle = angle,
};

So far we had spread the drops randomly in depths and directions between 0 and 10 degrees. To put the finishing touches, we need to randomly scatter the raindrops in the two dimensional perspective of the scene.

drop.Margin = new Thickness(Convert.ToInt32(rand.NextDouble() * this.Width), 0, 0, 0);

This will set gratuitously from 0 to the right most corner the gap between the drop and most left corner.
Finally, the last thing to do is to start the animation.

drop.Animate();


That's it!
Designing the drop
To design the raindrop view I use Expression Blend. Here is the XAML for it (for clarity I have omitted the Data attribute):

<Path Stretch="Fill" Data="..." VerticalAlignment="Stretch" RenderTransformOrigin="0.5,0.5"
    Margin="1.222,-2.518,-4.94,-7.559" UseLayoutRounding="False" >
    <Path.Fill>
        <LinearGradientBrush EndPoint="1.420529961586,0.976535022258759"
            StartPoint="0.331510990858078,0.976535022258759">
            <LinearGradientBrush.RelativeTransform>
                <TransformGroup>
                    <SkewTransform AngleY="0" AngleX="17.4704" CenterY="0.976535" CenterX="0.331511"/>
                    <RotateTransform Angle="-61.3206" CenterY="0.976535" CenterX="0.331511"/>
                TransformGroup>

            LinearGradientBrush.RelativeTransform>

            <GradientStop Color="#FE739EAD"/>
            <GradientStop Color="#FFD3E9F9" Offset="1"/>
        LinearGradientBrush>

    Path.Fill>

Path>


It is nothing more than a path with some gradient brush on it. This results in the following, magnified about 20 times:

To simulate the drop falling I use a storyboard that:

    animates the height the drop is in each moment 
    animate the visibility to collapsed when the desired height is reached, that is the drop has fallen through the whole scene 


<Storyboard x:Name="Pour">
    <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="drop"
Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[3].(TranslateTransform.Y)">
        <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
        <SplineDoubleKeyFrame KeyTime="00:00:00.6" Value="{Binding FallHeight}"/>
    DoubleAnimationUsingKeyFrames>

    <ObjectAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="drop"
Storyboard.TargetProperty="(UIElement.Visibility)">
        <DiscreteObjectKeyFrame KeyTime="00:00:00.6" Value="Collapsed" />
    ObjectAnimationUsingKeyFrames>

Storyboard>


To obtain the scene height I use binding to the DropSettings object that is injected in the constructor when the raindrop is created.


Let’s start raining!

This was all you need to simulate rain. To actually start it you have to call the classes we created in a manner that satisfies our expectations.

DropSettings dropSettings = new DropSettings(300);
Rain rain = new Rain(dropSettings, this.Scene, 40, 3, 400);
rain.Start();



Conclusion

Although Silverlight is still very CPU consuming, in this article I’ve shown you how to use a simple algorithm to simulate rain. For all that we still should not expect miracles when it comes to real time particle simulations. But I hope soon we shall have what we wish to make our application look and behave really realistic.
About the author
Lazar Nikolov is a software developer at CompletIT - the company behind SilverlightShow.net and leader in Silverlight related technologies in Bulgaria. His main interests are focused on Silverlight rich applications and Windows Phone 7 development.
In addition to authoring Silverlight articles (his series on ‘Simulating rain in Silverlight’ became one of the most popular articles on SilverlightShow!), Lazar is involved in the verification of all SilverlightShow articles, making sure that all content is consistent and in-line with the latest Silverlight/WP7 release updates.


A classic memory game: Part 1 - Designing the game
editorial@silverlightshow.net (Levente Mihály ) — Thu, 20 Jan 2011 10:00:00 GMT
This article is compatible with the latest version of Silverlight.

Don't miss...

    XNA for SL developers series 
    Pro Game Design with SL4 book: 

          
             Show more books

This article is Part 1 of “A classic memory game”.
Introduction
My wife has started learning Silverlight and because of my Expression Blend skills are still lacking, we have decided to build the following classic memory game so both of us can learn something new. We kept things simple but we respected basic Silverlight principles. That’s why we used MVVM which might sound an overkill for a simple game but you’ll see that it fits together perfectly. 
Nowadays everything revolves around Windows Phone 7 in the Silverlight world and I am not an exception either. Once I got my phone I quickly ported the game over to WP7 to see that with a few modifications it’s running nicely. 
In this first article I will go around the game’s concepts, designing the controls and the main game-states. In the second article I’ll finish building the game by adding the necessary code and connecting it with the View. The third part will be about porting the Silverlight game to Windows Phone 7.
First things first, here’s the game itself and download link for the source code.

 
Step 0. – creating a new MVVM Light project
For the project we have used my personal favorite and probably the most popular lightweight MVVM framework out there: Laurent  Bugnion’s MVVM Light toolkit. If you haven’t already installed it, you can do it from here: http://www.galasoft.ch/mvvm/installing/manually/
After installing and copying the Blend template in its place, two new ‘New Project’ templates should appear in the Silverlight department:

Of course you can add the MVVM Light toolkit bits later to the project as well, but it is very nice to have a template for an easy start. It’s also important to note that the MVVM Light toolkit is available for Silverlight 3, Silverlight 4, WPF3.5, WPF4 and Windows Phone 7.
Creating a custom ToggleButton Style – the Card
After drawing the different cards, the back of the cards,  and saving them as images, our first step was to create a custom control for the cards. 
In Blend put a Grid in the LayoutRoot and put two Images inside this Grid. One will represent the back of the card, the other will be the front. Right click on the Grid and choose Make into Control..

In the upcoming panel find the ToggleButton control and add the name CardToggleButtonStyle. Select a separate resource file (you may have to create a new one) to define the style in to keep the MainPage.xaml clean.

Delete the ContentPresenter, so you will end up something like this:

Notice the States panel, especially the CheckStates state-group. Every ToggleButton has a checked and unchecked state and we will use these two states to switch between our card’s front and back. So select the Unchecked state and change the front image’s Visibility to Collapsed. Then select the Checked state and do the same with the back image.
Now if you run the application you should be able to switch between the back and front of the card by clicking on it. Let’s add the turning-animation to the switching to make it look better! 
Select the Unchecked state and add a transition to Checked state (1). A good length for the animation is 0.3 secs (2). By selecting the newly created transition we can edit its animation. Forward to 0.2 sec in the timeline, select the front image (3) and click the Record Keyframe button (4). Do this for the back image too (3,4). Set up a 90 degrees Y rotation in the Projection panel for the front image, and a –90 for the back (5). (Don’t worry when Blend automatically overrides the 90 degrees to 89...) Change the Visibility of the images, the front was Collapsed, change it to Visible. The back was Visible, change it to Collapsed (6). Now forward to the 0.3 sec mark and change the front images Y rotation to 0 (7). Now when you press the play button, you should see the card turning from one side to the other.

You’ll have to create the opposite of this animation in the Checked->Unchecked transition.
The cards will be flipped back when a certain time elapsed or a third card is about to turn. That means the logic is responsible for this task not the player. So in the Checked state set the IsHitTestVisible to false. At first I didn’t do this and had this bug where the user could turn back and forth a card without the MoveCounter increasing.
Designing the layout – Creating a WrapListBox
So we have the card control, now we need to place them. The memory game shouts for a WrapPanel, you’ll find that in the Silverlight toolkit. But we wanted a more dynamic solution, having different number of cards for each difficulty. That’s why we used a WrapListBox, a ListBox with WrapPanel’s layout. Here’s how to do it:
Drop a ListBox in the Layout Grid, right click on it and choose Edit Additional Templates –> Edit Layout of Items (ItemsPanel) –> Create Empty..

Give it a name (WrapItemsTemplate) and again place the template in the separate resource dictionary to keep the main xaml clean. The ItemsPanel is responsible for the layout of the ListBox’s items. Here you can override the ListBox’s default layout (which is a StackPanel) and do anything you want. Just check out Bea Stollnitz’s famous solar system example.
We’ll need only a simple WrapPanel now. Delete the default StackPanel and replace it with the WrapPanel (you’ll need the Silverlight toolkit).

Trying it by placing a few Cards inside you’ll see that it doesn’t do exactly what we wanted. The problem is the ScrollViewer.

The quickest solution is to remove it from the ListBox’s template (we wouldn’t want the user to scroll for flipping cards).
Right click on the ListBox, select Edit Template and Edit a Copy.. After giving it a name (MemoryListBoxStyle) and placing it in the separate resource dictionary, move up the ItemsPresenter into the Grid, and delete the unneeded parts: the Border, the ScrollViewer and the ValidationErrorElement. The ItemsPresenter defines where the ItemsPanel (that’s our WrapPanel) is added inside the ListBox template. So we will need just that.

Much better:

Designing the layout – Menu and VisualStates
The game has three main stages: choosing a difficulty (start), playing, score (end). VisualStates are useful not just in (Custom) Control level, but in UserControl level as well. I’ve added three VisualStates to the LayoutRoot after building the menu items.

All the menus are Grids with a rounded Rectangle inside them. The Buttons use a custom style containing a rounded Rectangle and the ContentPresenter. 
The template of the RadioButtons are the ContentPresenter and two Rectangles. One Rectangle behaves as a highlight border, because it doesn’t fill and is visible only when in Checked state.
For the states first we need to add a VisualStateGroup, select the LayoutRoot, switch to the States panel, and add a VisualStateGroup. Now we can add our three states and of course we won’t miss adding transitions as well. The result looks like this:

Note that you can add Easing to transitions (highlighted too) to make a more realistic animation. For example in my case I have an ElasticInOut Easing on the MenuState –> GameState transition.
Switching States using the GoToStateAction behavior
A great and straightforward way to change between states is the GoToStateAction behavior. With this behavior we can easily set up the initial state, the GameState, and the switching from EndState to MenuState. What we can’t do with it, is the switch from GameState to EndState because it’s not trivial, it’s decided by the game logic. So let’s do the trivial ones:
Switch to the Assets panel and find the GoToStateAction behavior in the Behaviors. Put the behavior inside the LayoutRoot and select Loaded for EventName and MenuState for State. Don’t forget to check the UseTransitions box.
  
To switch from MenuState to GameState place another GoToStateAction behavior inside the start button, EventName is Click, StateName is GameState. Put the final behavior inside the new game button to make the switch from EndState to MenuState again (StateName is MenuState).
Summary
In this article we started designing a game, our main tool was Expression Blend. We’ve created a custom control for the Cards, a WrapListBox for laying out them, and we set up the three main states of the game. All of these parts are real, working elements.
In the next part we will put some logic behind the game and connect it with the View, using converters, the CallDatacontextMethodAction behavior and others. We will again rely heavily on Blend.
About the Author
My name is Levente Mihaly. I've entered the .NET world in 2006, and after graduating at Budapest University of Technology (Msc in Computer Science) I started working as a .NET software developer. After meeting technologies like WinForms and ASP.NET, Silverlight quickly became my favourite platform from the early Silverlight 2 beta stages. I was always interested in mobile development and now I'm very happy since with Windows Phone 7 I can easily expand my knowledge to the mobile world. Nowadays beside following Silverlight I'm focusing on WP7 in my free time. I'm also the runner-up of the 2010 Silverlight ecoContest. You can reach me on twitter (@leventemihaly). 

 


Step-by-Step Guide to Silverlight Shape Controls
editorial@silverlightshow.net (Kunal Chowdhury ) — Thu, 30 Sep 2010 11:30:00 GMT
This article is compatible with the latest version of Silverlight.
In my previous post “Introduction to Shapes in Silverlight” I introduced you with various types of Shapes available in Silverlight and informed you that, I will post an article describing each one of them and here it is.
In this article, I am going to describe you about each shapes and the process to add them in our application (whenever you need). This article is for the Beginners, who don’t know much about the shape controls. If you have any suggestions/concerns please use the feedback section to let me know.
Prerequisite
As mentioned in my previous post, you need “Microsoft.Expression.Drawing.dll” assembly to get the new Shape controls in hand to work with. You can get this dll once you install the Expression Blend SDK to your development PC. If you don’t have the Expression Blend, you can easily download it from the Microsoft Expression site.
Apart from this, your development environment should have the following Tools already installed:

    Microsoft Visual Studio 
    Silverlight Tools for Visual Studio 

Introducing the Shape Controls
Once your development environment is ready, you can open the Expression Blend IDE and create a new Silverlight Application Project. I am demonstrating with the help of Expression Blend here, so that, it will be easy for you to understand properly.

Now, once your project has been created by the IDE, open your “Assets” tab and click on the “Shapes” sub section to expand it at the right. In the right pane you will see all the collection of the shapes available in Silverlight 4. 

Lets start describing one by one. We will discuss both from the IDE and the XAML code. It will be helpful for you to understand. 
To work with the Shape controls, you need to add one xmlns namespace in your XAML page:

If you are using the Expression Blend IDE (designer), it will add this xmlns namespace automatically when you add the first shape control in your XAML page.
Arc Control
Let’s start with the Arc control. Earlier to Silverlight 4, how can you create an Arc shape? You have to use one Ellipse and two Rectangle controls to design the shape. You have to crop those controls as a Path control. Need more designing knowledge using the Blend IDE. Just think to create it from the backend code. OMG!!! You have to design the UserControl first as described earlier and the create the instance from the code behind and rotate it as necessary. Let us create a Arc using the Arc shape control. Click on the Arc symbol from the Assets pane and draw it in your designer page. 

This will create the below XAML code:

So easy right? Yes, it is very easy to design. Now, from the Properties panel, you can change any attribute of the shape like “StrokeThickness”, “ArcThickness”, “ArcThicknessUnit”, “StartAngel”, “EndAngel” etc.
Setting the “StrokeThickness” will change the thickness of the Arc. Have look into the following snapshot:

Increasing the “ArcThickness” will change the Arc like this: 

“StartAngel” and “EndAngel” describes the start and end point of the Arc. Here I used zero as the start angel and 90 as the end angel. Hence, it produced 90 degree Arc. If you set StartAngel as zero and EndAngel as 360, it will create a circle for you. The Ring control available in the list produces same code. 

If you want to draw a Pie in your UI, you can use the Pie shape control available in the list. It internally uses the same Arc control having different StartPoint and EndPoint to produce the Pie Shape. Have a look into the following snapshot: 

Setting the StartAngel to 90 and EndAngel to 360 creates the Pie Shape. You can adjust the angels to generate a different pie shape. 
Block Arrow Control
If you want to add some arrows in your application for direction, what will you do if you are using the earlier version of Silverlight? Yes, you have to create an Arrow UserControl properly shaped with other controls like Rectangle and/or Paths. Then based on the direction you had to rotate the control. So Irritating!!!
No need to tense more. Silverlight 4 is there for you. The Expression Blend SDK now has support for Block Arrow controls. There are four types of Block Arrow Control named “Block Arrow Down”, “Block Arrow Left”, “Block Arrow Top” and “Block Arrow Right”. They are not different controls, only changing the enum property will do the trick for you. So, no need to use transform to rotate the control and no need to use four different controls.
From the Assets pane chose any one of the Block Arrow and draw four shapes of the same. Now, from the properties panel, search for the orientation property. Select “Left”, “Right”, “Up” or “Down” from the orientation dropdown based on your requirement. That’s it. It will change the shape accordingly.

There are some other common properties available for the Block Arrow control e.g. ArrowheadAngle and ArrowBodySize. They are responsible for changing the size of the arrow head and arrow body respectively. You can find those properties in the property panel. 

Let’s see the XAML code, which has been generated for our four controls. Here it is: 

As you see, the only change between them is the Orientation property. So, just setting the Enum value you can set the direction of the Block Arrow. 
Callout Control
Before starting with this point think 10 times, if you want to develop a Callout control in earlier version of Silverlight, how would you do this? Any idea? Hmmm… little bit difficult. Some hint is to create a vector image and scale it as per need or use some path controls to create the shape. Not a good idea but this needs some effort from a good designer. Am I right? Yes.
But now Silverlight gives you those controls inbuilt in the runtime. Choice is yours, how do you want to utilize them. Like the Block Arrow, the Callout control also has four different enum types which you have to set based on your requirement.
Here are some example of Callout Controls:

Once you draw a callout control in the XAML designer, in the properties panel you will see a property called “CalloutStyle”. This dropdown has four enum values called “Cloud”, “Oval”, “Rectangle” and “RoundedRectangle”, which ones set will produce the respective shape in your UI.

The property called “AnchorPoint” gives you the option to change the callout start point for the anchor. This displays as (x, y) coordinate value. The default value for the AnchorPoint is (0, 1.5). 
Here is the actual XAML code to produce four different types of callout shapes:

You can easily find out the difference between each callout type.
Ellipse Control
This is not a new control in Silverlight 4. It was part of initial version of Silverlight too. You can find it in the System.Windows.dll assembly. Using Ellipse control, you can draw ellipse and circles.

The above code will produce a circle as shown in the below screenshot:

Setting different height & width, you can create an ellipse for your UI. Not going to discuss more on this control as it’s a common control for all.
Regular Polygon Control
Pentagon, Hexagon, Star and Triangle shape controls use the RegularPolygon internally to generate the said shapes in the UI. The properties called “InnerRadius” and “PointCount” are responsible to generate not only those shapes but other various shapes too. Have a look here:

InnerRadius of 100% and PointCount of 6 produces a Hexagon Shape as shown above. The XAML code for the above shape will look as below:


Inner Radius of 100% and PointCount of 5 generates Pentagon as shown in the above figure.

If you want to create a Star shape, set the InnerRadius to a lower value. Setting InnerRadius to 50% and PointCount to 5 generates a perfect Star shape. 

Want to add a Triangle in your page? Set the PointCount to 3. 3 is the minimum value for the PointCount property of the RegularPolygon shape control. 

You can also generate a circle using the same RegularPolygon shape control. Set the PointCount to 100 and it will create the above shape. Remember that, 100 is the Maximum value for the PointCount property. 

Setting the InnerRadius to 50% and PointCount to 100 will produce the above shape.
Rectangle Control
The Rectangle shape was available in earlier versions too. But, let me describe a bit of it here too. It is available as part of the System.Windows.dll assembly. The default generates a Rectangle shape. But tweaking it with the help of exposed properties, you can generate Rounded Rectangle or even a Circle too.

In the default case, the RadiusX and RadiusY properties will have a value ‘0’ (zero) and hence it generates a pure square/rectangle shape.


Setting those properties higher than zero will render the rectangle with rounded corner. In the above screenshot, it has a value of 20 for both RadiusX & RadiusY. Hence, created a rounded corner. If you set them to a more higher value, it may change to a Circle too.
Line Arrow Control
It’s a new shape control introduced in Silverlight 4. Before going into the deep discussion, think of creating a simple arrow (straight or bendable). To create such kind of arrow will take a good effort from your production development. Now it comes with Silverlight runtime. Tweaking the control by setting proper properties you can make it straight or bended. You can also make it one directional or bi directional. Have a look here:

Here is the XAML code:

Setting the BendAmount to zero will create a straight line for you. You can also change the starting point by changing the StartCorner property of the control.

If you want a fully bended arrow, you can do it by setting the BendAmount property to 1. Remember that, 1 is the highest value for the BendAmount. Have a look into the below screenshot:

There are 5 types of ArrowHead. You can set them as the StartArrow and EndArrow property. See the above figure for more details. In the above example I set the StartArrow as “OvalArrow” and the EndArrow as the default “Arrow”.
End Note
This is all about the new Shape controls. Hope this long article will help you understanding the basics about them. Please note that, all the diagrams were drawn on top of a Grid control and hence had the property Margin set for each one of them. If you are using Canvas, you have to use Height & Width explicitly for the controls.
Don’t forget to share this article link to others who might feel it very useful.
Appreciate your Feedbacks and/or Suggestions to improve this Article.


Using Blend 4's new built-in TransitionEffects in Navigation and MVVM applications
editorial@silverlightshow.net (Levente Mihály ) — Wed, 28 Jul 2010 00:58:00 GMT
This article is compatible with the latest version of Silverlight.
Expression Blend 4 comes with some pretty cool pre-built 
VisualState transition-animations called TransitionEffects. A TransitionEffect is a pixel-based transition from one state to another, in other words it’s a PixelShader that has an animatable Progress property. These effects can be used in various scenarios, they are very developer/designer friendly, and they are an easy way to make your Silverlight application more attractive.
In this article I will show you two situations to use Blend 4’s built-in TransitionEffects: 
- Navigating between pages in Navigation Framework and
- switching between Views in an MVVM (Light Toolkit) scenario.
Here are the two samples with the „Pixelate” and the „Slide In” effects, live demo and source codes:

Source code to MVVM Transition Demo
Live demo for Navigation Transition
Source code to Navigation Transition
VisualState and Transition recap
You probably know VisualStates from Silverlight SDK Controls and from custom Controls. The name of the concept is “Parts and State Model”. This means that every control has Parts (named elements within the Control) and States (and State Groups). Between switching from a state to another we can define transitions. VisualStateManager is the one that handles state-changes.
The States panel first appeared in Blend 2 SP1, in Blend 3 there were the pre-setted Easings for the transition storyboards, and now in the fourth version of Blend there are the TransitionEffects.
Here’s the standard Button’s States-view in Blend 4:
 
It’s good to know that we can use VisualStates and Transitions not just in custom Controls but in UserControls as well.
TransitionEffect in a Navigation Framework Application
To enable one of Blend 4’s new TransitionEffects in a Navigation Framework application, all we need is Blend 4 and zero coding. :)

    If you don’t have an existing navigation application in which you can test, create one using Visual Studio. Create a new project using the Silverlight Navigation Application template. 
    Once you’re application is ready, open it in Blend 4. Open the main page (default is MainPage.xaml). 
    Expand the LayoutRoot and put the ContentBorder in a Grid. You can do this by right clicking on the ContentBorder and selecting Group Into ->Grid. ContentBorder contains the ContentFrame. We will add the transition effect to the newly created grid. 

      
    Luckily ContentFrame exposes both the Navigating and Navigated events. The first one fires before the navigation, the second one after the navigation is made. We will create two states according to these events, a “NavigatingState” and a “NavigatedState”. 

    Select the States panel, and add a VisulStateGroup by clicking on the plus icon. Add two VisualStates to the group. 

      
    Notice the “fx” icon next to the Default Transition. Click on it and from the dropdown select the TransitionEffect you would like to use. Some effects have additional options (for “Slide In” there’s the option for slide direction). 

     
    Next to fx icon you can set an easing and the duration of the transition, mine is 1 second long. 

     
    So now there will be an animation between the two states we created. Next step is to wire up the states. On the Assets panel in the Behaviors, there’s a behavior called GoToStateBehavior. In this Behavior we can connect an event with a state. Just what we need. Expand the “ContentFrame” Border element in the Object and Timeline panel. Drag a GoToStateBehavior to the ContentFrame. Then drag another one. 

     
    Using the Behaviors, we can connect the NavigatingState with the Navigating event and the NavigatedState with the Navigated event. We can do this on the Properties panel of each Behavior. 

     
    After the events are connected with the states, we can run the application and voila, the navigation is animated. 

    Though you may notice that not only the content is animated, but the selected TransitionEffect is applied to the navigation links’ header also. This might be an unwanted side-effect. For a workaround, switch to XAML view, and move the whole VisualStateManager definition just inside the Grid we created in the first step. Something like this:
    
    
     <Grid x:Name="LayoutRoot" Style="{StaticResource LayoutRootGridStyle}">
    
                 
    
      
    
             <Grid Margin="0,0,0,0">
    
                 
    
                 
    
                 <VisualStateManager.CustomVisualStateManager>
    
                     <ei:ExtendedVisualStateManager/>
    
                 VisualStateManager.CustomVisualStateManager>
    
                 <VisualStateManager.VisualStateGroups>
    
                     <VisualStateGroup x:Name="VisualStateGroup">
    
                         <VisualStateGroup.Transitions>
    
                             <VisualTransition GeneratedDuration="0:0:1">
    
                                 <ei:ExtendedVisualStateManager.TransitionEffect>
    
                                     <ee:SlideInTransitionEffect/>
    
                                 ei:ExtendedVisualStateManager.TransitionEffect>
    
                                 <VisualTransition.GeneratedEasingFunction>
    
                                     <CircleEase EasingMode="EaseIn"/>
    
                                 VisualTransition.GeneratedEasingFunction>
    
                             VisualTransition>
    
                         VisualStateGroup.Transitions>
    
                         <VisualState x:Name="NavigatingState"/>
    
                         <VisualState x:Name="NavigatedState"/>
    
                     VisualStateGroup>
    
                 VisualStateManager.VisualStateGroups>    
    
                 
    
                 <Border x:Name="ContentBorder" Style="{StaticResource ContentBorderStyle}" Margin="0">
    
     ...
    
    
    

Now when we run the application again, the TransitionEffect is only applied to content, the header will stay intact.
For the demo I added the “Slide In” effect to the Cosmopolitan Theme Sample. Notice when there are a lot of different controls on a page the transition might not be very smooth. That’s the case in the demo on the SDK Controls and Toolkit Controls page, where the page contains a lot of different controls. Loading all the controls takes long, it’s not the effect itself that is slow. Well, nothing is perfect.
TransitionEffect in an MVVM application
The second sample for using transitions is an MVVM application. Scenario is simple; we have a few Views and a menu. The user can select between the Views, and one is visible at a time. I really like Laurent Bugnion’s MVVM Light Toolkit for its simplicity and efficiency, so I’ll be using that.
We will create a DataTemplate selector ContentControl, and will bind the Content to the selected ViewModel. Let’s create the Views and ViewModels first.

    First, we can start a new application using the MVVM Light (SL4) template. The MainPage.xaml, the MainPageViewModel and the ViewModelLocator will be automatically created. 
    We can add the a few Views and their ViewModels using the MVVM Light Toolkit templates (add new item: MvvmView(SL) and MvvmViewModel (SL)). Let’s call these OneView, TwoView, ThreeView and OneViewModel, TwoViewModel, ThreeViewModel. 

     
    In the ViewModelLocator we must set up properties for the ViewModels. We can do this by using the “mvvmlocatorproperty” snippet. Once this is done for all three ViewModels, we can set up the DataContext bindings in the Views. 

    
    
     DataContext="{Binding OneVM, Source={StaticResource Locator}}"
    
    
    
    
     private static OneViewModel _oneViewModel;
    
      
    
             /// 
    
             /// Gets the OneVM property.
    
             /// 
    
             public static OneViewModel OneVMStatic
    
             {
    
                 get
    
                 {
    
                     if (_oneViewModel == null)
    
                     {
    
                         CreateOneVM();
    
                     }
    
       
    
                     return _oneViewModel;
    
                 }
    
             }
    
      
    
             /// 
    
             /// Gets the OneVM property.
    
             /// 
    
             [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance",
    
                 "CA1822:MarkMembersAsStatic",
    
                 Justification = "This non-static member is needed for data binding purposes.")]
    
             public OneViewModel OneVM
    
             {
    
                 get
    
                 {
    
                     return OneVMStatic;
    
                 }
    
             }
    
       
    
             /// 
    
             /// Provides a deterministic way to delete the OneVM property.
    
             /// 
    
             public static void ClearOneVM()
    
             {
    
                 if (_oneViewModel != null)
    
                 {
    
                     _oneViewModel.Cleanup();
    
                     _oneViewModel = null;
    
                 }
    
             }
    
      
    
             /// 
    
             /// Provides a deterministic way to create the OneVM property.
    
             /// 
    
             public static void CreateOneVM()
    
             {
    
                 if (_oneViewModel == null)
    
                 {
    
                      _oneViewModel = new OneViewModel();
    
                 }
    
             }
    
    
    

The DataTemplate selector
For the DataTemplate selector we must create a custom ContentControl.

    Add a new class (in my case it’s called MvvmDataTemplateSelector) that inherits from ContentControl.
    
    
     public class MvvmDataTemplateSelector : ContentControl
    
         { 
    
             ...
    
         }
    
    
    
    Add a property - type of DataTemplate - for each property.
    
    
     /// 
    
             /// DataTemplate for type OneViewModel
    
             /// 
    
             public DataTemplate OneView { get; set; }
    
     
    
             /// 
    
             /// DataTemplate for type TwoViewModel
    
             /// 
    
             public DataTemplate TwoView { get; set; }
    
       
    
             /// 
    
             /// DataTemplate for type ThreeViewModel
    
             /// 
    
             public DataTemplate ThreeView { get; set; }
    
    
    
    Override the OnContentChanged method. In this method connect the ViewModel with its View, as we will bind the Content to the selected ViewModel.
    
    
     protected override void OnContentChanged(object oldContent, object newContent)
    
             {                        
    
                 // select ContentTemplate for ViewModel
    
                 if (newContent is OneViewModel)
    
                 {
    
                     ContentTemplate = OneView;
    
                 }
    
                 else if (newContent is TwoViewModel)
    
                 {
    
                     ContentTemplate = TwoView;
    
                 }
    
                 else if (newContent is ThreeViewModel)
    
                 {
    
                     ContentTemplate = ThreeView;
    
                 }
    
       
    
                 base.OnContentChanged(oldContent, newContent);            
    
             }
    
    
    
    Set up the MainPage and MainPageViewModel. We can add buttons for each view in the xaml, and in the MainPageViewModel we can add Commands. Each Command will set the SelectedViewModel property to a ViewModel. 
    Finally we can host our Views in the newly created MvvmDataTemplateSelector. Now when we compile and run the application we can switch between the Views.
    
    
     
    
                 <DataTemplate x:Key="oneView">
    
                     <Views:OneView />
    
                 DataTemplate>
    
                 <DataTemplate x:Key="twoView">
    
                     <Views:TwoView />
    
                 DataTemplate>
    
                 <DataTemplate x:Key="threeView">
    
                     <Views:ThreeView />
    
                 DataTemplate>
    
      ...
    
     <Helpers:MvvmDataTemplateSelector
    
                                 Content="{Binding ActiveViewModel}"
    
                                 OneView="{StaticResource oneView}"
    
                                 TwoView="{StaticResource twoView}"
    
                                 ThreeView="{StaticResource threeView}"  
    
                                 HorizontalAlignment="Stretch"                      
    
                                 VerticalAlignment="Stretch"
    
                                 HorizontalContentAlignment="Stretch"
    
                                 VerticalContentAlignment="Stretch"
    
                             />
    
    
    

TransitioningContentControl
The easiest way to add transitions to our application is to use the Silverlight Toolkit’s TransitioningContentControl:


 <toolkit:TransitioningContentControl 

             Grid.Column="1" 

             Content="{Binding ActiveViewModel}" 

             Style="{StaticResource TransitioningContentControlStyle2}" 

             HorizontalContentAlignment="Stretch" 

             VerticalContentAlignment="Stretch">

                 <toolkit:TransitioningContentControl.ContentTemplate>

                     <DataTemplate>

                         <Helpers:MvvmDataTemplateSelector

                              Content="{Binding }"

                              OneView="{StaticResource oneView}"

                              TwoView="{StaticResource twoView}"

                              ThreeView="{StaticResource threeView}"  

                              HorizontalAlignment="Stretch"                      

                              VerticalAlignment="Stretch"

                              HorizontalContentAlignment="Stretch"

                              VerticalContentAlignment="Stretch"

                          />

                      DataTemplate>

                  toolkit:TransitioningContentControl.ContentTemplate>

              toolkit:TransitioningContentControl>  


There’s one drawback, there are only three transition animations built in the Control. Luckily we can help that by editing its template, thus enabling Blend 4’s TransitionEffect.

    Open up Blend, and on the MainPage edit the TransitioningContentControl’s template (right click, edit template, edit a copy.) It will look like this: 

    
    The Control consists of two grids, one for the previous content, and one for the current content, this way enabling a transition between them. Each Transition animation has a State, when you set the TransitionName property, you set one of the upper States. The transition will happen between the Normal state (we cannot delete this) and the selected one. 

    To add a new animation, you can add a new State, and set-up a Storyboard for it. This time though we will enable one of the built-in TransitionEffects, by setting the Default transition just like in the Navigation Framework example.
    
    We can add a new State, or just edit the existing ones. I’ve edited the DefaultTransition: deleted the other States (this step is not necessary), deleted the DefaultTransition Storyboard, and in the State I set the PreviousContentPresetationSite to Collapsed, just like in the Normal state, because we will take care of this in the Default transition. 
    Select the Default transition (the one with the TransitionEffect), and create a Storyboard, where you hide the PreviousContentPresentationSite halfway through the transition. 

    
    At 0:00,000 the PreviousContentPresentationSite is Visible, at 0:00,500 it is Collapsed. The full transition is 1 second long. Of course you can change the timeline, e.g. when you are using a non-linear easing for the TransitionEffect. 

    Here’s the code for the finished VisualStateManager:
    
    
     <VisualStateManager.CustomVisualStateManager>
    
         <ei:ExtendedVisualStateManager/>
    
     VisualStateManager.CustomVisualStateManager>
    
     <VisualStateManager.VisualStateGroups>
    
         <VisualStateGroup x:Name="PresentationStates">
    
             <VisualStateGroup.Transitions>
    
                 <VisualTransition GeneratedDuration="0:0:1">
    
                     <ei:ExtendedVisualStateManager.TransitionEffect>
    
                         <ee:PixelateTransitionEffect/>
    
                     ei:ExtendedVisualStateManager.TransitionEffect>
    
                     <Storyboard>
    
                         <ObjectAnimationUsingKeyFrames 
    
                             Storyboard.TargetProperty="(UIElement.Visibility)" 
    
                             Storyboard.TargetName="PreviousContentPresentationSite">
    
                             <DiscreteObjectKeyFrame KeyTime="0:0:0.5">
    
                                 <DiscreteObjectKeyFrame.Value>
    
                                     <Visibility>CollapsedVisibility>
    
                                 DiscreteObjectKeyFrame.Value>
    
                             DiscreteObjectKeyFrame>
    
                         ObjectAnimationUsingKeyFrames>
    
                     Storyboard>
    
                 VisualTransition>
    
             VisualStateGroup.Transitions>
    
             <VisualState x:Name="DefaultTransition">
    
                 <Storyboard>
    
                     <ObjectAnimationUsingKeyFrames BeginTime="00:00:00" 
    
                                 Storyboard.TargetProperty="(UIElement.Visibility)" 
    
                                 Storyboard.TargetName="PreviousContentPresentationSite">
    
                         <DiscreteObjectKeyFrame KeyTime="00:00:00">
    
                             <DiscreteObjectKeyFrame.Value>
    
                                 <Visibility>CollapsedVisibility>
    
                             DiscreteObjectKeyFrame.Value>
    
                         DiscreteObjectKeyFrame>
    
                     ObjectAnimationUsingKeyFrames>
    
                 Storyboard>
    
             VisualState>
    
             <VisualState x:Name="Normal">
    
                 <Storyboard>
    
                     <ObjectAnimationUsingKeyFrames BeginTime="00:00:00" 
    
                             Storyboard.TargetProperty="(UIElement.Visibility)" 
    
                             Storyboard.TargetName="PreviousContentPresentationSite">
    
                         <DiscreteObjectKeyFrame KeyTime="00:00:00">
    
                             <DiscreteObjectKeyFrame.Value>
    
                                 <Visibility>CollapsedVisibility>
    
                             DiscreteObjectKeyFrame.Value>
    
                         DiscreteObjectKeyFrame>
    
                     ObjectAnimationUsingKeyFrames>
    
                 Storyboard>
    
             VisualState>
    
         VisualStateGroup>
    
     VisualStateManager.VisualStateGroups>
    
    
    

Summary
I hope I could show you in this short tutorial how easy it is to add a transition-animation to your application. The possible scenarios are endless, I’m sure everybody can find his own best way. You can even create custom TransitionEffects if you are familiar with the HLSL language.


WP7: UI Concepts of Windows Phone 7
editorial@silverlightshow.net (Anton Polimenov ) — Tue, 27 Jul 2010 00:07:00 GMT
This is part 4 of the Windows Phone 7 series:

Don't Miss

    WP7 Stock Quoting Demo series 
    See all Windows Phone 7 articles 
    See latest Windows Phone 7 news 


Metro Style
A Windows Phone design system, codenamed Metro is used as a basis for the Windows Phone 7 User Interface. It aims at easily directing end users to the content needed. In order to reach this, its principles focus on a look that uses type to echo the visual language of airport and metro system signage. Harmonious, functional and attractive visual elements are supposed to be realized in Metro interfaces. A good User Interface design should provoke playful exploration when using the application and give users a sense of wonder and excitement. It is highly recommended that developers incorporate Metro design style whenever this is possible. Its clear and straightforward design makes an application legible, while at the same time ecnourages the usage. Based on the application, the requirements may vary, but it still provides a more consistent, fluid User Interface experience from the custom and built-in view.
     
  
User Interface elements should be authentically digital and embody harmonious, functional and attractive visual elements. Applications should grab the attention of users by promoting navigation, exploration, and exciting visuals in their design.This concept is the basis for the five principles of the Metro design:

    Clean, light, open, and fast: It is visually distinctive, contains ample white space, reduces clutter and elevates typography as a key design element. 
    Content, not chrome: It accentuates focus on the content that the user cares most about, making the product simple and approachable for everyone. 
    Integrated hardware and software: Hardware and software blend into each other and create a seamless user experience from single-button access to Search, Start, Back and the camera to on-board sensor integration. 
    World-class motion: The Windows Phone 7 touch and gesture experiences on capacitive screens are consistent with Windows 7 on the desktop and include hardware-accelerated animations and transitions to enhance the user’s experience at every turn. 
    Soulful and alive: A personalized, automatically updated view into the information that matters most to the user is enabled and brings to life a cinematic photo and video experience by having a fully integrated Zune media player experience. 

 
Metro Style Controls
All controls, that come with Windows Phone 7 Development Tools are metro styled. The Panoramic View Control and the Pivot Control are exclusively developed for Windows Phone 7 but they are yet to be available. Nevertheless, while waiting for the official controls, a “temporary solution” has been elaborated. Here is the link to the codeplex project.
Panoramic View Control
 
The Panoramic View Control itself is pretty basic. 
A Title and Background Image dependent properties are implemented within the Panoramic View Control. Just like a tab control, it also derives from ItemsControll. Each individual Item is of type PanoramaItem. You can think of these as visual sections. There is a default Width, provided by the control, which can be used by every section. Shall more space be needed, a custom Width can be specified. For each PanoramaItem should be assigned header and content properties.
Pivot Control

 
The Pivot Control is very close to the Tab Control. It can be compared to the dividers of a notebook. It allows multiple pages to be defined for the same window. Each page consists of a certain type of information or a group of controls that the application displays when the user selects the corresponding tab (Pivot Item). To navigate from one page to another you can either click the page’s Header or simply flick through pages.
 
Other Controls

    Progress Indicator 
    Border 
    Check box 
    Content control 
    Content presenter 
    Grid 
    Hyperlink 
    Image 
    InkPresenter 
    ListBox 
    MediaElement 
    Multi scale image 
    Password box 
    Progress bar 
    Radio button 
    Scroll viewer 
    Slider 
    Stack panel 
    Text block 
    Text box 
    Canvas 
    Push button 

Most of the controls have the same functionality as their corresponding controls in Silverlight.
For more info about these controls read the UI Design and Interaction Guide for Windows Phone 7 v2.0.


Understanding control customization with templates: part #2
editorial@silverlightshow.net (Andrea Boschin  ) — Thu, 15 Jul 2010 11:36:00 GMT
This article is compatible with the latest version of Silverlight.
In the previous part of this article, I've explained the role of templates in Silverlight controls showing how to radically change the appearance of a control without having to change or rewrite its logic. This is an important feature of Silverlight's controls that allow a developer to create an application without concerning about its appearance and leave the designer free of manipulate it without needing to know their intimate logic. Unfortunately there are many times when built-in controls, the SDK and the Toolkit do not contains the control we need for our application. So you have to start writing the control by yourself, and creating a templated control make your work more reusable and customizable for future usages.
Download Source Code
Starting a new control
 The set of controls of Silverlight is very wide and cover a lot of needs, so it is hard to find a missing control to show in this article. The inspiration comes from the new generation phones, which often include controls that are very innovative. I decided to try a port of the Special button switch that you have certainly appreciated by accessing an iPhone.
The figure shows two instances of a control, I will call Switch, one in the Checked state (the red one) and the other in the Unchecked state. You can change the state of the control acting two ways: clicking on the coloured area or dragging the thumb with the chevron in the direction you want. The beautiful of the control is that it shows an animation when you make a change in its state scrolling the thumb from a side to the other. 
The control, as you can figure out, is a sort of ToggleButton, so we should start its building from this class. I choosed of starting from scratch implementing a ContentControl directly for two reasons. First of all I would want to make the example simple and basic, and secondly I noticed there isn't an easy way to implement the behavior I described using VisualStateManager. So let me start writing code:



 public class Switch : ContentControl

 {

     public Switch()

     {

         this.DefaultStyleKey = typeof(Switch);

     }

 }



In this snippet you see two basic concepts. My class inherits from ContentControl because I need to have some content, like a normal ToggleButton. This content is the label on the side or a more complex structure of objects. When you are starting a new control this is the first choice you have to make: Control (or something inheriting from Control) if the control is a leaf in the VisualTree. ContentControl if it can have a content. 
On the other side you can see I given a value to the DefaultStyleKey property. This lets the runtime will search its template in a file we are about to add to the project. The file, called always  generic.xaml, must be in a folder called "Themes" in the root of the project that contains the control. Its purpose is containing the basic templates of all the controls in the assembly. So, Here is the initial generic.xaml



 <ResourceDictionary

     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

     xmlns:local="clr-namespace:SilverlightPlayground.ControlTemplates">

  

     <Style TargetType="local:Switch">

         <Setter Property="Template">

             <Setter.Value>

                 <ControlTemplate TargetType="local:Switch">

                     <Grid>

                         <Grid.ColumnDefinitions>

                             <ColumnDefinition Width="Auto" />

                             <ColumnDefinition Width="*" />

                         Grid.ColumnDefinitions>

                         <Border Grid.Column="1" 

                                 BorderThickness="1" BorderBrush="Black" 

                                 CornerRadius="2" HorizontalAlignment="Stretch">

                             <Grid HorizontalAlignment="Stretch">

                                 <Grid.ColumnDefinitions>

                                     <ColumnDefinition x:Name="OnColumnElement" Width="0*" />

                                     <ColumnDefinition Width="Auto" />

                                     <ColumnDefinition x:Name="OffColumnElement" Width="100*" />

                                 Grid.ColumnDefinitions>

                                 <Rectangle x:Name="OnBackgroundElement" Grid.Column="0" Fill="Red" />

                                 <Rectangle x:Name="OffBackgroundElement" Grid.Column="2" Fill="Green" />

                                 <Rectangle Grid.Column="1" Fill="#FF617584" />

                                 <Thumb x:Name="ThumbElement" Grid.Column="1" Width="40" />

                             Grid>

                         Border>

                         <ContentPresenter Grid.Column="0" VerticalAlignment="Center" HorizontalAlignment="Right" Margin="0,0,5,0" />

                     Grid>

                 ControlTemplate>

             Setter.Value>

         Setter>

     Style>

    

 ResourceDictionary>



This template creates the basic appearance of the control, as you have seen in the previous figure. It misses some important parts, but I will add something else in the following snippets. In the template I have a basic Grid that separates the label from the body of the control. The body is made of another grid with three columns. The size of the first and the last column will be changed to move the thumb from the left to the right or viceversa. In the template I also have a Thumb control, representing an element that can be dragged and a couple of rectangles that give the background color to the visible area. 
Now we need to take some references to the elements we need to use for the animation. They are the Columns, the thumb and the coloured rectangles:



 [TemplatePart(Name = Switch.ThumbElementName, Type = typeof(Thumb))]

 [TemplatePart(Name = Switch.OnColumnElementName, Type = typeof(ColumnDefinition))]

 [TemplatePart(Name = Switch.OffColumnElementName, Type = typeof(ColumnDefinition))]

 [TemplatePart(Name = Switch.OnBackgroundElementName, Type = typeof(Shape))]

 [TemplatePart(Name = Switch.OffBackgroundElementName, Type = typeof(Shape))]

 public class Switch : ContentControl

 {

     private const string ThumbElementName = "ThumbElement";

     public Thumb ThumbElement { get; set; }

   

     private const string OnColumnElementName = "OnColumnElement";

     public ColumnDefinition OnColumnElement { get; set; }

   

     private const string OffColumnElementName = "OffColumnElement";

     public ColumnDefinition OffColumnElement { get; set; }

   

     private const string OnBackgroundElementName = "OnBackgroundElement";

     public Shape OnBackgroundElement { get; set; }

   

     private const string OffBackgroundElementName = "OffBackgroundElement";

     public Shape OffBackgroundElement { get; set; }

      

     public Switch()

     {

         this.DefaultStyleKey = typeof(Switch);

     }

   

     public override void OnApplyTemplate()

     {

         this.ThumbElement = this.GetTemplateChild(Switch.ThumbElementName) as Thumb;

         this.ThrowIfMissing(this.ThumbElement, Switch.ThumbElementName);

         this.OffColumnElement = this.GetTemplateChild(Switch.OffColumnElementName) as ColumnDefinition;

         this.ThrowIfMissing(this.OffColumnElement, Switch.OffColumnElementName);

         this.OnColumnElement = this.GetTemplateChild(Switch.OnColumnElementName) as ColumnDefinition;

         this.ThrowIfMissing(this.OnColumnElement, Switch.OnColumnElementName);

         this.OnBackgroundElement = this.GetTemplateChild(Switch.OnBackgroundElementName) as Shape;

         this.OffBackgroundElement = this.GetTemplateChild(Switch.OffBackgroundElementName) as Shape;

      

         this.UpdateVisualState();

      

         base.OnApplyTemplate();

     }

   

     private void UpdateVisualState()

     {

         // update the control appearance here

     }

      

     private void ThrowIfMissing(DependencyObject element, string name)

     {

         if (element == null)

             throw new Exception(string.Format("Missing required element '{0}'", name));

     }

 }



The OnApplyTemplate method is useful for this purpose. It is called in the initial phase of the life of the control and lets the developer to connect some elements of the control I have called "parts" in the previous article. An element is a "part" when it is attached in the OnApplyTemplate method and it is declared with the TemplatePart attribute at the top of the class. This attribute is not used by the runtime but is useful to external tools to detect the parts for design purpose. 
Many times a part is optional and can be easily removed without causing an error in the control. Some other times it is required. The control has to handle both the cases. When a part is optional the logic have to gracefully skip it when its value is null. When a part is required the better thing to do is raising an exception during the OnApplyTemplate method, as I did in the ThrowIfMissing method. Remember that the more the parts are optional more your control will be customizable. And also when you choose a class to take a reference to a part choose always the closest to the root of the inheritance hierarchy that has all the methods and property you need to make it working.
Finally, UpdateVisualState is the method where the visual appearance of the control is updated every time a property changes its value. The method is useful every time there is something changed and it needs to be reflected into the UI. In my control, this method will starts an animation to move the thumb. This update is needed only when the IsChecked property (a dependency property) is changed and when the control is initialized to make it respectful of the current value of the same property. 
In Silverlight there is not any way to animate a GridLenght property and this is the reason we need to create a custom animation to make the sliding. I create an empty storyboard and I use it as a timer to change the with of the colums, increasing one and decreasing the other. When the thumb has reached its position the animation is stopped:



 private void UpdateVisualState()

 {

     this.SwitchStoryBoard.Begin();

 }

  

 private void SwitchStoryBoard_Completed(object sender, EventArgs e)

 {

     if (!this.IsChecked)

     {

         if (this.OffColumnElement.Width.Value == 100.0)

             this.SwitchStoryBoard.Stop();

         else

         {

             this.OffColumnElement.Width = new GridLength(this.OffColumnElement.Width.Value + 10, GridUnitType.Star);

             this.OnColumnElement.Width = new GridLength(this.OnColumnElement.Width.Value - 10, GridUnitType.Star);

             this.SwitchStoryBoard.Begin();

         }

     }

     else

     {

         if (this.OnColumnElement.Width.Value == 100.0)

             this.SwitchStoryBoard.Stop();

         else

         {

             this.OnColumnElement.Width = new GridLength(this.OnColumnElement.Width.Value + 10, GridUnitType.Star);

             this.OffColumnElement.Width = new GridLength(this.OffColumnElement.Width.Value - 10, GridUnitType.Star);

             this.SwitchStoryBoard.Begin();

         }

     }

 }



Another thing to do, is to bind some properties of the template to the properties of the control. I used the TemplateBinding for the BorderBrush and BorderThickness, then I created two dependency properties in the control, OnBackground e OffBackground, to leave the user free of customizing the colors of the control. I used again the TemplateBinding, same way I did with the other properties. 



 <Style TargetType="local:Switch">

     <Setter Property="BorderThickness" Value="1" />

    <Setter Property="OnBackground" Value="#FFFF0000" />

    <Setter Property="OffBackground" Value="#FF008800" />

     <Setter Property="BorderBrush">

        <Setter.Value>

            <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">

                <GradientStop Color="#FFA3AEB9" Offset="0"/>

                <GradientStop Color="#FF8399A9" Offset="0.375"/>

                <GradientStop Color="#FF718597" Offset="0.375"/>

                <GradientStop Color="#FF617584" Offset="1"/>

            LinearGradientBrush>

          Setter.Value>

     Setter>

     <Setter Property="Template">

         <Setter.Value>

             <ControlTemplate TargetType="local:Switch">

                 <Grid>

                     <Grid.ColumnDefinitions>

                         <ColumnDefinition Width="Auto" />

                         <ColumnDefinition Width="*" />

                     Grid.ColumnDefinitions>

                     <Border Grid.Column="1" 

                             BorderThickness="{TemplateBinding BorderThickness}" 

                             BorderBrush="{TemplateBinding BorderBrush}" 

                             CornerRadius="2" HorizontalAlignment="Stretch">

                         <Grid HorizontalAlignment="Stretch">

                             <Grid.ColumnDefinitions>

                                 <ColumnDefinition x:Name="OnColumnElement" Width="0*" />

                                 <ColumnDefinition Width="Auto" />

                                 <ColumnDefinition x:Name="OffColumnElement" Width="100*" />

                             Grid.ColumnDefinitions>

                             <Rectangle x:Name="OnBackgroundElement" Grid.Column="0" Fill="{TemplateBinding OnBackground}" Opacity="1.0" />

                             <Rectangle x:Name="OffBackgroundElement" Grid.Column="2" Fill="{TemplateBinding OffBackground}" Opacity="1.0" />

                             <Rectangle Grid.Column="1" Fill="#FF617584" />

                             <Thumb x:Name="ThumbElement" Grid.Column="1" Width="40" />

                             <Path x:Name="OffChevron" Grid.Column="1" Data="M-5,-5 L6,3 L-5,11 L3,3 z" 

                                   Fill="#FF617584" Margin="14,4" Stretch="Fill" UseLayoutRounding="False" Opacity="1.0" IsHitTestVisible="False" />

                             <Path x:Name="OnChevron" Grid.Column="1" Data="M6.114583,-5 L-2.25,3 L5.8854165,11 L-5,3 z" 

                                   Fill="#FF617584" Margin="14,4" Stretch="Fill" UseLayoutRounding="False" Opacity="0.0" IsHitTestVisible="False" />

                             <Rectangle x:Name="DisabledVisualElement" Grid.Column="0" Grid.ColumnSpan="3" 

                                        Opacity="0.0" Fill="#eeFFFFFF" IsHitTestVisible="False" />

                             <Rectangle x:Name="ContentFocusVisualElement" Grid.ColumnSpan="3" RadiusX="2" RadiusY="2" 

                                        Stroke="#FF6DBDD1" StrokeThickness="1" Opacity="0" IsHitTestVisible="false" />

                         Grid>

                     Border>

                     <ContentPresenter Grid.Column="0" VerticalAlignment="Center" HorizontalAlignment="Right" Margin="0,0,5,0" />

                 Grid>

             ControlTemplate>

         Setter.Value>

     Setter>

 Style>



Using the Style this way is very comfortable because it lets the developer to define some default values for properties. In the Setter on top of the template I defined some colors, and attributes that the user can change, but they have defaults to prevent unexpected results.
The Visual States
Now that the control works as expected, it is time to make it more customizable. This capability comes from the use of the VisualStateManager that is able to manage some state groups. First of all I added the couple Normal/Disabled but also the Focused and Unfocused status. While the first couple is implemented using a rectangle on top of all the other parts, the Focused status uses another rectangle to create a border around the control. 
Another couple of styles, I've implemented, are Checked/Unchecked. Also if these conditions are showed by the sliding thumb the developer can find useful to have these statuses for the purpose of add some other effects. In my case I added a chevron that switches from left to right. Here is the code for the VisualStateManager:



 <VisualStateManager.VisualStateGroups>

     <VisualStateGroup x:Name="CommonStates">

         <VisualState x:Name="Normal" />

         <VisualState x:Name="Disabled" >

             <Storyboard>

                 <DoubleAnimation Duration="0" To="0.5" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="DisabledVisualElement" />

             Storyboard>

         VisualState>

     VisualStateGroup>

     <VisualStateGroup x:Name="FocusStates">

         <VisualState x:Name="Unfocused" />

         <VisualState x:Name="Focused">

             <Storyboard>

                 <DoubleAnimation Duration="0" To="1.0" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="ContentFocusVisualElement" />

             Storyboard>

         VisualState>

     VisualStateGroup>

     <VisualStateGroup x:Name="CheckStates">

         <VisualState x:Name="Checked">

             <Storyboard>

                 <DoubleAnimation Duration="0" To="0" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="OffChevron"/>

                 <DoubleAnimation Duration="0" To="1" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="OnChevron"/>

             Storyboard>

         VisualState>

         <VisualState x:Name="Unchecked">

             <Storyboard>

                 <DoubleAnimation Duration="0" To="1" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="OffChevron"/>

                 <DoubleAnimation Duration="0" To="0" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="OnChevron"/>

             Storyboard>

         VisualState>

     VisualStateGroup>

 VisualStateManager.VisualStateGroups>



This chunk of code must be inserted in the root element of the ControlTemplate. As you can see, it defines some animations the runtime will show during the transition. The VSM is capable of interpolate all the possible transitions and due to this reason it is possible to not define all the transitions between states. 
Once you have defined the states in the markup into the generic.xaml, you have two final things to do. You have to notify the VisualStateManager about the transitions from a state to another and you have to publish the available states using the TemplateState attribute as you already did with parts and the TemplatePart attribute. Starting by the last, the TemplateState attribute enables the graphics tools to know how many statuses they have to handle. 
But what really matter is setting the state of the control because it enables the VisualStateManager to apply the defined animations and transitions. In an event handler you can simply call the GoToState static method on the VisualStateManager class. Here is and example:



 private void Switch_IsEnabledChanged(object sender, DependencyPropertyChangedEventArgs e)

 {

     this.ThumbElement.IsEnabled = (bool)e.NewValue;

  

     if (this.ThumbElement.IsEnabled != true)

         VisualStateManager.GoToState(this, "Disabled", true);

     else

         VisualStateManager.GoToState(this, "Normal", true);

 }



This code sets the correct state according to the IsEnabled property value. The three arguments of the GoToState method are: 

    
    The UIElement which you have to change the state
    
    
    The destination state as you have called it in the markup
    
    
    A boolean indicating if the transitions must be used or if the change must be immediate
    

Template or not template?
The process of creating a templated control may appear hard, but once you have understood how it works you will find there is not any reason to create controls without a template if they have an UI. Having the basic template expressed as xaml markup makes the development process more simple and straightforward then having to create parts in code. The trick, about control reusability, is to think at them always like behaviors and then add a default appearance, but remember not to close any way to future drastic changes.


Understanding control customization with templates: part #1
editorial@silverlightshow.net (Andrea Boschin  ) — Mon, 12 Jul 2010 02:31:00 GMT
This article is compatible with the latest version of Silverlight.
Every Silverlight developer - and more extensively each Windows developer - knows what I mean with the term "Control". The term is referred to a reusable component that let the developer to add a known behavior to the user interface. The Silverlight plugin, the SDK and the Control's Toolkit have plenty of these controls, and we are used to put them into our application without any fear. Unfortunately, often their appearance is ugly and we may be tempted to change it someway, to give our application a fresh and unique look & feel. With Silverlight there are various degree of personalization you can apply to them, from the simple markup attribute, to an implicit style, but often we need a more deep and drastic revision. In these cases Silverlight grant a unique capability of changing the very inner structure of every control to bend it to our will.
Behavior versus Appearance
 
Given that the middle control in figure is a ToggleButton, what they have in common the three controls? At a superficial exam it may appear that the sole thing they have in common is the text "Select this option...". From an user experience point of view, the meaning they have in an user interface is someway different. But if you analyze them, from a developer perspective, you may agree they are perfectly equals. All the controls infact can be switched on or off and everyone has a label. So, the very important difference is not about the behavior but is about the aspect they have. And If you investigate deeply using Visual Studio you will understand that CheckBox and RadioButton are both inherited from ToggleButton, that is the root of this kind of controls. 
In Silverlight, there is a clear distinction between the behavior and the aspect of every control, at least if the control is developed with a set of rules in mind, that make it a Templated Control. This distinction separates the work of two key figures in the development process: the developer and the designer. Both these figures have different roles in the team and often the requirements of the first are totally opposite to the other's. 
I'm a developer, and when I put a CheckBox in the interface I'm acquiring a behavior to my application. I simply need that someone can choose if the user needs to activate or not an option. Nothing else. At the opposite, when a designer looks at the same interface it does not matter what the control does, but his main concern is its appearance, to make the application not only beautiful, but also more easily understandable and usable.
Templated controls.
In one of the last sentences, I used the term "templated control". First of all you have to know that all the controls in the Silverlight core, in the SDK and in the Control's Toolkit are fundamentally Templated Controls. But what does this mean? 
In every control you can detect some fixed parts, and some other parts that can be changed by the developer. In the CheckBox you have a Content property that let you change the label, but you can customize colors, borders, and many other properties. If you think at the inner structure of a the checkbox, made of simple shapes held toghether by some layout elements, you understand that changing a property of the control means changing one or more property of one or more shapes in this structure. This "structure" is called "ControlTemplate", because of the fact you can think at it as a placeholder for properties you can change and parts you can add. The template appearance will remain the same across different instances of the control but the label can change its content, the border its thickness and so on. Obviously you can create your own Templated Controls, but this is matter for the next part of the article. In this paragraphs you will learn how to customize the template and deeply change the appearance of the existing controls.
Until now I said that every control has a template, but I never tried to explain where this template is located. So, if you watch to the properties of a CheckBox you will easily find a Template property, and this is the location where an instance of ControlTemplate class retain the appearance of the control. Now, please point your browser to Google and type "silverlight control styles and templates" and hit "I'm feeling lucky". The first link of the search probably will take you to this page: http://msdn.microsoft.com/en-us/library/cc278075(VS.95).aspx. Here you can find a complete list of the Controls in Silverlight and a link to a page containig the original template of every control. Hit CheckBox Style and Templates and you will be revealed the whole template behind the CheckBox. Probably something like this:



 <ControlTemplate TargetType="CheckBox">

     <Grid>

         <Grid.ColumnDefinitions>

             <ColumnDefinition Width="16"/>

            <ColumnDefinition Width="*"/>

         Grid.ColumnDefinitions>

         <Grid HorizontalAlignment="Left" VerticalAlignment="Top">

             <Rectangle x:Name="Background" Width="14" Height="14" RadiusX="1" RadiusY="1" Stroke="{TemplateBinding BorderBrush}" StrokeThickness="{TemplateBinding BorderThickness}" Fill="#FFFFFFFF" Margin="1"/>

             <Rectangle x:Name="BackgroundOverlay" Fill="#FFC4DBEE" Opacity="0" Width="14" Height="14" RadiusX="1" RadiusY="1" StrokeThickness="1" Margin="1" Stroke="#00000000"/>

             <Rectangle x:Name="BoxMiddleBackground" Width="10" Height="10" RadiusX="1" RadiusY="1" Fill="{TemplateBinding Background}" Stroke="#00000000" StrokeThickness="1"/>

             <Rectangle x:Name="BoxMiddle" Width="10" Height="10" RadiusX="1" RadiusY="1" StrokeThickness="1" >

                 <Rectangle.Stroke>

                     <LinearGradientBrush EndPoint=".5,1" StartPoint=".5,0">

                         <GradientStop Color="#FFFFFFFF" Offset="1"/>

                         <GradientStop Color="#FFFFFFFF" Offset="0"/>

                         <GradientStop Color="#FFFFFFFF" Offset="0.375"/>

                         <GradientStop Color="#FFFFFFFF" Offset="0.375"/>

                     LinearGradientBrush>

                 Rectangle.Stroke>

                 <Rectangle.Fill>

                     <LinearGradientBrush StartPoint="0.62,0.15" EndPoint="0.64,0.88">

                         <GradientStop Color="#FFFFFFFF" Offset="0.013" />

                         <GradientStop Color="#F9FFFFFF" Offset="0.375" />

                         <GradientStop Color="#EAFFFFFF" Offset="0.603" />

                         <GradientStop Color="#D8FFFFFF" Offset="1" />

                     LinearGradientBrush>

                 Rectangle.Fill>

             Rectangle>

             <Rectangle x:Name="BoxMiddleLine" Width="10" Height="10" RadiusX="1" RadiusY="1" Stroke="{TemplateBinding BorderBrush}" StrokeThickness="1" Opacity=".2"/>

             <Path x:Name="CheckIcon" Margin="1,1,0,1.5" Fill="#FF333333" Stretch="Fill" Opacity="0" Width="10.5" Height="10" Data="M102.03442,598.79645 L105.22962,597.78918 L106.78825,600.42358 C106.78825,600.42358 108.51028,595.74304 110.21724,593.60419 C112.00967,591.35822 114.89314,591.42316 114.89314,591.42316 C114.89314,591.42316 112.67844,593.42645 111.93174,594.44464 C110.7449,596.06293 107.15683,604.13837 107.15683,604.13837 z" FlowDirection="LeftToRight"/>

             <Rectangle x:Name="IndeterminateIcon" Height="2" Fill="#FF333333" Opacity="0" Width="6"/>

             <Rectangle x:Name="DisabledVisualElement" RadiusX="1" RadiusY="1" Width="14" Height="14" Opacity="0" Fill="#FFFFFFFF"/>

             <Rectangle x:Name="ContentFocusVisualElement" RadiusX="2" RadiusY="2" Stroke="#FF6DBDD1" StrokeThickness="1" Opacity="0" IsHitTestVisible="false" Width="16" Height="16" />

  

             <Border x:Name="ValidationErrorElement" Margin="1" BorderThickness="1" CornerRadius="1" BorderBrush="#FFDB000C" Visibility="Collapsed"

                     ToolTipService.PlacementTarget="{Binding RelativeSource={RelativeSource TemplatedParent}}">

                 <ToolTipService.ToolTip>

                     <ToolTip x:Name="validationTooltip" 

                         Template="{StaticResource ValidationToolTipTemplate}"

                         DataContext="{Binding RelativeSource={RelativeSource TemplatedParent}}"

                         Placement="Right" 

                         PlacementTarget="{Binding RelativeSource={RelativeSource TemplatedParent}}">

                         <ToolTip.Triggers>

                             <EventTrigger RoutedEvent="Canvas.Loaded">

                                 <EventTrigger.Actions>

                                     <BeginStoryboard>

                                          <Storyboard>

                                             <ObjectAnimationUsingKeyFrames Storyboard.TargetName="validationTooltip" Storyboard.TargetProperty="IsHitTestVisible">

                                                 <DiscreteObjectKeyFrame KeyTime="0" >

                                                     <DiscreteObjectKeyFrame.Value>

                                                         <sys:Boolean>truesys:Boolean>

                                                     DiscreteObjectKeyFrame.Value>

                                                 DiscreteObjectKeyFrame>

                                             ObjectAnimationUsingKeyFrames>

                                         Storyboard>

                                     BeginStoryboard>

                                 EventTrigger.Actions>

                             EventTrigger>

                         ToolTip.Triggers>

                     ToolTip>

                 ToolTipService.ToolTip>

                 <Grid Width="10" Height="10" HorizontalAlignment="Right" Margin="0,-4,-4,0" VerticalAlignment="Top" Background="Transparent">

                     <Path Margin="0,3,0,0" Data="M 1,0 L5,0 A 2,2 90 0 1 7,2 L7,6 z" Fill="#FFDC000C"/>

                     <Path Margin="0,3,0,0" Data="M 0,0 L2,0 L 7,5 L7,7" Fill="#ffffff"/>

                 Grid>

             Border>

         Grid>

         <ContentPresenter

             Grid.Column="1"

             x:Name="contentPresenter"

             Content="{TemplateBinding Content}"

             ContentTemplate="{TemplateBinding ContentTemplate}"

             HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"

             VerticalAlignment="{TemplateBinding VerticalContentAlignment}"

             Margin="{TemplateBinding Padding}"/>

     Grid>

 ControlTemplate>



In the snippet, I've removed some parts of the template, related to the Visual State Manager, to shorten the code and concentrate our attention on the appearance of the control. If you are experienced in XAML you will understand the anatomy of the control, but the better is oversimplify it and change the control with our own template: Here is a shorter XAML snippet:



 <ControlTemplate>

     <Grid>

        <Grid.ColumnDefinitions>

            <ColumnDefinition Width="20"/>

            <ColumnDefinition Width="*"/>

        Grid.ColumnDefinitions>

        <Rectangle Stroke="#FF666666" StrokeThickness="1" Grid.ColumnSpan="2" RadiusX="2" RadiusY="2" Fill="WhiteSmoke" />

        <Rectangle x:Name="CheckIcon" Fill="Orange" Margin="1,1,0,1"  Stretch="Fill" Opacity="1.0" RadiusX="1" RadiusY="1" />

        <ContentPresenter x:Name="contentPresenter" Grid.Column="1" Margin="3" />

     Grid>

 ControlTemplate>



In the first element I declare a ControlTemplate. This element can be inserted directly into the Template property of the control or better added to a Style that we can apply to multiple controls. The inner content is the root of the template of the control and it is easy to understand the new checkbox will appear as a rectangle with an orange section used as selection indicator. The important part is the ContentPresenter control. This kind of control is useful to indicate where the value of the Content property has to be put. It is a real placeholder that will be filled with the sentence "Select this option..." or with something else you can write in the markup. 
A template may have some "parts", that are particular elements, referenced by the underlying class. The checkbox does not declare any parts, but often there is the need of attaching events to an element so, the developer give it a name, and the element becomes a "part". Watch the page "Slider Styles and Templates" for a real example of some parts. The slider has many parts, and as you can understand they are required to get the user interaction and change the values. 
What you have to be concerned about the parts is that you have never to change its name and its underlying type. The pages of MSDN accurately describe the names and the types of the parts, so if you find a part is declared "Button" you can use only a Button, but if the same part is declared as ButtonBase you can use indifferently a Button or an HyperlinkButton because both derive from ButtonBase.
Once you defined the new appearance of the control there is another need you can have. In my example you may want to change the color and thickness of the border or some other properties without creating different templates for each combination. You probably expect to put the new color in the BorderBrush property of the CheckBox and have the border changed. To allow this you have to create a binding between the property of the control and one or more properties in the template. For this purpose you have to use the TemplateBinding markup extension:



 <ControlTemplate>

     <Grid>

        <Grid.ColumnDefinitions>

           <ColumnDefinition Width="20"/>

            <ColumnDefinition Width="*"/>

        Grid.ColumnDefinitions>

        <Rectangle Stroke="{TemplateBinding BorderBrush}" Fill="{TemplateBinding Background}"

                   Grid.ColumnSpan="2" RadiusX="2" RadiusY="2" />

        <Rectangle x:Name="CheckIcon" Fill="Orange" Margin="1,1,0,1"  Stretch="Fill" Opacity="1.0" RadiusX="1" RadiusY="1" />

         <ContentPresenter x:Name="contentPresenter" Grid.Column="1" Margin="3" />

     Grid>

 ControlTemplate>



The TemplateBinding creates a sort of link between two properties. You only have to be sure both the properties have the same type. Also if this may appear similar to the Binding markup extension, the TemplateBinding is very limited in Silverlight. It has not any Converter property and cannot use anything else the a property name, but it is equally useful to spare time when reusing a template you created.
Managing states
If you run the project after assigning the template I wrote in the previous box you will remain deluded. The new CheckBox has a new appearance but it does not work anymore. It is become a shape on the plugin surface and is unable to react to the user interaction. The problem is that we have not defined what in the control have to change to react at the various states it might assume. With "state" I mean Checked or Unchecked, Hover or Normal, Focused or disabled. Each state changes some properties of the template and gives a feedback to the user. In the page "CheckBox Styles and Templates" you will find a table containing all the states of the CheckBox. They are managed by a component called VisualStateManger that is responsible of maintaining a number of state groups and track the current. You can put an entire section describing how a state must appear and every state is represented by one or more animations. The great thing is that you only have to be concerned about how an animation must change the appearance, and the VSM will interpolate all the transitions to the states. So, let me add a state to my checkbox template:



 <ControlTemplate>

    <Grid>

        <Grid.ColumnDefinitions>

            <ColumnDefinition Width="20"/>

            <ColumnDefinition Width="*"/>

        Grid.ColumnDefinitions>

        <VisualStateManager.VisualStateGroups>

             <VisualStateGroup x:Name="CheckStates">

                 <VisualState x:Name="Checked">

                     <Storyboard>

                         <DoubleAnimation Duration="0" To="1" Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="CheckIcon"/>

                     Storyboard>

                 VisualState>

                 <VisualState x:Name="Unchecked"/>

             VisualStateGroup>

         VisualStateManager.VisualStateGroups>

         <Rectangle Stroke="{TemplateBinding BorderBrush}" Fill="{TemplateBinding Background}"

                    Grid.ColumnSpan="2" RadiusX="2" RadiusY="2" />

         <Rectangle x:Name="CheckIcon" Fill="Orange" Margin="1,1,0,1"  Stretch="Fill" Opacity="0" RadiusX="1" RadiusY="1" />

         <ContentPresenter x:Name="contentPresenter" Grid.Column="1" Margin="3" />

     Grid>

 ControlTemplate>



As you can see I've added an animation, for the Checked state, that animates the Opacity property of the Orange rectangle in the middle of the checkbox . I have not added an animation to the Unchecked state and this mean the VSM will make the transition from Opacity = 1.0 to Opacity = 0.0 when the control move to the uncheked state. If you run the sample you will see the orange rectangle appear when you hit the control.
Good to know but...
What I've described in these rows is for sure very interesting for people that need a deep customization of controls appearance. But probably, you are now concerned about the complex syntax you have to use and learn. The good news is that Blend, since the release 3.0, is your friend when editing templates. When you are developing an application the better is having a tools that supports template editing. Blend is very powerful and let you manage the constituting elements of the templates but also the states in a very simple way. Learning about how to customize the templates manually is really interesting, but it is only the starting point for the next step: build your own templated controls.


A Designer-friendly Approach to MVVM
editorial@silverlightshow.net (András Velvárt ) — Fri, 12 Mar 2010 10:04:00 GMT
This article is compatible with the latest version of Silverlight.



Introduction
If you work with Silverlight or WPF, you have probably met the phrase “MVVM”. Almost everyone who is anyone in the WPF / Silverlight scene has their own MVVM framework, and their own way of explaining and teaching MVVM. Scary terms like IoC, Dependency Injection, Commanding Frameworks, Event Aggregators, Unit Testing, etc just roll off the tongue of the MVVM experts. This is one of the reasons why MVVM is intimidating for a lot of people. Still, you can create perfectly valid MVVM applications without even knowing what those terms mean. This post will show you my approach to MVVM, which is hopefully simple enough to get you started.
So, what is MVVM? There are tons of blog posts on the topic on the net - for example, take a look at John Papa’s 5 Minute Overview of MVVM in Silverlight. I won’t go into details, but here is my very short summary:

    MVVM allows for real separation between logic and presentation (or developer and designer). 
    Model is the data that is displayed in the application. Model is created by a developer. 
    View is the User Interface, that is defined in XAML (mostly). View is the responsibility of a designer. 
    ViewModel is the logic behind the UI, it handles data retrieval and manipulation, follows the state of the application (such as whether the user has logged on or not). The ViewModel is owned by the developer, and is present in the View as the DataContext. 

From our perspective, the interesting part is how the View and the ViewModel are communicating. There are two components to this: databinding (synchronizing data between the View and the ViewModel) and commanding – which is essentially a mechanism that allows the View to notify the ViewModel when user interaction has happened. 
Databinding in Silverlight and WPF is pretty powerful. In my mind, the Zen of WPF and Silverlight development is:
“Get the data to be displayed to the client, and trust databinding and XAML – the designer - to do the rest”.
Similarly, the Zen of WPF and Silverlight design is:
“No matter how you want to display the data for the user, XAML and databinding can probably handle it. Only ask a developer to help you after you have tried really hard.”
On the other hand, I always had a bad taste in the mouth when it comes to the commanding facilities of Silverlight. Commanding has two key features:

    Notify the ViewModel if something (usually a user interaction) happens in the View 
    Disable UI elements when a command is not available (for example, the save button, icons, etc should be disabled if the user does not have the right to modify an item). 

Here is why I don’t like commanding:

    For the designer to be able select a command in Blend, the developer has to create a lot of code – and usually that code simply invokes a method. There is RelayCommand and DelegateCommand to help with this though. 
    The biggest issue I have with commanding is that it really ties the hand of the designer. What if I don’t just want to disable the Save button, I want to change its text to “Login first to Save”? What if I am a crazy designer and want to have all the buttons fly in from outside the screen when the user has logged in and is authorized to press them? 
    Also, the CanExecute approach can be tedious for the developer. For example, after logging in, you have to re-evaluate pretty much all commands, and call CanExecuteChanged for all of them. For complicated tasks, when there are tons of commands, and their executability (is there such a word) is driven by database settings, the built-in approach may be the right one. But for simpler software, this can be overkill. 

The key goals of my MVVM approach
For the project itself:

    Total separation of the designer and developer workflows 
    Shallow learning curve for both the designer and the developer 
    Allowing both the designer and the developer to remain in their comfort zone, and only use the tools they are familiar with 
    Approachable solution for projects with low or medium complexity 

For the designer: 

    As much Blend support as possible (this is not totally achieved yet due to limitations in Blend 3) 
    Use of Visual States to reflect different states of the application 
    High level of flexibility 
    Almost everything can be done in Blend and XAML 
    Shallow learning curve: there is only an Action and a Behavior to learn about 
    Create modern UI, including animations, transitions, custom skins, etc. 

For the developer:

    Focus only on coding 
    Display logic (ViewModel) code is unit testable, including user actions 
    Application states can be expressed naturally, via enum values 
    Ability to include techniques from other MVVM approaches, such as the MVVM Light Toolkit 

So, what do I do instead of commanding?
I use an Action and a Behavior. The Action is for calling methods in the DataContext (that is, the ViewModel). It works similar to the CallDataMethod Action in the Expression Blend Samples project.
The CallDataContextMethodAction
In the attached sample project, there is a TextBox and a Button to illustrate the basic functionality of the CallDataContextMethodAction. The TextBlock is bound to the Message property of the ViewModel, and the Button has the CallDataContextMethodAction applied to it, with the method name set to ShowMsgBox.
 
Here is the relevant part of the ViewModel (which is set to be the DataContext of the entire form):

 public string Message { get; set; }
  
 public void ShowMsgBox()
 {
       if (Message == null)
             MessageBox.Show("Enter something in the textbox");
       else
             MessageBox.Show(Message);
 }

Here is our Action in Blend:
 
If the Button is pressed, a MessageBox is shown, with the text entered into the TextBox:
 
Note: You shouldn’t show a MessageBox from a ViewModel because the designer has no way of modifying what it looks like and how it behaves. However, this is just a test application, and the message boxes are only here to illustrate that the ViewModel actually received the call
So far, it is pretty trivial. What is new in the CallDataContextMethodAction is that it can handle collections pretty well, too. As Glenn Block said in his excellent article The spirit of MVVM (ViewModel), it’s not a code counting exercise, you usually do not need to have parameters for commands. But there are some circumstances when you cannot avoid parameters, Consider the “Greetings to” list in the above picture. We want to display a greeting message for the person the user has clicked on. If the names are displayed in a ListBox, you can bind the SelectedItem property of the ListBox to a ViewModel property, and call the GreetPerson method by capturing the SelectionChanged event (there is a pretty handy EventTrigger built into Blend to help you with this). But then clicking on the same name again won’t fire the SelectionChanged event one more time. Also, what if the designer uses an ItemsControl instead of a ListBox? What if we want to greet the person not by clicking, but by doing some other, non-selective gesture? In this case, we have to have the GreetPerson method either on the person’s ViewModel, or some way to let the main ViewModel know which person we need to greet.
Here is the relevant code in the ViewModel (note that there is no SelectedItem as the names are displayed in a simple ItemsControl):

 public MyViewModel()
 {
     Names = new ObservableCollection<string> {"John", "Smith", "Toby", "Emily"};
     SG1 = PanelState.On;
 }
  
 public void GreetPerson(string name)
 {
     MessageBox.Show("Hello, " + name);
 }


The Action is now attached to the ItemTemplate:
 
But the items displayed in the ItemsControl are strings, and therefore the DataContext of the TextBlock is also a string. And a string does not have a GreetPerson method, so how does the Action work in this case? When the Action cannot find a method in the DataContext of the AssociatedObject (the element the Action is attached to, in our case, the TextBlock displaying the name), it tries to find the same method in the parent of the AssociatedObject, and its parent and so on. If such a method is found in the parent, it passes the DataContext (ViewModel) of the AssociatedObject to the parent method. By traveling up the VisualTree, we get to the MainPage, where the DataContext is the MyViewModel class shown above. This class has a GreetPerson method, so that method gets called. The GreetPerson method also has a parameter of string – this will be the DataContext of the TextBlock, thus the name of the person to be greeted. Note, that with CallDataContextMethodAction, we could use a strongly typed parameter for the method, unlike in the case of Commands where the parameter has to be an object.
The big drawback of the CallDataContectMethodAction is that the name of the Method has to be typed in by the designer, thus it introduces the possibility of human error. Hopefully, we will be able to extend the design time experience later on, so that the developer can simply select the Method from a list instead of typing its name.
The VSMChangerBehavior
The other piece of the puzzle is the VSMChangerBehavior. It ties enum values in the ViewModel to Visual States in the View. As VisualStateGroups are orthogonal (meaning each group can be in any state regardless of what states the others are in), this is a very powerful means of visually reflecting the internal states the ViewModel is in. Here is an example:
Suppose we have two panels that we want to show depending on various ViewModel calculations. We have an enum type of PanelState:
public enum PanelState { Off, On }


And here are the two enums:

 [VisualStateGroup]
 public PanelState Panel1
 {
     get { return _panel1; }
     set
     {
         _panel1 = value;
         FirePropertyChanged("Panel1");
     }
 }
   
 [VisualStateGroup]
 public PanelState Panel2
 {
     get { return _panel2; }
     set
     {
         _panel2 = value;
         FirePropertyChanged("Panel2");
     }
 }

For both panels (Panel1 and Panel2) we have their own properties of type PanelState, that fire the PropertyChanged event when set. However, we are using the [VisualStateGroup] attribute to mark these enums as ones that have (or should have) a VisualStateGroup counterpart. Here is what the visual states look in Blend:
 
As you can see, we have a VisualStateGroup for each PanelState property, The states themselves are called Panel1_On, Panel1_Off, Panel2_On, Panel2_Off. These state names are calculated by concatenating the enum property’s name (which has the VisualStateGroup attribute), an underscore and the name of the enum value:
_. 
After this has been set up, all we have to do is to add the VSMChanger behavior to the Control that has the states we would like to change from the ViewModel:
 
From this point on, the behavior automatically changes the visual state of the UserControl as the enum values change within the ViewModel. This even includes state changes where the change is animated, as in the case in this simple demo. However, when the state transition is not instantaneous, the developer of the ViewModel may want to be notified when the transition has finished. For this, VSMChangerBehavior includes a callback mechanism. Simply name your callback method TransitionComplete, and the method gets called when the transition has finished. For example, to show a MessageBox whenever Panel2 has been completely shown or hidden, have this in the ViewModel:

 public void Panel2TransitionComplete()
 {
     MessageBox.Show("Panel2 Transition complete");
 }


There is one big problem with this behavior, though. Just like in the case of the CallDataContextmethodAction, the designer has to type in the names of the visual states groups and states. As we are wiring up things based on convention, If he/she makes a mistake, the state change will not happen. To help ease this pain, I have added a “VerboseInitialization” property to the behavior.
If it is on, the behavior will write detailed information to the output stream (unfortunately this stream can only be viewed from Visual Studio):
 
This should help debugging typos and missing states / groups until I figure out how to bend Blend to my will add add a proper designer experience for this behavior.

Summary
So, there you have it. A designer-friendly way to wire up the View and the ViewModel. User gestures can be turned into commands via the CallDataContextMethodAction, and internal states and state changes of the ViewModel can be easily reflected via the VSMChangerBehavior. The later can also be used to disable / enable / hide UI elements in a declarative way that gives much more freedom to the designer than the CanExecute approach. Please let me know what you think in the comments! 
You can download the solution with code here. You are free to do whatever you want with it, except say it is yours :)


Transforming an Ugly Duckling into a Graceful Swan With Expression Blend and Silverlight - Part 2 Intro Animation
editorial@silverlightshow.net (András Velvárt ) — Fri, 05 Mar 2010 08:18:00 GMT
This is part 2 of the series “Transforming an Ugly Duckling to a Graceful Swan with Expression Blend and Silverlight”.
Introduction
In the first part of the series, I introduced the application, and created the “ugly duckling” version, where the end user could already browse the and watch the videos. In this part, I am going to add some bling to the app – namely the Intro animation, the ability to skip it, and to replay it. The Intro animation itself is not created with Silverlight, so I will just use it as a video. This part takes heavy use of Visual States, Behaviors and Easings. 


Visual States
The application builds on Sample Data for displaying the videos’ metadata, and it uses Visual States to differentiate between the states of the application. For example, Visual States are used to show the intro animation, the details (in a later screencast), buffering states, some mouseover effects, and so on.
Behaviors
Expression Blend 3 introduced the concept of Behaviors, Actions and Triggers (commonly called Behaviors). Behaviors are a way to empower designers to add functionality to the application without the need to write code. Of course, Behaviors are actually code written by developers, but they can be reused from project to project, and they can have parameters that help designers fine tune the behavior of Behaviors, and increase reusability. 
In this part (and the entire project in fact), I am using quite a lot of behaviors. The ones used in this screencast are:

    GotoStateAction – Built into Blend, this Action makes the target user control to a specified Visual State. In the screencast it is used to get the application to start up in the "PlayingIntro” state, switch back to the PostIntroUIState, skip the intro and when the mouse is hovered over the “Replay intro” cube. 
    Rick Keeney’s EndCueTrigger to trigger a state change 2 seconds before the intro animation ends 
    MediaElementStateToVSMBehavior – This behavior can be attached to a MediaElement, and as the playback state of the MediaElement changes (for example, there are states like “Opening”, “Playing”, “Buffering”, the behavior sets the Visual States for a Control as the designer specified. In the project, we are using this behavior to show and hide the media playback status displays. 
    DisplayMediaStatusBehavior – Again, a behavior that can be attached to a MediaElement that can translate the Playing, Buffering, etc states into text and display it in a TextBlock. 
    MouseOverOpacityBehavior – when applied to a FrameworkElement, the opacity of the element changes when the mouse is over the element. Designers can specify the transition time and the values for the opacity when the mouse is over the element and when it is not. Used on the skip button to light it up and emphasize the interactive nature of the button. 

Easings
Easings are used to make animations more natural by having a gradual start and stop for the movements on the screen.


The glow effect
Silverlight does not have a Glow BitmapEffect, but with some change to the parameters of the drop shadow effect, it can actually be used as a glow effect. 
Screencast contents
Watch the screencast.
Here is what happens in the screencast:

    
        
            Time
            Content
        
        
            @ 0:00
            Introduction and showing off what we are building in this screencast
        
        
            @ 1:40
            Adding the intro animation – preparation
        
        
            @ 2:40
            Adding the intro animation - MediaElement
        
        
            @ 3:47
            Visual State for playing the intro and transition between PlayingIntro and ShowingUIAfterIntro states
        
        
            @ 4:57
            Make the App start up in the PlayingIntro state
        
        
            @ 6:07
            Adding the EndCueTrigger
        
        
            @ 9:40
            Adding the playback status display
        
        
            @ 12:50
            Adding IntroStatusVisible and IntroStatusHidden states and transitions
        
        
            @ 14:38
            Creating the MediaElementStateToVSMBehavior
        
        
            @ 16:18
            Using the MediaElementStateToVSMBehavior to show and hide the video status display
        
        
            @ 19:08
            Creating the DisplayMediaStatusBehavior
        
        
            @ 21:00
            Using the DisplayMediaStatusBehavior to set the text for the video status display
        
        
            @ 22:30
            Adding the skip intro button
        
        
            @ 24:30
            Adding a glow effect to the skip intro button
        
        
            @ 25:50
            Creating MouseOverOpacityBehavior
        
        
            @ 28:14
            Applying the MouseOverOpacityBehavior to the skip intro button
        
        
            @ 29:35
            Making the skip intro button skip the intro
        
        
            @ 31:30
            Replay Intro – creating the highlight on the box
        
        
            @ 33:20
            Creating ReplayIntroVisible and ReplayIntroHidden states and transitions
        
        
            @ 38:10
            Adding some code to the skip intro and replay intro features
        
        
            @ 41:30
            Summing up
        
    

Thank you for watching and good-bye until the next episode!
Download Solution


Transforming an Ugly Duckling to a Graceful Swan with Expression Blend and Silverlight - Part I
editorial@silverlightshow.net (András Velvárt ) — Thu, 11 Feb 2010 09:58:00 GMT
This is part 1 of the series “Transforming an Ugly Duckling to a Graceful Swan with Expression Blend and Silverlight”.
Introduction
As I promised earlier on Silverlight Show, this screencast series will show how to create the showcase application shown on www.response.hu (you may want to read the interview to get some background information on the project). The screencast series shows a real life example of how designers can add value to a project, and how a developer can support this effort by creating small, reusable behaviors that allow the designer to tweak things to shape the end result to be exactly as he wanted it. 
The series is broken into four screencasts. In the first one, I will create the “ugly duckling” version of the application. The next one will add the Intro animation, related functionality and Blend behaviors. The third part will show how to style and animate the video list, and the last part will add the details view with the 3D transition effect.
During the series, I will introduce some important concepts of working with Expression Blend on Silverlight applications. These concepts include:

    Working with Sample Data 
    Creating a master-detail view 
    Creating and using Behaviors and Actions 
    Playing videos, displaying playback status information 
    Using Visual States to add interactivity 
    Customizing the look and behavior of a ListBox through ItemTemplate, ItemContainerStyle, ItemsPanelTemplate and ControlTemplate 
    Extracting style to a resource 

Screencast #1 – The Ugly Duckling
Note: I recommend watching the screencast in full screen.
Watch the screencast
The first screencast shows how to create the ugly version that I am going to work from in the later parts of the series. The ugly version lists all the videos (or ReferenceItems), and allows the user to see the explanation and play back the showcase videos.
The videos (or ReferenceItems) have a title, a thumbnail picture, a description, a video URL and a link where additional information can be read. The application uses Expression Blend’s Sample Data feature to populate the data source that contains the videos and the associated data. After creating the data source,  I show how the thumbnails can be displayed in a ListBox, and how a master-detail view can be created in Blend using Element-to-Element databinding. As the first screencast is finished, the reference items are listed as thumbnails and the details of the selected video can be read, and the video can be played back.
Here is what happens in the screencast:

    
        
            Time
            Content
        
        
            @ 0:00
            Introduction and showing off the finished application
        
        
            @ 1:59
            Creating the application in Blend
        
        
            @ 2:50
            Using Blend’s Sample Data feature to store the data for the video
        
        
            @ 6:58
            Displaying the sample data in a ListBox
        
        
            @ 8:37
            Creating the Details view with title, description, video and the more information link
        
        
            @ 13:33
            Running the project for the first time, master-detail scenario works
        
        
            @ 14:39
            Importing the videos into the project
        
        
            @ 15:42
            Importing the thumbnail images to the project
        
        
            @ 16:20
            Replacing the sample data with real data
        
        
            @ 17:20
            Running the Ugly Duckling application with the real data
        
        
            @ 19:10
            Wrapping up
        
    

I hope you found this screencast useful. Feel free to grab the attached source code. You may reuse the source code in any way you see fit. I have also provided the sample videos and thumbnails in the project, but the images and videos in the attached solution may only be used to follow the tutorial and to run the project as they represent the work of Response, and contain trademarks and logos from Response and its clients.
Please let me know in the comments if you like the screencast format, if it is too fast or too slow, and generally any opinion you may have about the screencast!
Download solution


Implicit Styles in Silverlight
editorial@silverlightshow.net (Pencho Popadiyn ) — Tue, 24 Nov 2009 07:14:00 GMT

This article is compatible with the latest version of Silverlight.





Introduction
Only three months after the release of the latest official version of Silverlight 3, a new beta version – Silverlight 4 is already a fact. There are a lot of new things, which deserve to be mentioned, such as Rich Text, drop target, webcam, microphone, etc. Check out the official Silverlight site for more information. However, in this article I decided to show you one very interesting feature, which is taken from WPF, namely it is the implicit styles feature.

What was the situation till now? Whenever you’ve created a style  in Silverlight, you were obligated to specify the TargetType as well as an unique Key/Name for the style. You should also explicitly set the Style property of the desired element.


<Style x:Key="ButtonStyle" TargetType="Button">

    <Setter Property="Background" Value="Red"/>

    <Setter Property="Foreground" Value="Black"/>

    <Setter Property="FontSize" Value="16"/>

    <Setter Property="Height" Value="55"/>

    <Setter Property="Width" Value="140"/>

    <Setter Property="Margin" Value="8"/>

    <Setter Property="RenderTransformOrigin" Value="0.5,0.5"/>

    <Setter Property="RenderTransform">

        <Setter.Value>

            <RotateTransform Angle="-15"/>

        Setter.Value>

    Setter>

Style>

.................

<StackPanel>

    <Button x:Name="button1" Content="First Button" Style="{StaticResource ButtonStyle}"/>

    <Button x:Name="button2" Content="Second Button" Style="{StaticResource ButtonStyle}"/>

StackPanel>


This is also known as a named style.
 

But not any more! Silverlight 4 gives you the ability to create implicit styles.
Creating Implicit Styles
If you omit the Style’s Key and specify only the TargetType, then the Style is automatically applied to all elements of that target type within the same scope (it is implicitly applied). This is typically called a typed style as opposed to a named style, which is the only kind of Style we’ve seen so far.

The following example demonstrates you how to create an implicit style, which will be applied to all Buttons in the Application scope.


<Style TargetType="Button">

    <Setter Property="Background" Value="Red"/>

    <Setter Property="Foreground" Value="Black"/>

    <Setter Property="FontSize" Value="16"/>

    <Setter Property="Height" Value="55"/>

    <Setter Property="Width" Value="140"/>

    <Setter Property="Margin" Value="8"/>

    <Setter Property="RenderTransformOrigin" Value="0.5,0.5"/>

    <Setter Property="RenderTransform">

        <Setter.Value>

            <RotateTransform Angle="-15"/>

        Setter.Value>

    Setter>

Style>

.............

<StackPanel>

    <Button x:Name="button1" Content="First Button"/>

    <Button x:Name="button2" Content="Second Button"/>

StackPanel>


 Note, you shouldn't specify the Button's Style property.
 
In such an application, all Buttons get this style by default. But each Button can still override its appearance by explicitly setting a different Style or explicitly setting properties.


<Button x:Name="button2" Content="Second Button" Background="Green"/>


 
Also, any Button can restore its default Style by setting its Style property to null.


<Button x:Name="button2" Content="Second Button" Style="{x:Null}"/>







The Target Element Must Match Exactly the TargetType
Note, that the TargetType must match exactly for a typed style to be applied. For example, if you specify the Style’s Key, then it’s ok for the target element to be a subclass of the TargetType. But a typed style typically gets applied to elements which type matches exactly! This is done to prevent surprises. For example, you might have created a Style for all ToggleButtons in your application and you don’t want this style to be applied to any CheckBoxes (which derives from the ToggleButton).

Where is the Key for the Keyless Resource?
So far so good, but you may wonder how it is possible a Style to get away with being a member of a ResourceDictionary without having a key. It actually does have a key – it’s just set implicitly. And the implicit key is simply the value of the TargetType (at least this is the situation in WPF, probably it is also true for Silverlight!?!).
Implicit Styles and BasedOn
If you have multiple implicit styles relating to a particular control, then they do not magically combine. For example, if you have the following two styles:


<Style TargetType="Button">

    <Setter Property="FontSize" Value="16"/>

Style>

 

<Style TargetType="Button">

    <Setter Property="Background" Value="Red"/>

    <Setter Property="Foreground" Value="Black"/>

Style>


they won’t get combined. Something more - this will result in a run-time error. However, implicit styles can still use BasedOn. After the refactoring of the previous example it should look like the code below:


<Style x:Key="BasedStyle" TargetType="Button">

    <Setter Property="FontSize" Value="16"/>

Style>

 

<Style TargetType="Button" BasedOn="{StaticResource BasedStyle}">

    <Setter Property="Background" Value="Red"/>

    <Setter Property="Foreground" Value="Black"/>

Style>


Undoubtedly, this is a great addition to the Silverlight styling. You can define implicit styles at any level of your application. Additionally you have the ability to override at any time the implicit style or even to reset it.

Time	Content
@ 0:00	Introduction and showing off what we are building in this screencast
@ 1:40	Adding the intro animation – preparation
@ 2:40	Adding the intro animation - MediaElement
@ 3:47	Visual State for playing the intro and transition between PlayingIntro and ShowingUIAfterIntro states
@ 4:57	Make the App start up in the PlayingIntro state
@ 6:07	Adding the EndCueTrigger
@ 9:40	Adding the playback status display
@ 12:50	Adding IntroStatusVisible and IntroStatusHidden states and transitions
@ 14:38	Creating the MediaElementStateToVSMBehavior
@ 16:18	Using the MediaElementStateToVSMBehavior to show and hide the video status display
@ 19:08	Creating the DisplayMediaStatusBehavior
@ 21:00	Using the DisplayMediaStatusBehavior to set the text for the video status display
@ 22:30	Adding the skip intro button
@ 24:30	Adding a glow effect to the skip intro button
@ 25:50	Creating MouseOverOpacityBehavior
@ 28:14	Applying the MouseOverOpacityBehavior to the skip intro button
@ 29:35	Making the skip intro button skip the intro
@ 31:30	Replay Intro – creating the highlight on the box
@ 33:20	Creating ReplayIntroVisible and ReplayIntroHidden states and transitions
@ 38:10	Adding some code to the skip intro and replay intro features
@ 41:30	Summing up