Category Archives: 13544

Using The GeoCoordinateReactiveService

Having created an Rx wrapper over the GeoCoordinateWatcher on a previous post, in this post I’ll demonstrate how it can be used in a simple application.


The application will display the status of the service, the position and the distance traveled.


For this simple application the service will be exposed as a singleton property of the App class:


public partial class App : Application
{
    // ...

    public static IGeoCoordinateReactiveService GeoCoordinateService { get; private set; }

    public App()
    {
        // ...

        InitializePhoneApplication();

        // ...
    }

    // ...

    private void InitializePhoneApplication()
    {
        // ...

        GeoCoordinateService = new GeoCoordinateReactiveService();

        // ...

    }

    // ...

}

Getting the status of the service is very simple. It just requires subscribing to the StatusObservable. Since we want to display the status, we need to observe it on the dispatcher before:


App.GeoCoordinateService.StatusObservable
    .ObserveOnDispatcher()
    .Subscribe(this.OnStatusChanged);

For the position we do the same with the PositionObservable:


App.GeoCoordinateService.PositionObservable
    .ObserveOnDispatcher()
    .Subscribe(this.OnPositionChanged);

The distance traveled would seem a bit more complicated because we need to keep track of the last position and calculate the distance traveled on every position change. But this is where the Rx excels with its query operators. If we combine the position observable with the position observable having skipped one position with the zip operator we end up with an observable with the current and previous position. And if we apply a selector, we get the traveled distance:


App.GeoCoordinateService.PositionObservable
    .Zip(
        App.GeoCoordinateService.PositionObservable.Skip(1),
        (p1, p2) => p1.Location.GetDistanceTo(p2.Location))
    .ObserveOnDispatcher()
    .Subscribe(this.OnDistanceChanged);

You can find the complete implementation of the service and application here.




Resources:


A Synchronization Context Based On The TPL Dataflow Library

The purpose of the synchronization model implemented by the SynchronizationContext class is to allow the asynchronous/synchronization operations of the common language runtime to behave properly with different synchronization models. This model also simplifies some of the requirements that managed applications have to follow in order to work correctly under different synchronization environments. Examples of such synchronization environments are user interface infrastructures like Windows Forms, Windows Presentation Foundation and ASP.NET.


Providers of synchronization models extend this class to provide their own implementations. Because these user interface infrastructures usually run on their own threads, dispatching execution to their execution contexts usually means leaving the current thread.


The Task Parallel Library (TPL) provides dataflow components to help increase the robustness of concurrency-enabled applications. These dataflow components are collectively referred to as the TPL Dataflow Library. This dataflow model promotes actor-based programming by providing in-process message passing for coarse-grained dataflow and pipelining tasks. The dataflow components build on the types and scheduling infrastructure of the TPL and integrate with the C#, Visual Basic, and F# language support for asynchronous programming. These dataflow components are useful when you have multiple operations that must communicate with one another asynchronously or when you want to process data as it becomes available.


The TPL Dataflow Library (System.Threading.Tasks.Dataflow namespace) is not distributed with the .NET Framework 4.5. To install the System.Threading.Tasks.Dataflow namespace, open your project in Visual Studio 2012, choose Manage NuGet Packages from the Project menu, and search online for the Microsoft.Tpl.Dataflow package.


Sometimes, for demo or testing purposes, I need a synchronization context that behaves like the user interface ones but doesn’t force me to build applications with a user interface and the TPL Dataflow Library seemed like a good option to implement such synchronization context.


It was as easy as this:


public class TplDataflowSynchronizationContext : SynchronizationContext
{
    private ActionBlock<ActionItem> ab
        = new ActionBlock<ActionItem>(
            item =>
            {
                Trace.WriteLine(
                    string.Format("{0}: {1}", Environment.CurrentManagedThreadId, item.operation));

                try
                {
                    item.d(item.state);
                }
                finally
                {
                    item.SetResult(true);
                }
            });

    public override SynchronizationContext CreateCopy()
    {
        return new TplDataflowSynchronizationContext();
    }

    public override void Post(SendOrPostCallback d, object state)
    {
        Trace.WriteLine(
            string.Format("{0}: Posting...", Environment.CurrentManagedThreadId));

        this.ab.Post(new ActionItem { d = d, state = state, operation = "Post" });

        Trace.WriteLine(
            string.Format("{0}: Posted.", Environment.CurrentManagedThreadId));
    }

    public override void Send(SendOrPostCallback d, object state)
    {
        Trace.WriteLine(
            string.Format("{0}: Sending...", Environment.CurrentManagedThreadId));

        ActionItem item = new ActionItem { d = d, state = state, operation = "Send" };
        this.ab.SendAsync(item);
        item.Task.Wait();

        Trace.WriteLine(
            string.Format("{0}: Sent.", Environment.CurrentManagedThreadId));
    }

    public class ActionItem : TaskCompletionSource<bool>
    {
        public SendOrPostCallback d;
        public object state;
        public string operation;
    }
}

UPDATE:


Fixed implementation because the SynchronizationContext.Send method returned without having completely executed the operation. Thanks to Svick for pointing that out and Stephen Toub for the help fixing it.

C# 5.0 Async/Await Demo Code

