<ChristophDotNet : WPF

Silverlight 3 for Kiosk Apps? Of Course!

ChristophDotNet — Tue, 17 Nov 2009 15:48:36 GMT

Several of the customers I work with are looking to build kiosk or point-of-sale applications with Silverlight. The ease of deployment with browser-based Silverlight applications is definitely appealing. Sharing applications or components between customers’ kiosks and web sites is another appealing reasons to go with Silverlight. This post outlines the architecture decisions between Silverlight and WPF and presents architecture options for Silverlight based solutions. A follow up post will discuss the Silverlight implementation details.

However, POS systems or kiosks often need integration with local peripherals, such as credit card readers, barcode scanners, printers, etc. Since Silverlight browser applications run in a sandbox access to these devices isn’t immediately available. Therefore we need to find a way to insert a bridge between the peripherals and the Silverlight application to read data from the devices and forward the data to the Silverlight app.

To get started, let’s look at applications that can communicate with local peripherals. Desktop applications can communicate with local devices. Devices usually ship with C++ or .NET libraries to read data or sink events from devices. Therefore Desktop applications are usually preferred for POS systems. Microsoft has a POS for .NET framework to simplify development of applications that need access to a wide array of peripherals. WPF offers a very compelling option to build the application UI and building the UI in WPF is a great step to share assets between the kiosk and the Web. The following table summarizes the decision points to decide between a full desktop application or a Silverlight app.

Pro	Con
Full POS Framework for peripheral integration	Requires high-touch deployment
Full access to local resources (files, registry, printers, peripherals)	Some re-development to share assets between desktop and web applications
Hardware accelerated graphics	Windows specific
Richest Graphics with WPF and XNA
Full .NET Framework (WCF, WPF, WF, SxS versioning, …)

If the cons weigh too high and you really need a browser-based app, for example when you’re running in shared kiosk environments or if ease of deployment is much more important than peripheral integration, then you have a couple of options with Silverlight.

First, you can simply load the Silverlight application with a control hosted in a desktop application via the COM hosting interfaces. The host application can load the Silverlight application from a web URL, i.e. once you install the host application, you can still download the Silverlight application from the web. The Silverlight hosting interfaces even allow managing the download process, customize caching of .xap files and other resources through the IXcpControlHost interface.

For communication between the Silverlight app and the device manager running in the host application, the Silverlight application can expose an interface via the scriptable object bridge. That bridge is intended for communicating with the javascript engine of a web browser but it works in other containers as well. The scriptable object is accessible to the Win32 host via COM IDispatch interfaces, which the host application can invoke to send data to the embedded Silverlight application as shown in the diagram below.

You may at this point decide that the custom host is all you need, but may also want to run the application in a browser, for example because the Silverlight application integrates with an existing web site or you need to comply with an industry standard like CUSS.

Pro	Con
Single Process solution	Non-standard, Windows-only container
	Need to re-develop browser functionality, such as caching
	Tight coupling of peripheral management and application UI

In the past, applications installed a local web server like Cassini which hosted a .NET component that would communicate with local resources as needed. The Silverlight application would make REST calls to the “web server” which would handle the communication with a peripheral device or other local resources.

However, this approach had a couple of drawbacks. First, running a local web server requires administrator privileges and is often frowned upon because of potential security risks. Second, communication always had to be initiated by the Silverlight application. The peripheral could not send notifications to the application running in the browser.

Pro	Con
Potentially fully managed code implementation	Complexity running a local web server
	Communication overhead with HTTP
	One-way communication. Silverlight application has to poll/
	Policy restrictions for local services and sockets
	Perceived security risks of local web servers
	Complex deployment of local services

With Silverlight 3 we have an alternative that doesn’t require a local “web server”. Silverlight 3 introduced the ability for Silverlight applications to communicate regardless what application container they are running in. One Silverlight application would send messages over a “named channel” with a LocalMessageSender object. Another Silverlight application can listen on that named channel with a LocalMessageReceiver object.

In our case the Win32 application could be an application without a visible UI that only acts as a bridge between the peripherals and the browser application.

In a scenario where the need for a local peripherals is limited to a single, well-known device, the effort to write a C++ host and communicate with the device in unmanaged code isn’t a daunting task. More sophisticated POS solutions may require more than one peripheral type. They may even require supporting different device configurations, i.e. bar code readers from different vendors. These types of POS applications typically require POS abstraction frameworks like POS for .NET. However, in that case the host application could be either a managed C++ application with C++ code to implement the COM host for the Silverlight “bridge” application and .NET code to manage peripheral interaction.

Pro	Con
Loose coupling between peripheral management and UI	Local deployment of peripheral management application required
Shareable bridge	More complex architecture with two applications

To close with some food for thought, there may be a completely browser based alternative that I haven’t tested out yet. Instead of running a Silverlight bridge in a separate Win32 application you could try to build a C++ ActiveX control to host the Silverlight “bridge” and the native device interaction code. This approach presents some security challenges that can be mitigated, but you still have to deal with the perceptions of pushing down an ActiveX control.

You do have the benefits of clean separation between a cross-platform application that run on any platform that supports Silverlight and the platform specific extensions that need to manage interaction with local peripherals. You also have the benefit of a fully browser-based deployment model.

Pro	Con
Fully browser-based deployment model	Native code development of ActiveX control
	Policies for secure ActiveX execution required to avoid security risks

Win7 Multi-touch. Why wait until WPF4?

ChristophDotNet — Wed, 23 Sep 2009 13:30:23 GMT

WPF 4 is going to fully integrate Win 7’s multi-touch capabilities. with Windows 7 being RTM, you don’t have to wait for WPF 4 to be released for developing multi-touch demos. You can get started today with the native Win7 APIs, or with the WindowsTouch library for .NET 3.5SP1. The .NET library is much easier to work with since the native APIs are rather low level and based on the existing tablet APIs.

Check out the link to the Win 7 .NET Interop Sample or the Channel9 video: http://channel9.msdn.com/shows/Continuum/MultitouchLibraryWin7/.

Lynn’s blog post discusses the question on multi-touch with .NET 3.5 or 4.0: http://blogs.msdn.com/socaldevgal/archive/2009/06/15/socaldevgal-wishes-to-decide-net-3-5-or-net-4-0-for-windows-7-multi-touch-application-development.aspx. It’s got more useful links to multi-touch development on Win7 resources as well.

At least until WPF4 ships, there is a viable option to build production apps with multi-touch. There are some differences how WindowsTouch and WPF4 implement things, and you’re probably encountering a little bit of re-work, but both options are based on WPF and most of your UI and you code-behind should stay the same and you learn the UI Design Guidelines for Touch right away.

Enjoy.

WPF UI Update from Background Threads

ChristophDotNet — Wed, 14 May 2008 17:30:36 GMT

I'm trying to do my apps in any type of XAML these days since I finally think I "got it". I wish I could claim that I will break free from the limitations of HTML and my new found liberty will result in fantastic looking apps -- but in reality, I still lack the design skills to come up with something that looks really cool.

Either way, XAML presents a great opportunity to really innovate on the UIs with regards to looks and interactivity, regardless if you’re writing desktop apps with WPF, web apps with Silverlight, mobile apps with Silverlight Mobile or if you're programming for one of these cool Surface tables ... and I will write my puny little test apps in WPF, even if they are just as ugly as my Windows Forms apps used to be.

Now, I'm writing this cool little app and I want to do some interesting stuff in the background (my apps may be ugly, but at least they are responsive). WPF is still STA, which means you still have to be explicit about posting back to the main UI thread if your background thread needs to communicate updates … bummer, but I thought I knew how to program async from my Windows Forms apps. As it turns out, it's a little bit different and there are few things to keep in mind. It also turns out that things are still not as widely document. That’s why I’m sharing.

For starters, there's the handy Dispatcher on every UIElement which provides the BeginInvoke method to run code on the right thread.

For example, my program dispays progress with a WPF ProgressBar object. To update that ProgressBar from the background thread, the ProgressBar fires an event. The EventHandler then calls BeginInvoke, on the background thread. BeginInvoke will then pass the DispatcherOperationCallback to the main thread to execute:

runner.RequestFinished += delegate(object s, RequestFinishedEventArgs e2)

    System.Diagnostics.Debug.WriteLine("Update event handler called.");

try

        progressBar1.Dispatcher.BeginInvoke(

           System.Windows.Threading.DispatcherPriority.Normal

           , new DispatcherOperationCallback(delegate

                       System.Diagnostics.Debug.WriteLine("value is: " + progressBar1.Value);

                       progressBar1.Value = progressBar1.Value + 1;

                       return null;

                   }), null);

    catch (Exception ex)

        System.Diagnostics.Debug.WriteLine(ex.ToString());

};

Works great - you see the progressBar update every time the event handler is invoked. I had some Debug.WriteLine statements in there to make sure:

Update event handler called.

value is: 0 <—delegate being called to update the UI

Update event handler called.

value is: 1 <—delegate being called to update the UI

It works great … unless you're working with synchronization objects like ManualResetEvent. My code was waiting *on the background thread* for my stuff to complete, while at the same time posting back to the main thread with BeginInvoke - under the assumption that only the background thread is blocking:

ManualResetEvent waiter;

public TestRunner()

    waiter = new ManualResetEvent(false);

public void RunAsync(TestConfig conf)

    Thread t = new Thread(RunInternal);

    t.IsBackground = true;

    conf.wait = waiter;

    waiter.Reset();

    t.Start(conf);

    waiter.WaitOne();

    System.Diagnostics.Debug.WriteLine("done waiting");

WRONG assumption. The background thread is executing until the ManualResetEvent's WaitOne() returns. All the messages from the Dispatcher are queued up. Consequently, the progressBar doesn't update even though the background thread is operating as expected and the Debug Output looks like this:

Update event handler called.

<—delegate NOT called to update the UI

Update event handler called.

<—delegate NOT called to update the UI

done waiting <—delegate NOT called until the ManualResetEvent was Set()

value is: 0

value is: 1

The best way around this is to architect your program event driven, for example as a state machine, and avoid synchronization objects altogether.

Hopefully you enjoy UI programming with WPF or Silverlight as much as I do.