I’ve published the sample code I use to demonstrate the use of async/await in C# 5.0. You can find it here.

Projects

PauloMorgado.AyncDemo.WebServer

This project is a simple web server implemented as a console application using Microsoft ASP.NET Web API self hosting and serves an image (with a delay) that is accessed by the other projects.

This project has a dependency on Json.NET due to the fact the the Microsoft ASP.NET Web API hosting has a dependency on Json.NET.

The application must be run on a command prompt with administrative privileges or a urlacl must be added to allow the use of the following command:

netsh http add urlacl url=http://+:9090/ user=machine\username


To remove the urlacl, just use the following command:



netsh http delete urlacl url=http://+:9090/


PauloMorgado.AsyncDemo.WindowsForms



This Windows Forms project contains three regions that must be uncommented one at a time:



Sync with WebClient



This code retrieves the image through a synchronous call using the WebClient class.



Async with WebClient



This code retrieves the image through an asynchronous call using the WebClient class.



Async deadlock



This code how async operations can still deadlock.



Async with HttpClient with cancelation



This code retrieves the image through an asynchronous call with cancelation using the HttpClient class.



PauloMorgado.AsyncDemo.Wpf



This WPF project contains three regions that must be uncommented one at a time:



Sync with WebClient



This code retrieves the image through a synchronous call using the WebClient class.



Async with WebClient



This code retrieves the image through an asynchronous call using the WebClient class.



Async deadlock



This code how async operations can still deadlock.



Async with HttpClient with cancelation



This code retrieves the image through an asynchronous call with cancelation using the HttpClient class.

Breaking Changes In Argument List Evaluation In C# 5.0

The C# Language Specification states on §7.5.1.2 that “(…) the expressions or variable references of an argument list are evaluated in order, from left to right (…)”.

So, when this code is compiled with the C# 4.0 compiler:

static void M(
    int x = 10,
    int y = 20,
    int z = 30)
{
    Console.WriteLine(
        "x={0}, y={1}, z={2}", x, y, z);
}

static void Main(string[] args)
{
    int a = 0;

    M(++a, z: ++a);
}


and run, this unexpected output is obtained:



x=2, y=20, z=1


In fact, fixing this compiler flaw was the cause of one of the few breaking changes introduced in C# 5.0.



Using the 5.0 compiler, the expected result is obtained:



x=1, y=20, z=2


To avoid this type of surprises, expression evaluation should be avoided in argument lists.



With this code:



int a = 0;

int i = ++a;
int j = ++a;

M(i, z: j);


the same result is obtained for both C# 4.0 and C# 5.0:



x=1, y=20, z=2

How To: Make XAML Content Globalizable When Using Value Converters

(This content was written based on Silverlight for Windows Phone, but might be valid for generic Silverlight.)

There are a many articles on MSDN (and all over the Internet) about globalization and localization of Silverlight applications in general and specifically Windows Phone 7 applications but I haven’t found any that uses a value converter.

Continue reading

Hash Function Added To The PredicateEqualityComparer

Sometime ago I wrote a predicate equality comparer to be used with LINQ’s Distinct operator.

The Distinct operator uses an instance of an internal Set class to maintain the collection of distinct elements in the source collection which in turn checks the hash code of each element (by calling the GetHashCode method of the equality comparer) and only if there’s already an element with the same hash code in the collection calls the Equals method of the comparer to disambiguate.

At the time I provided only the possibility to specify the comparison predicate, but, in some cases, comparing a hash code instead of calling the provided comparer predicate can be a significant performance improvement, I’ve added the possibility to had a hash function to the predicate equality comparer.

You can get the updated code from the PauloMorgado.Linq project on CodePlex,

Globalization, Localization And Why My Application Stopped Launching

When I was localizing a Windows Phone application I was developing, I set the argument on the constructor of the AssemblyCultureAttribute for the neutral culture (en-US in this particular case) for my application.


As it was late at night (or early in the dawn Smile) I went to sleep and, on the next day, the application wasn’t launching although it compiled just fine.


I’ll have to confess that it took me a couple of nights to figure out what I had done to my application.


Have you figured out what I did wrong?


The documentation for the AssemblyCultureAttribute states that:


The attribute is used by compilers to distinguish between a main assembly and a satellite assembly. A main assembly contains code and the neutral culture’s resources. A satellite assembly contains only resources for a particular culture, as in [assembly:AssemblyCultureAttribute(“de”)]. Putting this attribute on an assembly and using something other than the empty string (“”) for the culture name will make this assembly look like a satellite assembly, rather than a main assembly that contains executable code. Labeling a traditional code library with this attribute will break it, because no other code will be able to find the library’s entry points at runtime.


So, what I did was marking the once main assembly as a satellite assembly for the en-US culture which made it impossible to find its entry point.


To set the the neutral culture for the assembly resources I should haveused (and eventually did) the NeutralResourcesLanguageAttribute. According to its documentation:


The NeutralResourcesLanguageAttribute attribute informs the ResourceManager of the application’s default culture, and also informs the ResourceManager that the default culture’s resources are found in the main application assembly. When looking up resources in the same culture as the default culture, the ResourceManager automatically uses the resources located in the main assembly instead of searching for a satellite assembly. This improves lookup performance for the first resource you load, and can reduce your working set.