Awkward Coder

RavenDB - locked database base when running Azure emulator

2011-12-06T06:07:00.001-08:00

Thought I'd note this down for anyone observing this in the future - this was purely down to user (me) error!

If you ever find yourself using the embedded version of RavenDB in an asp.net based azure hosted service running in the azure emulator locally don't play around with azure instance settings as it can f**k-up royally and cause you no end of pain with your RavenDB instance.

Specifically if you change the number of instance to anything other than 1 you start to observe race conditions in your app. Always keep the instance count to 1 when running in the emulator locally:

If you don't you start to receive exceptions like the following:

IT took me about an hour to figure this out, I only realised when I looked at the azure compute storage emulator and saw 2 instances running simultaneously. I would have thought these would be using separate physical database instances but after thinking about this it became obvious they weren't - the IIS instances were virtualised but the physical folder structure wasn't.

Configuring default page for azure service

2011-12-06T05:31:00.001-08:00

Been playing around with Azure for a week or so now and I'm starting to get my head round it, to be honest it ain't that difficult. @RichGee & I are going to be deploying RESTful services into the cloud for our shiney ninja project and whilst we are spiking these out I wanted to be able to set the default page, you know something like 'default.html'.

Now this was easy when hosting a service in IIS, all you had to do was specify the default document types:

But in azure there isn't any visible way to access IIS from the management tools, you only have access to the 'Hosted Services' console:

I suppose you could remote onto the virtual box and set it up in IIS, but that feels overly complicated.

There must be any easier way?

There is if you are using asp.net, the element in the web.config. This allows you specify the default document at design time and will be injected into IIS when the web service\site is installed into IIS by azure:

More info can be found in MSDN here.

Getting app feedback from windowsphone.com

2011-12-01T07:54:00.001-08:00

I was chatting with my good friend Denis (@dhaman) about user feedback for the apps he's produced for the iPhone & droid app stores and just like the WP7 app store they all fall short in supporting your app once released out into the wild. I was also reading the final post in the '31 days of mango...' by @jeffblankenburg and he talks about promoting your app, he mentions the great work Nick (@spacescape) did originally for FINDaPAD in producing a template you can use to provide a bespoke site for WP7 app - Nick pushed this out to codeplex here.

Denis pointed out he started to explicitly put a feedback mechanism in the app blurb, ideally at the top. Initially I thought I don't need this, we've got http://findapad.biz with feedback via uservoice, but then I realised there isn't any way for a user viewing FINDaPAD in the app store to get in touch with us. This is a piece of functionality that should be in the app store and I don't mean a forum like feature to discuss the review\rating by a dissatisified user (1 star rating for FINDaPAD) I mean the ability to provide a contact point for any user to talk to you.

As you can see from the screenshot below they don't even provide anyway to show a support URL or email. I would have expected something down the left hand-side.

I don't really expect the app store to get a make over until Windows 8 platform is released (including to the phone). So what I am going to do to help us get better feedback in the mean time is put an explicit message in the blurb. Something like:

'We really want to hear from you, get in touch via feedback @ http://findapad.biz'

Now where this should be positioned is the difficult question, I'll try near the bottom at first and see what happens.

Observations on web service design for mobile devices

2011-11-28T09:53:00.001-08:00

This post was prompted by my use of back end third party services for the FINDaPAD app and my recent set of posts about push pins and Bing Maps control. I want to explore the affect the design of the back end services can have on a mobile app UX & UI design.

For FINDaPAD we make use of two sets of third party services, Nestoria & UK Crime API. Nestoria is a property search service for the UK and other countries whilst UK Crime API provides crime information for England & Wales, we use the second to generate crime stats for a local area when viewing a property in FINDaPAD.

Even though Nestoria claim on their website 'The API is very much a work in progress.' I believe this be a well thought out API from a consumers perspective, it has a compact data schema (JSON or XML) and it enforces a pagination convention on the consumer which has a bigger benefit for mobile app development than for full blown desktop for the simple reason of CPU performance and power consumption. We use two APIs from Nestoria, one for property details and the other for average property prices - one HTTP GET request for one set of results. It has well defined pagination API which limits the maximum page size to 50.

Shown below is the performance cost of making a HTTP GET request against Nestoria on a tethered WP7 device - it takes approximately 3.7 seconds to request the first 50 properties, decode the JSON and map into a domain model. The relationship between the number of properties downloaded and the time taken to download is relatively linear and predictable and this fact is import when designing how your UI reacts when downloading data - whether it sits there with a progress bar or allows the user to perform other actions.

The UK Police API is a less mature API having been around for about a year, it allows you to query for data by several different criteria.

In FINDaPAD we have to use two separate API calls to get the information we want - two HTTP GET requests for one set of results. First we have to make a HTTP GET request with our geo-location to get the police force & neighbourhood values and then a second HTTP GET request with the result from the first to get the crime stats for the current geo-location. Now this isn't a problem per-se for FINDaPAD because we request the crime stats asynchronously whilst we are trickling the property data from Nestoria to the UI so the user experience is a seem less transition from the details of property to the crime stats for the local area. Ideally this would have been done as a single web request not only from a performance point of view but from a cost - if you're paying for your data plan on your mobile device then you would have incurred a greater cost.

In my 'How many pins...' I was using a UK Police API to return all the crimes in a particular area, this was based on the idea of supplying a geo-location and it would return all the crimes occurring within a 1 mile radius for the last calendar month. This API call works great when tested from a desktop app or the WP7 emulator because both have plenty of processor power, memory and network connectivity. But when running on a device it can be an issue because the returned data set has an unlimited size and the cost in time to transmit this down the wire, decode etc is unknown - fundamentally the API does not support pagination. This is best demonstrated by the following set of screen shots, searches for crimes in totally different locations, one a remote rural area and the other an urban inner city area:

The first screen shot shows the cost to get all the crimes in a rural area (where there are no crimes) and the second in the urban inner city you can see how the elapsed time has increased, if the total crimes in the urban area increases I don't have anyway of calculating how long it would take to request and process going results and ultimately this could lead the user to abandon the app (and give it a bad rating!).

So you might ask - Okay how would you do it then?

If I was going to keep the API endpoint the same - all crimes in a 1 mile radius. I would add pagination support so that I could trickle the data to UI as each request is fulfilled. If I was going to change the API I would like the ability to specify a bounding rectangle so I could request only the visible crimes, this would also require pagination as the number of crimes could be even greater than the 1630 show above. Though there could be a downside to the second approach as this would make client caching more problematic.

Don't be under the impression I think the UK Police API is bad or wrongly implemented, I believe this APIs will mature over time as greater understand of how the data is being used.

Remember not all publicly consumable web services are well suited for use with mobile devices.

How many pins can Bing Maps handle in a WP7 app - part 3

2011-11-23T12:51:00.001-08:00

I've finally got round to finishing this 3 part series about manipulating push pins on the Bing Maps control in WP7 - the final part took longer than expected!

In the first part I showed what happens to memory usage and UI performance when you have to many pins to show and how virtualizing the pins can reduce and improve both of these. In the second part I showed how you could optimise the HTTP calls to the back end services and how scrolling around the map control can be used to start and stop the requesting of more data.

In this part what I want to show is how you can group & cluster pins and effectively remove the idea of using a pins completely but still convey the geo-location data to the user. I'll be using techniques described in the polygons posts I wrote previously to help with the grouping & clustering of pins.

For this post like the previous posts I'm going to be using the UK Police API for street level crime, see here. This API gives a lot of data when used in an urban area like London and I'll using a location based in London to show how grouping and clustering can improve the UI experience.

At the end of part 2 we still had the same UI as part 1 but it was optimised for HTTP communication to the back end services - the first screen shot shows the map with no push pins and second shows the UI at the end of the second post:

As you can see the second screenshot indicates there was 313 crimes in the visible bounding rectangle - what you can't gain from interpreting the data with pins is there are multiple crimes for the same location. Plus when there are a lot crimes we start to loose site of the map control it's self and this defeats the point of using the map control in the first place. I've also highlighted the memory usage and at the end of part 2 the memory usage was around 48 Mb which to be honest is rather high for such a simple task.

What I did to get round these issues was to use a square polygon to represent a defined area of the visible map - very similar to the way I did this in the 'tessellating polygons' posts. I then calculated if a crime occurred within this defined area and if it did the crime was added to class representing the defined area ( class called 'CrimeShape'). The first screen shot below shows the same location zoomed out with no tessellation, the second shows the squares at this resolution. As you can see we can now show more crime data, well over 1000, but at this resolution it's still hard to gain a meaningful understanding. The third screen shot is the same place at a higher resolution:

So now we've a reduced number of pins and an increased amount of crime data. What's interesting about the third screen shot is it appears there is a crime hot spot centred around the traffic junction (intersection) - 269 crimes. The memory usage is also much better, even on the second screen shot we're now peaking memory at half the previous implementation peak value.

Drilling down further into the data by increasing the resolution of the map control (via the Zoom property) and gradually reducing the square area size I get the following set of screen shots:

What you see from the fifth screen shot above is the actually crimes are not occurring at the traffic junction (intersection) they are occurring just above to the left. Determining this kind of detail wouldn't have been possible if I'd just shown pins or used a low map resolution and a course grained area granularity.

Now I think this is a great way to use the polygons on top of the map control but the use of squares doesn't quite look or feel right - they are too regular. What is required is a more irregular pattern - how about hexagons or triangles!

I really like the hexagons, it reminds me of honeycomb...

Before I get into the code and how it is structured I want to show how this data can be interpreted to generate heat map instead of using pins all together:

I get a similar affect using hexagon shapes:

Looking at the code to generate the heat map first this was achieved by binding the crime counts for an area to the Fill property of the MapPolygon class. This is more difficult than it appears and the reason being the Fill property is not a dependency property so you can't bind to it. To get round this I derived from the MapPolygon class and made Fill a dependency property:

public sealed class MapPolygonExtended : MapPolygon
{
    public static readonly DependencyProperty FillProperty = DependencyProperty.RegisterAttached("Fill",
                                                                                                 typeof(Brush), 
                                                                                                 typeof(MapPolygonExtended), 
                                                                                                 new PropertyMetadata(new PropertyChangedCallback(FillChangedCallback)));

    public Brush Fill
    {
        get { return base.Fill; }
        set { base.Fill = value; }
    }

    private static void FillChangedCallback(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var dlb = (MapPolygonExtended)d;
        dlb.Fill = (Brush)e.NewValue;
    }
}

Then using this class I'm able to bind a property from the ViewModel to the Fill property:

As you can see from the XAML above I'm using a converter to convert the CrimeCount property from the CrimeShape Model to a solid brush colour. This is where the thresholds are defined for the polygon fill colour:

public sealed class CrimeCountConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        var count = (int)value;

        if (count < 3)
        {
            return new SolidColorBrush(Colors.Green);
        }

        if (count < 10)
        {
            return new SolidColorBrush(Colors.Orange);
        }

        return new SolidColorBrush(Colors.Red);
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

The CrimeShape Model aggregates the Polygon Model and is bound via the MapViewModel class. These are standard bindable Model & ViewModel classes. I'm not going to show the complete code for these classes, what is shown below is how the top level service is used to generate & group the crime data for rendering onto the map control. Whether the crime data is shown using a heat map or aggregated push pin is not defined in the ViewModel this is defined as shown above in the XAML.

private void BuildCrimeMap()
{
    if (ukCrimeMapSubscriber != null)
    {
        log.Write("MapViewModel: Shutting down existing crime map subscriber...");
        ukCrimeMapSubscriber.Dispose();
        ukCrimeMapSubscriber = null;
    }

    log.Write("MapViewModel: Building crime map...");

    if (shapeSelected)
    {
        crimeShapes.Clear();
    }
    else
    {
        var nonVisible = crimeShapes.Where(cs => !boundingRectangle.Intersects(cs.TileBoundingRectangle));
        nonVisible.ForEach(cs => crimeShapes.Remove(cs));
    }

    Busy = true;
    shapeSelected = false;

    Func<LocationRect, double, IObservable<CrimeShape>> func = (r, s) => Observable.Empty<CrimeShape>();
    if (selectedShape.Name.ToLower().Contains("square"))
    {
        func = (r, s) => ukCrimeMapService.TessellateSquares(boundingRectangle, selectedShape.Size);
    }
    else if (selectedShape.Name.ToLower().Contains("hexagon"))
    {
        func = (r, s) => ukCrimeMapService.TessellateHexagons(boundingRectangle, selectedShape.Size);
    }
    else if (selectedShape.Name.ToLower().Contains("triangle"))
    {
        func = (r, s) => ukCrimeMapService.TessellateTriangles(boundingRectangle, selectedShape.Size);
    }

    ukCrimeMapSubscriber = func(boundingRectangle, selectedShape.Size)
            .ObserveOnDispatcher()
            .Subscribe(crimeShape =>
            {
                if (crimeShapes.Any(cs => cs.Polygon == crimeShape.Polygon))
                {
                    return;
                }

                crimeShapes.Add(crimeShape);
            },
            exception => { },
            () =>
            {
                Busy = false;
                log.Write("MapViewModel: Crime shapes count = " + crimeShapes.Count);
            });
}

As you can see I'm using Rx (Reactive Extensions) again to deal with asynchronous nature of the tessellating function, not only is the method asynchronous it will return a stream of CrimeShape class instances, the number of theses is determined from the input parameters to the tessellating method. I really like the compact nature of the call to the Rx method - from the ViewModel perspective it is only 10 lines of code!

The service definition is shown below, as you can see I've tried to keep this simple and very clean:

public interface IUkCrimeMapService
{
    IObservable<CrimeShape> TessellateSquares(LocationRect boundingRectangle, double size);
    IObservable<CrimeShape> TessellateTriangles(LocationRect boundingRectangle, double size);
    IObservable<CrimeShape> TessellateHexagons(LocationRect boundingRectangle, double size);
}

This service interface is implemented by the UkCrimeMapService class. The responiblity of this class is two-fold:

Firstly the orchestration of calls to two other services that actually do the work of generating (tessellating) the polygons - ICreatePolygons, and the work to retrieve the crime data from the UK Police back end services - IUKCrimeService.

Secondly the assignment of polygons and crime data to correct CrimeShape class instance.

public sealed class UkCrimeMapService : IUkCrimeMapService
{
    private readonly ICreatePolygons polygonService;
    private readonly IUkCrimeService crimeService;
    private readonly ICacheProvider cacheProvider;
    private readonly ILog log;
    private readonly TimeSpan cacheTimeout;

    public UkCrimeMapService(ICreatePolygons polygonService, IUkCrimeService crimeService, ICacheProvider cacheProvider, ISettings settings, ILog log)
    {
        this.polygonService = polygonService;
        this.crimeService = crimeService;
        this.cacheProvider = cacheProvider;
        this.log = log;

        cacheTimeout = TimeSpan.FromMilliseconds(settings.CacheTimeout);
    }
}

The polygon generating service interface, ICreatePolygons, is defined as follows, I've removed several other mehtods to show only the relevant methods for this post. As you can see this has a similiar structure to the previous service interface:

public interface ICreatePolygons
{
    IObservable<Polygon> TessellateVisibleSquares(LocationRect visibleRectangle, double size);
    IObservable<Polygon> TessellateVisibleHexagons(LocationRect visibleRectangle, double size);
    IObservable<Polygon> TessellateVisibleTriangles(LocationRect visibleRectangle, double size);
}

The crime service also has a simply definition, the criterion takes a geo-location for the area you want retrieve crime data for, the data is returned in a one mile radius of the location:

public interface IUkCrimeService
{
    IObservable<StreetLevelCrimeResult> SearchStreetLevelCrime(StreetLevelCrimeCriterion criterion);
}

The way the call to the UkCrimeMapService orchestrates the calls to these services is as follows:

The polygons service is called to tessellate polygons for the required bounding rectangle asynchronously,
As each polygon is received a CrimeShape class instance is created and published,
The number of calls required to retrieve all crimes for the polygon area is calculated,
This list and polygon are then pushed onto a queue to be processed by a background worker,
The background worker starts processing the queue and retrieve the crime data from the UK crime service,
Once all the data is returned the Rx observer is signalled as being complete and the background worker shut down.

We use caching where applicable in the services to avoid repetitively creating the same polygons or requesting the same crime data from the UK Police API.

Steps 1, 2, 3 & 4 are represented by the following two methods:

private IObservable<CrimeShape> TessellatingImpl(LocationRect boundingRectangle, double size, Func<LocationRect, double, IObservable<Polygon>> tessellatingFunc, string polygonName)
{
    var crimeWorker = new CrimeWorker();
    var localWorker = crimeWorker;

    return Observable.Create<CrimeShape>(obs =>
    {
        localWorker.SetObserver(obs);
        localWorker.Worker.DoWork += DoCrimeWork;
        localWorker.Worker.WorkerSupportsCancellation = true;
        localWorker.Worker.RunWorkerAsync(localWorker);

        Scheduler.ThreadPool.Schedule(mapThrottle, o =>
        {
            localWorker.TessellatingDisposable = tessellatingFunc(boundingRectangle, size)
                .SubscribeOn(Scheduler.ThreadPool)
                .ObserveOn(Scheduler.ThreadPool)
                .Subscribe(polygon => ProcessResponse(polygon, polygonName, localWorker),
                            FailedTessellatingPolygons,
                            () => CompletedTessellatingPolygons(localWorker));

            mapThrottle = TimeSpan.FromMilliseconds(MapSubsequentThrottle);
        });

        return localWorker.Disposable;
    }).Finally(() =>
    {
        log.Write("UkCrimeMapService: Shutting down background worker...");
        crimeWorker.Dispose();
        log.Write("UkCrimeMapService: Background worker shutdown...");
    });
}
      
private void ProcessResponse(Polygon polygon, string polygonName, CrimeWorker crimeWorker)
{
    var cacheKey = new CrimePolygonTuple(polygon);
    var crimeShape = cacheProvider.Get<CrimePolygonTuple, CrimeShape>(cacheKey);
    var criteria = Enumerable.Empty<StreetLevelCrimeCriterion>();
    if (crimeShape == null)
    {
        crimeShape = new CrimeShape(polygon, polygonName, polygon.Size);
        cacheProvider.Add(cacheKey, crimeShape, cacheTimeout);

        criteria = CalculateCrimeCriteria(crimeShape.TileBoundingRectangle);
    }
    else if (!crimeShape.IsComplete)
    {
        criteria = CalculateCrimeCriteria(crimeShape.TileBoundingRectangle);
    }

    if (crimeWorker.IsDisposed)
    {
        return;
    }

    criteria.ForEach(c => crimeWorker.PushQueue(new CrimeCriterionTuple { CrimeShape = crimeShape, Criterion = c }));

    var observer = crimeWorker.Observer;
    if (observer != null)
    {
        crimeWorker.Observer.OnNext(crimeShape);
    }
}

Could this code be used in a real world WP7 app?

The simple answer is NO!

The reason for this is not the quality of the code per-se but the fact it's using services that aren't well designed for this use. The code has all the required exception handlers, it also avoid doing work on the UI thread (Dispatcher) as much as possible and it manages the life time of the background worker correctly. What I mean by 'services that aren't well designed for this use' can be best demonstrated by the following three screen shots. The first shows the application running through the WP7 emulator and as we all know the emulator is a really bad place to measure app performance:

As you can see from the highlighted output window in visual studio the total time to create the polygons, retrieve the data from the UK police API backend services and render the heat map is less than 8 seconds!

You start thinking this is looking really promising and then you try it on a device. I tried this on my new Nokia Lumia 800:

The elapsed time has risen to 14 seconds, now you're probably thinking this isn't to bad either but what you have to remember is the device is tethered to a machine so the network type is ethernet and importantly I'm only request crime data for a small area.

When you start to look at a larger area it will increase the elapsed time greatly:

The screen shot above represents an area approximate to 3x2 miles and the time taken is over 6 minutes!

The majority of the time is consumed in retrieving the crime data, deserializing to JSON and mapping into model classes ready for use. If the UK Crime API was more mature then maybe there would be a better and more simpler way to retrieve this data - I'm going to talk about back end service design in a future post.

I've made the code available for download via SkyDrive, if you want to run the demo you'll need to register for an account with the UK Police API here.

The code makes extensive use of the WP7Contrib for help with accessing the backend HTTP services, caching of data in memory and the binding of Model classes to the UI.

Setting up RavenDB in IIS 7.5

2011-11-21T08:38:00.001-08:00

I started exploring RavenDB today and the first part was to get an instance running under IIS, specifically running under IIS 7.5 (Windows 7). This is a quick post to help explain a very simple issue I had because of my lack of familiarity with IIS 7.5.

I downloaded the latest binaries and followed the instructions for setting up RavenDB can be found here. This was very quick and simple, I thought I had everything working, but then I started seeing the following:

I know RavenDB is being loaded into the IIS Worker Process - because I can see 'Raven' in the error message. Apart from that 'Your request didn't match anything that Raven knows to do, sorry...' didn't really help point me in any useful direction. I can't even tell if the problem is related to RavenDB or IIS 7.5.

It turns out the problem was related to the ACL for the website configured in IIS 7.5. Specifically I hadn't associated the Application Pool Identity with the website. This link has all the background and information required to complete this association, below is the screenshot for creating the 'RavenDB' app pool association:

Once this was done I was able to run management studio and create the default database and actually start some work :)

Please welcome FINDaPAD to the WP7 app store

2011-11-04T10:50:00.000-07:00

I'm proud to announce the release of FINDaPAD into the WP7 app store, it's been a long journey working on this app and I'd like to thank my co-workers Rich & Nick for all their hard work. We've spent the last 6 months working on this at the weekends and as with all software released to market the last few weeks seem to have been the hardest.

So what is a FINDaPAD?

FINDaPAD is a property search app for buy or rental properties in the UK housing market.

We aren't the first app to go to market offer property search services but we do believe we offer something different from a UI perspective - we've tried to follow the Metro-style guidelines for WP7 as much as possible. The app is very much designed with the idea of being used when you're out & about looking for properties and you need a quick and easy way to search the local area. You also have the ability to search locations using post code, place name or geo-location.

The rest of this post describes the technologies used in developing the app.

The app is currently NOT a mango app - yes I've said it, it's NOT a mango app. The simple reason being we started the app on the 7.0 and we took the decision in late August not to move to Mango until after we had a stable release. August might seem a long time ago but when you're trying to get something out of the door, days and weeks seem to go by very quickly indeed. The app was first submitted for approval prior to the Microsoft BUILD conference in early September and after two failed submissions it was finally approved and in the store by late September.

You might be wondering why wait until now to start talking and publicising the app? We realised after getting the app into the market place there was still plenty to do - website, twitter, PR, support, etc. We choose the achievement of a successful submission to be a soft launch of the app with friends and relatives testing and giving feedback. Since the initial release we've submitted eight updates to the market place in the last 6 weeks, these including a couple of big bug fixes and the addition of missing functionality which only became obvious after family used it to find their new home in Brighton. So now we're ready for a hard release with a PR push.

We built the app using the following APIs, frameworks & libraries:

Nestoria API - open source API providing property information for the UK and other countries,

UK Crime API - open source API providing crime stats for the UK,

WP7Contrib - we use this for all communication with back end web services, custom MVVMLight messenger, UI transitions and custom controls including SmartTextBlock,

Silverlight Toolkit - LongListSelector for infinite scrolling lists and bing maps control,

MVVMLight Toolkit - Laurent's great framework for making life with MVVM easier,

Reactive Extensions (Rx) - we use this for handling asynchronous calls and event subscriptions,

Visiblox - a great charting package for visualising data, big thanks to @ColinEberhardt,

Funq- a compact and fast DI container for WP7,

PreEmptive Solutions - post build weaving of runtime analytics into executables.

We're now working on a Mango release and hope to have this out in a couple of weeks and we're looking forward to performance improvements around HTTP compression support and fast app switching.

Until then happy property searching :)

Tessellating shapes on top of Bing Maps in a WP7 app - part 2

2011-11-03T15:47:00.000-07:00

In my previous post I showed how to tessellate polygons over Bing Maps control. This was a demonstration of how to achieving tessellation over the map control for a WP7 app. The problem is this is a sub-optimal solution from a UI perspective. This post shows how I've changed to code to use an asynchronous pattern for creating the polygons. The code is available for download.

The primary problem with the solution is not the actual calculation but 'where' the calculation was being performed. All the work was done on the main UI (Dispatcher) thread. Simply this means the app would freeze whilst calculating the required the polygons for the currently visible map area.

The secondary problem was overloading the UI thread with rendering requests. Obviously all the visible polygons need rendering to the screen, but if you chuck a lot of work at the UI thread nothing else in your app is going to be able to do any UI work until all those requests have been processed. This means at best you'll get a jerk response or at worst you'll app will freeze.

And finally there isn't any caching for already calculated polygons for a geo-location, why would we want to repeat the same work over and over again.

The first approach to address these issues is the introduction of a service interface exposing the polygon methods asynchronously:

public interface ICreatePolygons
{
    ISettings Settings { get; }

    Polygon Polygon(GeoCoordinate location, int sides, double diameter, double offset, double offsetBearing, double startAngle);

    IObservable<Polygon> Square(GeoCoordinate centre, double size);
    IObservable<Polygon> AdjacentSquares(Polygon polygon);
    IObservable<Polygon> TessellateVisibleSquares(LocationRect visibleRectangle, IList<Polygon> existingPolygons, double size);

    IObservable<Polygon> Hexagon(GeoCoordinate centre, double size);
    IObservable<Polygon> AdjacentHexagons(Polygon polygon);
    IObservable<Polygon> TessellateVisibleHexagons(LocationRect visibleRectangle, IList<Polygon> visiblePolygons, double size);

    IObservable<Polygon> Triangle(GeoCoordinate centre, double size);
    IObservable<Polygon> AdjacentTriangles(Polygon polygon);
    IObservable<Polygon> TessellateVisibleTriangles(LocationRect visibleRectangle, IList<Polygon> visiblePolygons, double size);
}

As you can see all the methods apart from the Polygon method all return the polygons using the Rx (Reactive extensions) approach. This allows the actual work of calculating the polygons to be done on a background worker thread and solve the primary problem with the previous solution - freezing of the UI.

Shown below is the Hexagon method, what you can see is how I schedule the work onto the thread pool using Rx:

public IObservable<Polygon> Hexagon(GeoCoordinate centre, double size)
{
    try
    {
        this.ValidateDatum();

        return Observable.Create<Polygon>(obs =>
        {
            var disposable = new BooleanDisposable();
            Scheduler.ThreadPool.Schedule(o =>
            {
                var polygon = CreateHexagonImpl(centre, size);

                if (disposable.IsDisposed)
                {
                    return;
                }

                obs.OnNext(polygon);
                obs.OnCompleted();
            });

            return disposable;
        });
    }
    catch (Exception exn)
    {
        this.log.Write(FailedHexagon, exn);
        throw new ServiceException(FailedHexagon, exn);
    }
}

The secondary problem is solved easily with the primary change in place. The addition of a pause to the thread calculating the adjacent polygons when tessellating the polygons for the map control.

Shown below is the recursive method used to calculate the visible adjacent polygons, what you'll see is the 'Thread.SpinWait' added every time an adjacent polygon is found and notified to any subscribers of the observer. This allows the background thread to cease work for a fixed amount of time (default is 66 ms) without causing a context switch. I found using a delay of 66 ms was enough to allow other threads\controls enough time to do their stuff, in my case this was allow the map control to render & download tiles and allow the use interact with the UI.

private void AddVisibleAdjacentPolygons(LocationRect visibleRectangle,
                                        Polygon polygon, ICollection<Polygon> newPolygons,
                                        Func<Polygon, IList<Polygon>> adjacentPolygonFunc,
                                        IObserver<Polygon> observer,
                                        BooleanDisposable disposable)
{
    foreach (var adjacentPolygon in adjacentPolygonFunc(polygon))
    {
        if (disposable.IsDisposed)
        {
            return;
        }

        if (!visibleRectangle.Intersects(adjacentPolygon.TileBoundingRectangle))
        {
            continue;
        }

        if (newPolygons.Contains(adjacentPolygon))
        {
            continue;
        }

        newPolygons.Add(adjacentPolygon);
        observer.OnNext(adjacentPolygon);

        Thread.SpinWait(this.settings.Throttle);

        this.AddVisibleAdjacentPolygons(visibleRectangle, adjacentPolygon, newPolygons, adjacentPolygonFunc, observer, disposable);
    }
}

The final problem is address by a standard pattern - caching. For this I'm using the WP7Contrib caching assembly. Before I show how I use the cache provider lets look at the generation times for different polygon tessellations.

Shown below is with no caching for the initial tessellation generation for 1 mile squares (on a device not in the emulator). As you can see the duration is 8247 ms:

When I move the map around in the local vicinity you can see the durations are about half of the start-up time when caching is not enabled:

When caching for adjacent polygons is enabled we get similar result for the initial start-up:

But when you compare the subsequent requests for the local vicinity you can see the time for generating the adjacent polygons has been reduced:

This demo makes use of the WP7Contrib in memory cache provider. The code for this demo app is available on SkyDrive.

Tessellating shapes on top of Bing Maps in a WP7 app

2011-10-28T09:37:00.000-07:00

Before I complete the 'How many pins can Bing Maps handle in a WP7 app...' set of posts. I want to take one last diversion and show how you can tessellate shapes on top of the Bing Maps control in a WP7 app. This builds on top of a previous post about drawing shapes on top of Bing Maps. If you're unsure what tessellation is, then the following definition should give you a good idea:

A tessellation is created when a shape is repeated over and over again covering a plane without any gaps or overlaps.

Only three regular polygons tessellate in the Euclidean plane: triangles, squares or hexagons. Shown below are some graphical examples of how these shapes tessellate:

I'm only going to show how you can tessellate these shapes on top of the map control. The effect will be rendered as a set of MapPolygon class instances. You could achieve a similar effect with a set of MapPolyline class instances and it would be probably a lot easier but, and it is an important 'but', if you use a MapPolyline you won't be able to use the polygon colour fill functionality. The MapPolygon instances are render as a layer on top of the map control, the control provides this functionality out of the box, this means the XAML is very clean and easy to understand:

As you can see the polygons are rendered as part of the MapItemsControl instance, the item source is bound to the Polygons property on the ViewModel. The item template is shown below and you can see this is also very simple. I've also included the brush definitions so you can see where the polygon colours are defined:

Before I dive into the code used to generate the polygons lets see the effect I'm going to generate, shown below are a set of tessellated shapes at different sizes. The density of polygons on the screen is dependent on the zoom level of the map control - here I'm using a default zoom level of 13 when the app starts, obviously you can zoom in and out as required and the polygons will automatically re size. This functionality is provided by the parent MapLayer class instance.

Here I'm using a set of pre-defined shapes, these are defined in the ViewModel constructor which is shown below. You can see each Shape class instance has a Name property and 2 function delegate properties - PolygonFunc and AdjacentPolygonFunc. This is the same style I used in the previous post.

public MapViewModel(ILog log)
{
    this.log = log;

    this.polygons = new ObservableCollection&lt;Polygon>();
    this.datum = new GeoCoordinate(51.54590803376571, -0.10334014892578125);
    this.Centre = new GeoCoordinate(51.561811605968394, -0.0883626937866211);

    this.Zoom = 13;
            
    this.shapes = new ObservableCollection&lt;Shape>
    {
        new Shape { Name = "No Shape", PolygonFunc = centre => new Polygon(), AdjacentPolygonFunc = centre => new List&lt;Polygon>() },
        new Shape { Name = "Square (100 m)", PolygonFunc = MapFuncs.Square(100), AdjacentPolygonFunc = MapFuncs.AdjacentSquares(100) },
        new Shape { Name = "Square (200 m)", PolygonFunc = MapFuncs.Square(200), AdjacentPolygonFunc = MapFuncs.AdjacentSquares(200) },
        new Shape { Name = "Square (500 m)", PolygonFunc = MapFuncs.Square(500), AdjacentPolygonFunc = MapFuncs.AdjacentSquares(500) },
        new Shape { Name = "Square (1 km)", PolygonFunc = MapFuncs.Square(1000), AdjacentPolygonFunc = MapFuncs.AdjacentSquares(1000) },
        new Shape { Name = "Square (1 mile)", PolygonFunc = MapFuncs.Square(1609.347), AdjacentPolygonFunc = MapFuncs.AdjacentSquares(1609.347) },
        new Shape { Name = "Triangle (3 sides, 500 m)", PolygonFunc = MapFuncs.Triangle(500), AdjacentPolygonFunc = MapFuncs.AdjacentTriangles(500) },
        new Shape { Name = "Triangle (3 sides, 1 km)", PolygonFunc = MapFuncs.Triangle(1000), AdjacentPolygonFunc = MapFuncs.AdjacentTriangles(1000) },
        new Shape { Name = "Triangle (3 sides, 1 mile)", PolygonFunc = MapFuncs.Triangle(1609.347), AdjacentPolygonFunc = MapFuncs.AdjacentTriangles(1609.347) },
        new Shape { Name = "Hexagon (6 sides, 500 m)", PolygonFunc = MapFuncs.Hexagon(500), AdjacentPolygonFunc = MapFuncs.AdjacentHexagons(500) },
        new Shape { Name = "Hexagon (6 sides, 1 km)", PolygonFunc = MapFuncs.Hexagon(1000), AdjacentPolygonFunc = MapFuncs.AdjacentHexagons(1000) },
        new Shape { Name = "Hexagon (6 sides, 1 mile)", PolygonFunc = MapFuncs.Hexagon(1609.347), AdjacentPolygonFunc = MapFuncs.AdjacentHexagons(1609.347) },
    };
    this.SelectedShape = this.shapes[5];
}

Hopefully the delegate method names are obvious, PolygonFunc calculates the geo-location points for the shape and the AdjacentPolygonFunc. The shapes are divided into 2 distinct groupings - squares and everything else. Squares are easy to calculate because you only have to calculate geo-locations for 4 points using constant bearings - 0, 90, 180 & 270. Everything else is where it starts to get complicated, you have to use a circle and calculate the position of each point on the circumference. The diameter for the circle comes from the defined size of the shape.

Shown below is the PolygonFunc method for creating a hexagon, as you can see the hexagon is generated using the Polygon method we also set the Height & Width of the generated polygon.

public static Func&lt;GeoCoordinate, Polygon> Hexagon(double diameter)
{
    Func&lt;GeoCoordinate, Polygon> func = location =>
    {
        var hexagon = Polygon(location, 6, diameter, 0, 0, 0);

        var north = hexagon.Locations[0];
        var south = hexagon.Locations[3];
        var east = hexagon.Locations[1];
        var west = hexagon.Locations[5];
              
        hexagon.Height = north.GetDistanceTo(south);
        hexagon.Width = east.GetDistanceTo(west);
                
        return hexagon;
    };

    return func;
}

The Polygon method is shown below, this is ultimately the same method used to create triangles as well as hexagons:

private static Polygon Polygon(GeoCoordinate location, int sides, double diameter, double offset, double offsetBearing, double startAngle)
{
    var centre = location;
    if (offset != 0)
    {
        centre = CalculateUsingHaversine(centre, offset, offsetBearing);
    }

    var polygon = new Polygon();

    var radius = diameter / 2;
    var angle = CircleInDegresses / sides;

    for (var i = 0; i &lt; sides; i++)
    {
        var aggregatedAngle = (i * angle) + startAngle;
        polygon.Locations.Add(CalculateUsingHaversine(centre, radius, aggregatedAngle));
        polygon.Centre = centre;
        polygon.TileBoundingRectangle = Square(diameter)(centre).TileBoundingRectangle;
    }

    return polygon;
}

For this demo I'm using the Haversine method for calculating distance between two geo-locations. There are more accurate ways to calculate geo-locations, I'm aware of the error factor (0.3 %) and happy to negate this for Haversine formula. The reason is simple - in a real-world app I won't be displaying a large number of polygons over a large areas (see the 'square 100 metre' in the above screenshot) so therefore the total distances calculated would not be large and the error factor would be small. Shown below is a screenshot of a single hexagon polygon rendered onto the map control.

The purpose of the AdjacentPolygonFunc method should be obvious - to calculate the adjacent polygons for an existing polygon. The implementation of this function depends on the type of polygon, the number of adjacent polygons for a square is different to a triangle or hexagon. Shown below are the rendered adjacents; I've added the order in which the adjacent polygons are calculated. An understand of the order of calculation is important when it comes to rendering the rest of the polygons for the visible map control.

As I said the adjacent methods are dependent on the type of polygon and calculating the adjacents for a square is the easiest. Shown below is the method used for adjacent hexagons. It requires not only the ability to calculate the polygon points but the ability to calculate the points in the correct geo-locations - the points have to be 'massaged' into the correction geo-locations.

public static Func&lt;Polygon, List&lt;Polygon>> AdjacentHexagons(double length)
{
    Func&lt;Polygon, List&lt;Polygon>> func = hexagon =>
    {
        var adjacentPolygons = new List&lt;Polygon>();
        GeoCoordinate deltaNorthWest;
        GeoCoordinate deltaNorthEast;
        GeoCoordinate deltaSouthWest;
        GeoCoordinate deltaSouthEast;

        // Calculate the horizontal distance between the edge of the hexagon and the edge of the bounding rectangle
        var eastEdge = new GeoCoordinate(hexagon.Locations.OrderByDescending(l => l.Latitude).Select(l => l.Latitude).First(),
                                            hexagon.Locations.OrderByDescending(l => l.Longitude).Select(l => l.Longitude).First());

        var horizontalDelta = eastEdge.GetDistanceTo(hexagon.TileBoundingRectangle.Northeast) * 2;

        // Calculate the vertical distance between the top of the hexagon and the top of the east edge
        var northEdge1 = hexagon.Locations.OrderByDescending(l => l.Latitude).First();
        var northEdge2 = hexagon.Locations.OrderByDescending(l => l.Longitude).ThenByDescending(l => l.Latitude).First();

        var verticalDelta = Math.Cos(DegreeToRadian(60.00)) * northEdge1.GetDistanceTo(northEdge2);

        // Calculate top centre hexagon position....
        deltaNorthWest = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Northwest, verticalDelta, 180);
        deltaNorthEast = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Northeast, verticalDelta, 180);

        var topCentre = AdjacentSquare(deltaNorthWest, deltaNorthEast, 0, 0, length);
        topCentre.Locations = Hexagon(length)(topCentre.Centre).Locations;

        // Calculate bottom centre hexagon position....
        deltaSouthWest = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Southwest, verticalDelta, 0);
        deltaSouthEast = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Southeast, verticalDelta, 0);

        var bottomCentre = AdjacentSquare(deltaSouthWest, deltaSouthEast, 180, 180, length);
        bottomCentre.Locations = Hexagon(length)(bottomCentre.Centre).Locations;

        // Calculate centre right hexagon position...
        deltaNorthEast = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Northeast, horizontalDelta, 270);
        deltaSouthEast = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Southeast, horizontalDelta, 270);

        var centreRight = AdjacentSquare(deltaNorthEast, deltaSouthEast, 90, 90, length);
        centreRight.Locations = Hexagon(length)(centreRight.Centre).Locations;

        // Calculate centre left hexagon position...
        deltaNorthWest = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Northwest, horizontalDelta, 90);
        deltaSouthWest = CalculateUsingHaversine(hexagon.TileBoundingRectangle.Southwest, horizontalDelta, 90);

        var centreLeft = AdjacentSquare(deltaNorthWest, deltaSouthWest, 270, 270, length);
        centreLeft.Locations = Hexagon(length)(centreLeft.Centre).Locations;

        // Calculate top right hexagon position...
        deltaNorthEast = CalculateUsingHaversine(topCentre.TileBoundingRectangle.Northeast, horizontalDelta * 4.225, 270);
        deltaSouthEast = CalculateUsingHaversine(topCentre.TileBoundingRectangle.Southeast, horizontalDelta * 4.225, 270);

        var topRight = AdjacentSquare(deltaNorthEast, deltaSouthEast, 90, 90, length);
        topRight.Locations = Hexagon(length)(topRight.Centre).Locations;

        // Calculate top left hexagon position...
        deltaNorthWest = CalculateUsingHaversine(topCentre.TileBoundingRectangle.Northwest, horizontalDelta * 4.225, 90);
        deltaSouthWest = CalculateUsingHaversine(topCentre.TileBoundingRectangle.Southwest, horizontalDelta * 4.225, 90);

        var topLeft = AdjacentSquare(deltaNorthWest, deltaSouthWest, 270, 270, length);
        topLeft.Locations = Hexagon(length)(topLeft.Centre).Locations;

        // Calculate bottom right hexagon position...
        deltaNorthEast = CalculateUsingHaversine(bottomCentre.TileBoundingRectangle.Northeast, horizontalDelta * 4.225, 270);
        deltaSouthEast = CalculateUsingHaversine(bottomCentre.TileBoundingRectangle.Southeast, horizontalDelta * 4.225, 270);

        var bottomRight = AdjacentSquare(deltaNorthEast, deltaSouthEast, 90, 90, length);
        bottomRight.Locations = Hexagon(length)(bottomRight.Centre).Locations;

        // Calculate bottom left hexagon position...
        deltaNorthWest = CalculateUsingHaversine(bottomCentre.TileBoundingRectangle.Northwest, horizontalDelta * 4.225, 90);
        deltaSouthWest = CalculateUsingHaversine(bottomCentre.TileBoundingRectangle.Southwest, horizontalDelta * 4.225, 90);

        var bottomLeft = AdjacentSquare(deltaNorthWest, deltaSouthWest, 270, 270, length);
        bottomLeft.Locations = Hexagon(length)(bottomLeft.Centre).Locations;

        adjacentPolygons.Add(topRight);
        adjacentPolygons.Add(centreRight);
        adjacentPolygons.Add(bottomRight);
        adjacentPolygons.Add(bottomLeft);
        adjacentPolygons.Add(centreLeft);
        adjacentPolygons.Add(topLeft);

        return adjacentPolygons;
    };

    return func;
}

So how I do generate all the adjacent polygons for the visible area of the map control?

Simply using one of favourite programming techniques - recursion!

This is were the order of creating the adjacent polygons becomes important. The pattern follows the principle of always creating the adjacent polygons for the current polygon and then moving to the next adjacent polygon and repeating ad infinitum. There is a break clause for the recursion to prevent an infinite loop - if the current polygon is not visible it does not calculate the adjacent polygons. This means only the visible polygons are calculated for the visible area of the map control.

Shown below is the visible order the polygons are calculated for all supported shapes, I've shown the first 12 polygons being calculated and rendered.

The first 12 squares:

The first 12 triangles:

The first 12 hexagons:

Shown below is the recursive method I use to calculate all the visible adjacent polygons. As you can see this method is short and concise - all the logic for creating the adjacent polygons is abstracted away in the AdjacentPolygonFunc. The only other logic is to work out if an adjacent polygon is visible on the screen, this uses the Intersects method on the bounding rectangle of the map control. To prevent an infinite loop occurring we also check to see if an adjacent polygon has already been created and added to the existing polygons list.

private void AddVisibleAdjacentPolygons(Polygon polygon, ICollection&lt;Polygon> existingPolygons)
{
    var adjacentPolygons = this.selectedShape.AdjacentPolygonFunc(polygon);

    foreach (var adjacentPolygon in adjacentPolygons)
    {
        if (!this.boundingRectangle.Intersects(adjacentPolygon.TileBoundingRectangle))
        {
            continue;
        }

        if (!existingPolygons.Contains(adjacentPolygon))
        {
            existingPolygons.Add(adjacentPolygon);
            this.AddVisibleAdjacentPolygons(adjacentPolygon, existingPolygons);
        }
    }
}

The only remaining visibility issue is the use of a 'datum' for tessellation. Wikipedia defines a 'geodetic datum is a reference from which measurements are made'.

In the examples above I'm using 'Highbury Corner' in central London as the datum point for tessellating shapes, this is why the polygons do not start in the centre off the visible bounding rectangle. The idea being where every I scroll the map control to, all the rendered polygons should start from this point.

Since it's possible I'm not rendering all the polygons between the datum and the centre of the visible bounding rectangle I need to be able to work out the closes point to the centre of the visible bounding rectangle when the datum point is not visible. This is achieved using geometry and Pythagoras theorem.

I need to be able to work out the shortest hypotenuse between the datum (start) and the centre of the visible bounding rectangle (end). The horizontal and vertical components of this hypotenuses has to be an absolute factor of the height and width of the polygon. Once this value is calculated I then use the Haversine formula to calculate the exact geo-location of the centre polygon.

public static GeoCoordinate CalculateClosestPolygon(GeoCoordinate start, GeoCoordinate end, Polygon polygon)
{
    var hypotenuse = start.GetDistanceTo(end);
    if (hypotenuse == 0)
    {
        return start;
    }

    var bearing = CalculateBearing(start, end);
    var absoluteBearing = Math.Abs(bearing);

    var vertical = Math.Sin(DegreeToRadian(absoluteBearing)) * hypotenuse;
    var horizontal = Math.Cos(DegreeToRadian(absoluteBearing)) * hypotenuse;

    var rectifiedHorizontalLength = RectifiedLength(horizontal, polygon.Width);
    var rectifiedVerticalLength = RectifiedLength(vertical, polygon.Height);

    var rectifiedHypotenuseLength = Math.Sqrt((rectifiedHorizontalLength * rectifiedHorizontalLength) + (rectifiedVerticalLength * rectifiedVerticalLength));

    var closestEnd = CalculateUsingHaversine(start, rectifiedHypotenuseLength, bearing);
    return closestEnd;
}

The final issue is really an observation about memory consumption - the more polygons I add to the map control the closer I get to the 90 Mb limit. As you can see from the screenshot above I managed to get the peak memory usage over 180 Mb! You can see from the output window in visual studio the reason why the right hand screenshot above peaks at such a high value, the number of visible polygons is over 3700!

This is another demonstration of the problems you can have with a data set with a large if not infinite size. To get round this issue I would limit the minimum size of the polygons depending on the zoom level of the map control.

If you've reached this far and are still wondering what's the use of tessellating polygons over the map control?

The simple answer is to cluster pins or other visual information that has a geo-location value. In the final 'How many pins can Bing Maps handle in a WP7 app...' I will show how you can conflate (cluster) large numbers of map pins for a relatively small visible area.

The code makes use of the WP7Contrib for the base class for the ViewModel & Model classes and is referenced as an NuGet packages. The code for this demo app is available on SkyDrive.

WP7Contrib: Added support for GZip compression to ResourceClient

2011-10-23T14:12:00.000-07:00

With the release of Mango for WP7 and a user request for GZip compression support in the contrib I've added GZip compression support to the ResourceClient in WP7Contrib.This means you can now request GZip compression for HTTP requests against back end web servers when using the ResourceClient in the contrib. All you have to do is specify 'WithGZip' method in the setup:

When you compare the debug statements in the output window of visual studio you can see the difference in HTTP response lengths, the first shows no compression and the second includes compression:

As you can see the HTTP response length drops from 43273 (bytes) to 8927 (bytes), this is obviously great not only from a performance point of view of the app but also from the cost to user, we have managed to lower their data usage.

This code is available in the GZipDemo app in the WP7Contrib Spikes directory (7.1).

WP7Contrib: URL shortening in a WP7 app

2011-10-16T12:59:00.000-07:00

I needed the ability to shorten a URL for a WP7 app the other day so I could share a URL via the ShareLinkTask, more info about this task can be found on MSDN. What follows is a solution to shortening a URL programmtically using tinyurl.com.

Obviously shortening a URL from a phone requires a connection, so this might not be applicable to a lot of apps. The problem is not the actual connection but the quality of said connection. When tethered or on WIFI the time required to shorten a URL is insignificant, but when on 3G the time is very noticable.

The solution I came up with allowed me to be abstracted away from the under lying HTTP request, infact it allowed me to write the code in 3 lines of code!

private void HandleShortenButtonClick(object sender, RoutedEventArgs e)
{
    this.tinyUrlShortener.Shorten(this.url.Text)
        .ObserveOnDispatcher()
        .Subscribe(u => this.shortenedUrl.Text = u);
}

The implementation for in the WP7Contrib is as follows, it uses the Rx (reactive extensions) async method to make the request over HTTP and process the response. If processing the response fails then the original URL is returned - if it fails to call the TinyUrl server it will return the original value as the shortened URL.

public IObservable<string> Shorten(string url)
{
    if (string.IsNullOrEmpty(url))
    {
        throw new ArgumentException("Can reduce a null or empty url!", "url");
    }

    try
    {
        this.log.Write(string.Format("TinyUrlShortener: Url - '{0}'.", url));
                
        return Observable.Defer<string>(() => Observable.Create<string>(obs =>
        {
            var disposable = new BooleanDisposable();

            try
            {
                var requestUrl = string.Format("http://tinyurl.com/api-create.php?url={0}", this.propertyEncoder.Encode(url));
                this.log.Write(string.Format("TinyUrlShortener: Tiny url - '{0}'.", requestUrl));

                var request = (HttpWebRequest)WebRequestCreator.ClientHttp.Create(new Uri(requestUrl));
                request.Method = "GET";
                request.AllowAutoRedirect = true;
                request.CookieContainer = new CookieContainer();
                        
                Observable.FromAsyncPattern(request.BeginGetResponse, ar =>
                {
                    try
                    {
                        var shortenedUrl = url;
                        if (disposable.IsDisposed)
                        {
                            return;
                        }

                        using (var response = (HttpWebResponse)request.EndGetResponse(ar))
                        {
                            if (response.StatusCode == HttpStatusCode.OK)
                            {
                                using (var stream = new StreamReader(response.GetResponseStream()))
                                {
                                    shortenedUrl = stream.ReadLine();
                                }
                            }
                        }

                        this.log.Write(string.Format("TinyUrlShortener: Shortened url - '{0}'.", shortenedUrl));
                        obs.OnNext(shortenedUrl);
                        obs.OnCompleted();
                    }
                    catch (Exception exn)
                    {
                        var message = string.Format(FailedRequest, exn.Message);
                        obs.OnError(new ServiceException(message, exn));
                    }
                })();
            }
            catch(Exception exn)
            {
                var message = string.Format(FailedRequest, exn.Message);
                obs.OnError(new ServiceException(message, exn));
            }

            return disposable;
        }));
    }
    catch (Exception exn)
    {
        var message = string.Format("TinyUrlShortener: Failed to shorten url, message - '{0}'.", exn.Message);
        this.log.Write(message);
        throw new ServiceException(message, exn);
    }
}

This has now been added to the WP7Contrib. There is an example of how to use this in the Spikes directory called 'UrlShortenerDemo'.

Drawing shapes on top of Bing Maps in a WP7 app

2011-10-16T11:54:00.000-07:00

Before I complete the 'How many pins can Bing Maps handle in a WP7 app...' set of posts. I wanted to show how I'm drawing shapes on top of the Bing Maps control in WP7. This is based around using the MapPolygon class in the Microsoft.Phone.Controls.Maps namespace, more info on MSDN. Basically this will drawn lines betweens the geo-locations defined in the collection exposed by the Locations property. You're also able to define other properties such as fill colour, stroke thinkness, opacity. With these you have the ability to really customize any polygon you render over the map control.

I'm going to show how I achieved the following screen shots and how this is all based around using the well known Haversine formula with only the centre location of the visible bounding rectangle of the Bing Maps control:

A couple of things to note, UI design is not my forte (as @RichGee will tell you) so the following is more about how to achieve it than what it finally looks like and secondly I'm using the Haversine formula to calculate geo-locations. This formula is not the most accurate available, but for my purposes the 0.3% error factor is acceptable. 'Movable Type' has a great page about lat & long formulas and calculations, more info here.

I've used MVVM pattern for this app so therefore I have a set of Model classes that are bounded to the View via the ViewModel. The app only has 1 View, 1 ViewModel and 1 Model class but the Model class uses both object orientated and functional techniques to achieve what I wanted.

The View has the map control and polygon defined in XAML as follows:

As you can see the map Centre property is bound to the ViewModel and the Locations property of the MapPolygon is bound to the Polygon geo-locations collection on the ViewModel.

The Shape Model class defines a couple of properties, one for the shape name and the second a function for calculating the geo-locations used to describe the polygon (shape). This is a function delegate because the geo-locations are generated dynamically at runtime and this depends on the current centre location of the map control.

public sealed class Shape : BaseModel
{
    private string name;
    private Func<GeoCoordinate, LocationCollection> polygonFunc;

    public string Name
    {
        get
        {
            return this.name;
        }
        set
        {
            this.SetPropertyAndNotify(ref this.name, value, () => this.Name);
        }
    }

    public Func<GeoCoordinate, LocationCollection> PolygonFunc
    {
        get
        {
            return this.polygonFunc;
        }

        set
        {
            this.SetPropertyAndNotify(ref this.polygonFunc, value, () => this.PolygonFunc);
        }
    }
}

Instances of this Model are populated in the ViewModel constructor using a set of static methods on a helper class. This helper class is where the smarts for calculating polygons is contained. As you can see from the code below I've created several different shapes in different sizes.

public MapViewModel(ILog log)
{
    this.log = log;

    this.polygon = new LocationCollection();
    this.Centre = new GeoCoordinate(51.561811605968394, -0.0883626937866211);
    this.Zoom = 15;
            
    this.shapes = new ObservableCollection<Shape>
    {
        new Shape { Name = "No Shape", PolygonFunc = centre => new LocationCollection()},
        new Shape { Name = "Square (50 m)", PolygonFunc = MapFuncs.Square(0.050) },
        new Shape { Name = "Square (250 m)", PolygonFunc = MapFuncs.Square(0.250) },
        new Shape { Name = "Square (500 m)", PolygonFunc = MapFuncs.Square(0.500) },
        new Shape { Name = "Circle (50 m)", PolygonFunc = MapFuncs.Circle(0.050) },
        new Shape { Name = "Circle (250 m)", PolygonFunc = MapFuncs.Circle(0.250) },
        new Shape { Name = "Circle (500 m)", PolygonFunc = MapFuncs.Circle(0.500) },
        new Shape { Name = "Pentangle (500 m)", PolygonFunc = MapFuncs.Pentangle(0.500) },
        new Shape { Name = "Star (5 points)", PolygonFunc = MapFuncs.Star(5, 0.500) },
        new Shape { Name = "Star (6 points)", PolygonFunc = MapFuncs.Star(6, 0.500) },
        new Shape { Name = "Star (7 points)", PolygonFunc = MapFuncs.Star(7, 0.500) },
        new Shape { Name = "Star (8 points)", PolygonFunc = MapFuncs.Star(8, 0.500) },
        new Shape { Name = "Star (9 points)", PolygonFunc = MapFuncs.Star(9, 0.500) },
        new Shape { Name = "Star (10 points)", PolygonFunc = MapFuncs.Star(10, 0.500) },
        new Shape { Name = "Polygon (4 sides)", PolygonFunc = MapFuncs.Polygon(4, 0.500) },
        new Shape { Name = "Polygon (5 sides)", PolygonFunc = MapFuncs.Polygon(5, 0.500) },
        new Shape { Name = "Polygon (5 sides, offset)", PolygonFunc = MapFuncs.Polygon(5, 0.500, 36) },
        new Shape { Name = "Polygon (6 sides)", PolygonFunc = MapFuncs.Polygon(6, 0.500) },
        new Shape { Name = "Polygon (7 sides)", PolygonFunc = MapFuncs.Polygon(7, 0.500) },
        new Shape { Name = "Polygon (8 sides)", PolygonFunc = MapFuncs.Polygon(8, 0.500) },
        new Shape { Name = "Polygon (9 sides)", PolygonFunc = MapFuncs.Polygon(9, 0.500) },
        new Shape { Name = "Polygon (10 sides)", PolygonFunc = MapFuncs.Polygon(10, 0.500) }
    };

    this.SelectedShape = this.shapes.First();
}

This collection of Shapes is then bound to the View via the Shapes property on the ViewModel. The View uses this as part of ListPicker to allow the user to select the current Shape. When a Shape is selected the ViewModel raises a property notify changed event to indicate the currently selected Shape should be re-drawn. The important part is the static class MapFuncs, this is where the smarts are. It uses the Haversine formula to calculate the polygons. The Haversine method is shown below along with a couple of hepler methods for converting degrees to and from radians. The Haversine formula calculates the geo-location given a start geo-location, distance and bearing on a sphere, the sphere in case is the Earth:

private static GeoCoordinate CalculateUsingHaversine(GeoCoordinate startLocation, double distance, double bearing)
{
    var lat1 = DegreeToRadian(startLocation.Latitude);
    var long1 = DegreeToRadian(startLocation.Longitude);

    var bar1 = DegreeToRadian(bearing);
    var angularDistance = distance / EarthRadius;

    var lat2 = Math.Asin(Math.Sin(lat1) * Math.Cos(angularDistance) + Math.Cos(lat1) * Math.Sin(angularDistance) * Math.Cos(bar1));

    var lon2 = long1 + Math.Atan2(Math.Sin(bar1) * Math.Sin(angularDistance) * Math.Cos(lat1),
                                    Math.Cos(angularDistance) - Math.Sin(lat1) * Math.Sin(lat2));


    var destinationLocation = new GeoCoordinate(RadianToDegree(lat2), RadianToDegree(lon2));

    return destinationLocation;
}

private static double DegreeToRadian(double angle)
{
    return Math.PI * angle / 180.0;
}

private static double RadianToDegree(double angle)
{
    return angle * (180.0 / Math.PI);
}

As I said earlier, the formula is then used to calculate the geo-locations which describe the required polygon (shape).

Method for creating polygon describing a Circle:

public static Func<GeoCoordinate, LocationCollection> Circle(double diameter)
{
    var radius = diameter / 2;
    Func<GeoCoordinate, LocationCollection> func = location =>
    {
        var locations = new LocationCollection();

        // Calculate the the location for each degree of a circle...
        for (var i = 0; i < 360; i++)
        {
            locations.Add(MapFuncs.CalculateUsingHaversine(location, radius, i));
        }

        return locations;
    };

    return func;
}

Method for creating polygon describing a Square:

public static Func<GeoCoordinate, LocationCollection> Square(double length)
{
    Func<GeoCoordinate, LocationCollection> func = location =>
    {
        var locations = new LocationCollection();

        // Calculate the mid points of the square...
        var halfLength = length / 2;
        var north = CalculateUsingHaversine(location, halfLength, 0);
        var south = CalculateUsingHaversine(location, halfLength, 180);
        var east = CalculateUsingHaversine(location, halfLength, 90);
        var west = CalculateUsingHaversine(location, halfLength, 270);

        // Use the mid points to calculate the corners of the square...
        locations.Add(new GeoCoordinate(north.Latitude, west.Longitude));
        locations.Add(new GeoCoordinate(north.Latitude, east.Longitude));
        locations.Add(new GeoCoordinate(south.Latitude, east.Longitude));
        locations.Add(new GeoCoordinate(south.Latitude, west.Longitude));

        return locations;
    };

    return func;
}

Method for creating any polygon, e.g. hexagon, heptagon, octagon etc:

public static Func<GeoCoordinate, LocationCollection> Polygon(int sides, double diameter, double startAngle)
{
    Func<GeoCoordinate, LocationCollection> func = location =>
    {
        var locations = new LocationCollection();

        var radius = diameter / 2;
        var angle = 360.00 / sides;

        for (var i = 0; i < sides; i++)
        {
            var aggregatedAngle = (i*angle) + startAngle;
            locations.Add(CalculateUsingHaversine(location, radius, aggregatedAngle));
        }

        return locations;
    };

    return func;
}

The following 2 are the most interesting, they are also the most complicated - Star & Pentangle (pentagram). The method for creating a Star polygon allows the number of points to be defined as well as the diameter (size). The Pentangle is a special case of a Star, it gives you a more natural looking star image. Wikipedia describes a pentagram as 'the shape of a five-pointed star drawn with five straight strokes.'

The difference between two is essential the ratio between the inner and outer points of the star - I'm sure there is a technical term for this but I'm not aware of the name. For the following Star polygons I've a ratio of 2/3 and for the Pentangle I've used 8/17 - this give the distinctive Pentangle shape:

Method for creating a Star polygon:

public static Func<GeoCoordinate, LocationCollection> Star(int sides, double diameter)
{
    return Star(sides, diameter, 0);
}

public static Func<GeoCoordinate, LocationCollection> Star(int sides, double diameter, double startAngle)
{
    return Star(sides, diameter, startAngle, ((double)2)/3);
}

private static Func<GeoCoordinate, LocationCollection> Star(int sides, double diameter, double startAngle, double ratio)
{
    Func<GeoCoordinate, LocationCollection> func = location =>
    {
        var locations = new LocationCollection();

        var outerPoints = new LocationCollection();

        // Calculate the outer points, these lie on the circumference of the circle
        // described by the diameter...
        var radius = diameter / 2;
        var angle = 360.00 / sides;
        for (var i = 0; i < sides; i++)
        {
            var aggregatedAngle = (i * angle) + startAngle;
            outerPoints.Add(CalculateUsingHaversine(location, radius, aggregatedAngle));
        }

        // Distance between 2 outer points...
        var distance = (outerPoints[0].GetDistanceTo(outerPoints[1])) / 1000;
        var side = Math.Sqrt((radius * radius) - ((distance / 2) * (distance / 2)));

        // Calculate the inner points and combine with outer points...
        var halfAngle = angle / 2;
        for (var i = 0; i < sides; i++)
        {
            var aggregatedAngle = (i * angle) + (startAngle + halfAngle);
            var point = CalculateUsingHaversine(location, (side  * ratio), aggregatedAngle);

            locations.Add(outerPoints[i]);
            locations.Add(point);
        }

        return locations;
    };

    return func;
}

Method for creating a Pentangle polygon:

public static Func<GeoCoordinate, LocationCollection> Pentangle(double diameter)
{
    return Star(5, diameter, 0, ((double)8)/17);
}

I included a couple of memory counters at the bottom of the demo app to observe the memory consumption when rendering polygons onto the map control. After showing 10 polygons on the map and then removing the polygon the following memory usage was observed. I was a little surprised by the increase of over 14 Mb in peak memory usage. I could see there being issues when rendering multiple polygons on the map control.

Removing the polygon from the map control was also not as straight forward as expected. I had to use the same pattern as described in this post. Clearing the contents of the geo-locations collection did not work, I had to clear it then add a single value back into the collection. I ended up with the following functionality:

public LocationCollection Polygon
{
    get
    {
        this.polygon.Clear();
        this.BuildPolygon().ForEach(this.polygon.Add);

        // If the 'no shape' is selected we need to force the polygon to be removed
        // this is done by adding a point, in this case the centre location.
        if (this.polygon.Count() == 0)
        {
            this.polygon.Add(this.centre);
        }

        return this.polygon;
    }
}

The code makes use of the WP7Contrib for the base class for the ViewModel & Model classes and is referenced as an NuGet packages. The code for this demo app is available on SkyDrive.

How many pins can Bing Maps handle in a WP7 app - part 2

2011-10-09T03:31:00.000-07:00

I wasn't planning this to span more than one post but it has and there's a good chance there'll be a third focusing back on the UI and how you can improve this further. This post is going to focus on what you can do with the service layer to improve the performance when loading a lot of pins into the Bing Maps control in a WP7 app.

To recap we reached a point where we are only showing the pins required for the bounding rectangle of the map control - even if the call to the service layer returned 500 hundred pins we were calculating which pins were actually visible and only adding them to the MapItemsControl class.

This was working well from a UI and general app perspective - we're no longer blocking the UI thread and we aren't chewing through to much memory. The main problem with this approach is the inefficiency in retrieving data from the UK crime web services. The data returned by these services is centred around the a geo-location for a radius of 1 mile, put simply they return all the reported crimes within a mile of a geo-location. The test location returns over 1000 crime geo-locations, we only want to show a subset of these, probably 150 or so. The screenshot from the last post shows this perfectly:

When I moved the map a request for more data is being made, even if I only move the map a couple of scrolls it is making a new request for data centred around the new geo-location. What became obvious was the actual data being displayed for this movement had already been requested previously. This forms the basis of the in-efficiency - requesting data that has already been requested by the app.

To recap we're getting the data when the ViewChangedEnd event is firing for the map control. We use the crime service in the service layer to request the data from the web services. It is then filtered before adding to the MapItemsControl class. I've shown a stripped down version of the call to the crime service in the service layer below:

private void HandleViewChangeEnd(object sender, MapEventArgs mapEventArgs)
{
    var criterion = new StreetLevelCrimeCriterion { Latitude = this.map.Center.Latitude, Longitude = this.map.Center.Longitude };
            
    this.crimeSubscriber = this.crimeService.SearchCrimeRelatedStreetLevelCrime(criterion)
        .ObserveOnDispatcher()
        .Subscribe(result =>
                        {
                            ...
                            ...
                            ...
                        });
}

What's required to prevent requesting the same data again and again (when scrolling) is caching in the service layer. The service layer should be able to workout what data you're requesting and then if the data has already been requested then it should return this already requested data instead of making a request to the back-end web services - standard caching pattern.

Now the service layer did have a caching pattern at the end of the first post. The problem is the cache key was based on an exact geo-location (contained in the Criterion class). So it would cache the crimes for a mile around an exact geo-location for every request. As you can imagine the chances of 2 requests being made with the same geo-location are very small:

var cacheKeyTuple = new CacheKeyTuple&lt;NeighbourhoodCrimeCriterion>
    {
        Name = "SearchNeighbourhoodCrimes",
        Value = criterion.DeepClone()
    };

    var cachedResult = this.cacheProvider.Get&lt;CacheKeyTuple&lt;NeighbourhoodCrimeCriterion>, NeighbourhoodCrimeResult>(cacheKeyTuple);
    if (cachedResult != null)
    {
        this.log.Write("UkCrimeService: SearchNeighbourhoodCrimes results retrieved from cache, hash code - {0}", criterion.GetHashCode());
        return Observable.Return(cachedResult).AsObservable();
    }

The screen shot below shows how inefficient this is. When the app is started in location 1 all the crimes within a 1 mile are requested around the map centre point (shown by the pins inside the red circle). When the map is scrolled to locations 2 & 3 then it shouldn't have to request more data from the back-end web services it should be returned from the cache.

So the output in visual studio is shown below, you can see the inefficiency in the multiple requests to the web services, I've also highlighted the geo-location information sent to the web services.

To make this more efficient we have to apply some high school mathematics - Pythagorean Theorem. We're going to use this to calculate the largest square we can get inside the circle described by the crimes returned from the back-end web service. Once we know the length of the side of the square we can use trigonometry to calculate the geo-locations of the corners of the square. Finally when we know this we'll be able to calculate if the map control bounding rectangle is contained within the square, if it is then we don't need to make a request to the web services we can use the cached data, if not then a request will be made to the web services for more data.

First, applying Pythagorean Theorem, we are going to use metric units so instead of a radius of 1 mile it will be 1.60934 km.

By the symmetry of the diagram the center of the circle is on the diagonal AB of the square. The length of AB is 3.21868 km and the lengths of BC and CA are equal. The Pythagorean Theorem then says that

(BC * BC) + (AC * AC) = (AB * AB)

Hence

(BC * BC) + (CA * CA) = 10.35990

But since this is a square then BC is equal to AC, hence

2 * (BC * BC) = 10.35990

and therefore

|(BC * BC) = 5.17995

Taking the square root on my calculator I get

BC = 2.27595

The square has the sides of length 2.27595 Km.

Second, we use trigonometry to calculate the geo-locations of the 4 corners of the square. We use the following Haversine formula to calculate these, don't worry I've implemented this in code. It's shown here for completeness:

	lat₂ = asin(sin(lat₁)cos(d/R) + cos(lat₁)sin(d/R)*cos(θ))
	lon₂ = lon₁ + atan2(sin(θ)sin(d/R)cos(lat₁), cos(d/R)−sin(lat₁)*sin(lat₂))

θ is the bearing (in radians, clockwise from north);
d/R is the angular distance (in radians), where d is the distance travelled and R is the earth’s radius

Finally, these have been implemented in the CircularLocation class. It allows the setting of the radius and centre point and it will calculate the largest contained rectangle inside the described circle. The full implementation is shown below:

public sealed class CircularLocation
{
    private const double EarthRadius = 6371;

    private GeoCoordinate centerPoint;
    private double radius;

    private LocationRect containedRect;

    public GeoCoordinate CenterPoint
    {
        get
        {
            return centerPoint;
        }
        set
        {
            this.centerPoint = value;
            this.containedRect = null;
        }
    }
        
    public double Radius
    {
        get
        {
            return this.radius;
        }
        set
        {
            this.radius = value;
            this.containedRect = null;
        }
    }

    public LocationRect ContainedRect
    {
        get
        {
            if (this.containedRect == null)
            {
                this.containedRect = this.CalculateContainedRect();
            }

            return this.containedRect;
        }
    }

    public bool IsRectangleContained(LocationRect boundingRectangle)
    {
        var containedRect = this.ContainedRect;

        if (boundingRectangle.North > containedRect.North)
        {
            return false;
        }

        if (boundingRectangle.East > containedRect.East)
        {
            return false;
        }

        if (boundingRectangle.South &lt; containedRect.South)
        {
            return false;
        }

        if (boundingRectangle.West &lt; containedRect.West)
        {
            return false;
        }
            
        return true;
    }

    private LocationRect CalculateContainedRect()
    {
        var hypotenuse = 2 * this.radius;

        var side = Math.Sqrt(hypotenuse * hypotenuse / 2);
        var halfSide = side / 2;

        var directNorth = this.CalculateDestination(this.centerPoint, halfSide, 0);
        var directSouth = this.CalculateDestination(this.centerPoint, halfSide, 180);
        var directEast = this.CalculateDestination(this.centerPoint, halfSide, 90);
        var directWest = this.CalculateDestination(this.centerPoint, halfSide, 270);

        return new LocationRect(directNorth.Latitude, directWest.Longitude, directSouth.Latitude, directEast.Longitude);
    }

    private GeoCoordinate CalculateDestination(GeoCoordinate startLocation, double distance, double bearing)
    {
        var lat1 = DegreeToRadian(startLocation.Latitude);
        var long1 = DegreeToRadian(startLocation.Longitude);

        var bar1 = DegreeToRadian(bearing);
        var angularDistance = distance / EarthRadius;

        var lat2 = Math.Asin(Math.Sin(lat1) * Math.Cos(angularDistance) + Math.Cos(lat1) * Math.Sin(angularDistance) * Math.Cos(bar1));

        var lon2 = long1 + Math.Atan2(Math.Sin(bar1) * Math.Sin(angularDistance) * Math.Cos(lat1),
                                        Math.Cos(angularDistance) - Math.Sin(lat1) * Math.Sin(lat2));


        var destinationLocation = new GeoCoordinate(RadianToDegree(lat2), RadianToDegree(lon2));

        return destinationLocation;
    }

    private double DegreeToRadian(double angle)
    {
        return Math.PI * angle / 180.0;
    }

    private double RadianToDegree(double angle)
    {
        return angle * (180.0 / Math.PI);
    }
}

This class is then used in the modified crime service as the key for an item added to the cache. When a request is made to the crime service it will recurse the keys added to the cache looking for an instance that
can contain the requested bounding rectangle of the map control - simple!

Obviously how the key is created and added to the cache has been modified, but this is nothing more than creating of an instance of the CircularLocation class and setting the required properties. Shown below is the crime service method.

public IObservable&lt;StreetLevelCrimeResult> SearchStreetLevelCrime(StreetLevelCrimeCriterion criterion)
{
    try
    {
        var centrePoint = criterion.BoundingRectangle.Center;
                
        var keys = this.cacheProvider.Keys&lt;CircularLocation>();
        var key = keys.FirstOrDefault(k => k.IsRectangleContained(criterion.BoundingRectangle));

        if (key != null)
        {
            var cachedResult = this.cacheProvider.Get&lt;CircularLocation, StreetLevelCrimeResult>(key);

            this.log.Write("UkCrimeService: SearchStreetLevelCrime results retrieved from cache, hash code - {0}", criterion.GetHashCode());
            return Observable.Return(cachedResult).AsObservable();
        }

        object[] @params = new[] { propertyEncoder.Encode(centrePoint.Latitude), propertyEncoder.Encode(centrePoint.Longitude) };
                
        return resourceHandlerFactory.Create()
            .ForType(ResourceType.Json)
            .UseUrlForGet(this.settings.StreetCrimeUrl)
            .WithBasicAuthentication(this.settings.Username, this.settings.Password)
            .Get&lt;List&lt;CrimeRelated.StreetLevel.Resources.Result>>(@params)
            .Select(response =>
            {
                var result = ProcessResponse(response);

                var circularLocation = new CircularLocation { CenterPoint = centrePoint, Radius = SearchDistance };
                var containedRect = circularLocation.ContainedRect;
                this.log.Write("UkCrimeService: SearchStreetLevelCrime contained rectangle - {0}", containedRect);

                this.cacheProvider.Add(circularLocation, result, this.cacheTimeout);

                return result;
            });
    }
    catch (Exception exn)
    {
        var message = string.Format(FailedPoliceStreetLevelCrime, exn.Message);
        this.log.Write(message);
        throw new Exception(message, exn);
    }
}

Now when I run the app I get better performance when scrolling within the calculated contained rectangle. Only when you're no longer inside the contained rectangle is a request for more data made to the back-end web services. This can be observed in the output window of visual studio. The highlighted area shows the cached results being returned, eventually I scroll outside of the contained rectangle and another request to the back-end web services is made.

Back to the original question - How many pins can Bing Maps handle in a WP7 app?

This post hasn't really changed the answer to this question from the previous post, it has shown you how you can be more efficient with your requesting of data when you're only showing a subset of the returned data.

Part3 will focus back on the UI and how conflation of pins can will help the user experience.

I've put the code for this version up on SkyDrive, you'll need a username & password for the UK crime stats service to run the code.

Observing network traffic for Bing Maps control in WP7

2011-10-05T13:12:00.000-07:00

Using the Bing Maps control in a WP7 app can incur a rather large memory cost when compared to the rest of an app. Typically I see an initial cost of approximately 8 Mb to show a full screen map when the zoom level is set to 16. This is not a concern, and in my opinion this shouldn't be either. Whats interesting to see is whats happen under the covers from a network perspective and to see if I can see any correlation. None of the following has any scientific basis, more a set of observations.

This is very simple to do, all we need to do is configure the WIFI on the device and then reconfigure Fiddler for remote connections. You can find all the detailed required in this great post by Eric Law.

For the observations I used a modified version of the app from the 'How many pins...' post I did a couple of weeks ago. It only shows the map control it does not display any pins.

When the app is initially installed and run for the first time I'm observing the following network traffic in Fiddler:

You can see there are approximately 35 requests for tiles when the app initially starts, as expected the low resolution tiles are requested first followed by higher resolution. Interestingly the largest tile in png format is only 25 Kb in size.Even if we multiplied 35 by 25 we don't get anywhere near the 8 Mb figure. Infact it only totals about 875 Kb. What we have to remember is, PNG is a bitmapped image format employing a lossless compression format.

Lets see the cost of loading one of these single tiles into an Image control, shown below is the tile and the a test app which loads the tile into the Image control when button the is clicked. I've also stuck on a couple of memory counters.

You can see from loading the image explicitly there is a memory cost associated approximately 600 Kb for this tile. If this was multipled by 25 we'd get a total memory cost of 15 Mb. This is a theoretical total figure but even if it was approaching half this size for the tiles downloaded in the Fiddler screenshot you can see the Bing Maps control is already managing the memory allocated internal already without even approaching the 90 Mb limit.

The next observation was around restarting the application. I observed the tiles were being cached for the app. Whether these are cached by the control for all apps or on a per app basis is unclear. Each response for a tile has HTTP caching directives and these state the tile can be cached for a year - 365 days. The screenshot show 2 restarts of the application, once immediately after closing the app and the second after rebooting the device.

The final observation is the most obvious as I scroll & zoom in and out of the map, I see alot of requests for tiles as expected, the interesting part is it appears the control makes maximum of 5 simultaneous requests for tiles. This was pretty hard to capture but the following screenshot shows 3 outstsanding requests:

Removing poly line from Bing Maps on WP7

2011-10-02T08:19:00.000-07:00

Showing a route line for a journey on a Bing Maps control in a WP7 app is relatively easy, especially if you use the WP7Contrib Bing Maps Wrapper service to call out to the Bing Maps RESTful API. It's not quite so easy to remove a route line from the control once displayed.

The background to this is in our WP7 app FINDaPAD (you'll need Zune installed) we have a page which shows the route to a property. We offer a driving route and a walking route - if it's walking distance! We don't display these routes together, they are mutually exclusive. When either of the icons is clicked to calculate the route we remove the existing route and display the new route once it has been calculated. The couple of screen shots below show 2 different routes between the same start & end locations depending whether you are driving or walking.

Shown below is a quick demo I knocked up to show the problem in more detail. This app displays a driving or walking app between the 2 UK cities Oxford & Cambridge. It also has a couple of buttons for Clearing the route line and what I call Resetting the route line. This is very similar to what we have in FINDaPAD.

The MapPolyline class in the Microsoft.Phone.Controls.Maps namespace use the Location property for the line drawn on top of the map. This is not a generic collection like IList or ObservableCollection it is of type LocationCollection coming from the same namespace.

So my definition of Clearing would be clearing contents of this collection. This is done in the 'Clear Route' button click event handler:

private void HandleClearRouteButtonClick(object sender, RoutedEventArgs e)
{
    this.routeResult.Text = string.Empty;
    this.routeMapRouteLine.Locations.Clear();
}

Unfortunately this doesn't do what I'd expected, it does not remove the overlaid map polyline. As you can see from the screenshot below the text showing the number of points and total distance has been removed but the line hasn't.

To get this to work I had to do what I define as Resetting the clearing of the collection but then adding back in a single value. It doesn't have to any particular value it could be anything that is a valid geo-location - not GeoCoordinate.Unknown.

private void HandleResetRouteButtonClick(object sender, RoutedEventArgs e)
{
    this.routeResult.Text = string.Empty;
    this.routeMapRouteLine.Locations = new LocationCollection {this.routeMap.Center};
}

I literally resetting the collection and adding the centre point of the map back in as the start of the poly line, this gives the expected UI response when 'Reset Route' button is clicked:

I've observed the same behaviour when using the MVVM pattern (FINDaPAD) or a code behind as in the above demo. I've included the code below for the demo, including the XAML.

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">

            <Microsoft_Phone_Controls_Maps:Map x:Name="routeMap"
                                               Height="400"
                                               VerticalAlignment="Top"
                                               ZoomBarVisibility="Collapsed"
                                               CopyrightVisibility="Visible"
                                               ZoomLevel="8"
                                               AnimationLevel="UserInput"
                                               HorizontalContentAlignment="Stretch"
                                               VerticalContentAlignment="Stretch">

                <Microsoft_Phone_Controls_Maps:MapPolyline x:Name="routeMapRouteLine"
                                                           Stroke="Green"
                                                           StrokeThickness="6"
                                                           Opacity="0.7" />

            </Microsoft_Phone_Controls_Maps:Map>

            <Button Content="Driving Route"
                    Height="72"
                    Margin="0,463,232,0"
                    Name="drivingButton"
                    VerticalAlignment="Top"
                    Click="HandleDrivingButtonClick" />

            <Button Content="Walking Route"
                    Height="72"
                    Margin="209,463,6,0"
                    Name="walkingButton"
                    VerticalAlignment="Top"
                    Click="HandleWalkingButtonClick" />

            <TextBlock Height="30"
                       Margin="12,427,6,0"
                       Name="routeResult"
                       VerticalAlignment="Top" />

            <Button Content="Clear Route"
                    Height="72"
                    HorizontalAlignment="Left"
                    Margin="0,529,0,0"
                    Name="clearRouteButton"
                    VerticalAlignment="Top"
                    Width="224"
                    Click="HandleClearRouteButtonClick" />

            <Button Content="Reset Route"
                    Height="72"
                    HorizontalAlignment="Left"
                    Margin="209,529,0,0"
                    Name="resetRouteButton"
                    VerticalAlignment="Top"
                    Width="241"
                    Click="HandleResetRouteButtonClick" />
        </Grid>

As I said earlier I've used the Bing Maps Wrapper service from the WP7Contrib, you can find out more about calculating routes and all the other functionality by reading a couple of posts by RichGee and this by me.

public partial class MainPage : PhoneApplicationPage
{
    private const string RouteResultFormat = "Route Points: {0}, Distance: {1} {2}";
    private const string RouteFailedFormat = "Route Failed: {0}";

    private readonly IBingMapsService bingMapsService;
    private readonly IRouteSearchCriterion drivingCriterion;
    private readonly IRouteSearchCriterion walkingCriterion;

    public MainPage()
    {
        InitializeComponent();

        this.bingMapsService = new BingMapsService("Your credentials", "Your app id");

        var start = new GeoCoordinate(51.754240074033525, -1.25244140625);
        var end = new GeoCoordinate(52.19413974159756, 0.1318359375);

        var waypoints = new List<WayPoint> { new WayPoint { Point = start }, new WayPoint { Point = end } };

        this.drivingCriterion = CriterionFactory.CreateRouteSearch(waypoints, ModeOfTravel.Driving);
        this.walkingCriterion = CriterionFactory.CreateRouteSearch(waypoints, ModeOfTravel.Walking);

        this.routeMap.Center = new GeoCoordinate(51.88369680508255, -0.4140472412109375);
        this.routeMap.ZoomLevel = 8;
    }

    private void HandleDrivingButtonClick(object sender, RoutedEventArgs e)
    {
        this.routeProgressBar.IsIndeterminate = true;

        this.bingMapsService.CalculateARoute(drivingCriterion)
            .ObserveOnDispatcher()
            .Subscribe(this.UpdateRouteResult, () => { this.routeProgressBar.IsIndeterminate = false; });
    }
        
    private void HandleWalkingButtonClick(object sender, RoutedEventArgs e)
    {
        this.routeProgressBar.IsIndeterminate = true;

        this.bingMapsService.CalculateARoute(walkingCriterion)
            .ObserveOnDispatcher()
            .Subscribe(this.UpdateRouteResult, () => { this.routeProgressBar.IsIndeterminate = false; });
    }

    private void UpdateRouteResult(RouteSearchResult result)
    {
        if (result.HasError)
        {
            this.routeResult.Text = string.Format(RouteFailedFormat, result.ErrorDetails);
            return;
        }

        if (result.HasPoints)
        {
            this.routeResult.Text = string.Format(RouteResultFormat, result.Points.Count, result.TravelDistance, result.DistanceUnit);
            this.routeMapRouteLine.Locations = result.Points;
            this.routeMap.ZoomLevel = 8;
        }
    }

    private void HandleClearRouteButtonClick(object sender, RoutedEventArgs e)
    {
        this.routeResult.Text = string.Empty;
        this.routeMapRouteLine.Locations.Clear();
    }

    private void HandleResetRouteButtonClick(object sender, RoutedEventArgs e)
    {
        this.routeResult.Text = string.Empty;
        this.routeMapRouteLine.Locations = new LocationCollection {this.routeMap.Center};
    }
}

WP7Contrib: Criterion Factory - calculating a Route

2011-09-29T04:39:00.000-07:00

Carrying on my series about the Criterion Factory in the WP7Contrib I thought I'd show the how we do a route search. We support multiple Criterion Factory methods for creating criterion these all depend on how much information you have available.

Calculating a route using Bing Maps REST API can be tricky and confusing there are over 10 optional parameters which you could configure to get a route between 2 locations. As with other sets of method on the Criterion Factory we've attempt to reduce the complexity by providing this abstraction.

Shown below are the methods on the Criterion Factory (for route search). As you can see all of the overloaded methods are rooted to final method which validates the Waypoints parameter. These are used like all other Criterion Factory methods to make creating criterion easier for use with the Bing Maps Wrapper service.

#region CreateRouteSearch

public static IRouteSearchCriterion CreateRouteSearch(IList<WayPoint> wayPoints)
{
    return CreateRouteSearch(wayPoints, ModeOfTravel.Driving, DistanceUnit.Kilometer, null, null, null, RoutePathOutput.Points, null, TimeType.Departure, null, null);
}

public static IRouteSearchCriterion CreateRouteSearch(IList<WayPoint> wayPoints, ModeOfTravel modeOfTravel)
{
    return CreateRouteSearch(wayPoints, modeOfTravel, DistanceUnit.Kilometer, null, null, null, RoutePathOutput.Points, null, TimeType.Departure, null, null);
}

public static IRouteSearchCriterion CreateRouteSearch(IList<WayPoint> wayPoints, ModeOfTravel modeOfTravel, DistanceUnit distanceUnit, Optimize? optimize)
{
    return CreateRouteSearch(wayPoints, modeOfTravel, distanceUnit, optimize, null, null, RoutePathOutput.Points, null, TimeType.Departure, null, null);
}

public static IRouteSearchCriterion CreateRouteSearch(IList<WayPoint> wayPoints, ModeOfTravel modeOfTravel, DistanceUnit distanceUnit, Optimize? optimize, Avoid avoid, int? heading, RoutePathOutput routePathOutput, DateTime? dateTime, TimeType timeType, int? maxSolutions, string pointOfInterest)
{
    if (wayPoints == null || wayPoints.Count < 2)
        throw new ArgumentException("Minimum number of WayPoints is 2.", "wayPoints");

    var criterion = new RouteSearchCriterion
    {
        TravelMode = modeOfTravel,
        DistanceUnit = distanceUnit,
        Optimize = optimize,
        Avoid = avoid ?? new Avoid(),
        Heading = heading,
        PathOutput = routePathOutput,
        DateTime = dateTime,
        TimeType = timeType,
        MaxSolutions = maxSolutions.HasValue ? maxSolutions.GetValueOrDefault() : 1,
        PointOfInterest = pointOfInterest
    };
    criterion.WayPoints.AddRange(wayPoints);
    return criterion;
}

#endregion

These methods allow you to easily create the required criterion for the Bing Maps Wrapper service. Obviously as your requirement gets more detailed you can specify travel types, places to avoid, road types to avoid etc.

The important and probably most complex parameter is the Waypoint list. As the names suggest all this is a set of location the route must contain. I hope its obvious but this list must contain at least 2 items - the start and destination locations for the route, you can't really have a route without these!

A Waypoint is simple the notion of a place of interest. It can be either exact geo-location specified by latitude & longitude, a landmark specified by a place name and\or post code or an address. Specifying a geo-location would be the most accurate but any of them will do.

The code below shows easy it is to get a route between 2 places with the Bing Maps Wrapper service - 8 lines of code including creating the criterion. This code is from an example called 'RouteSearch' in the Spikes directory of the WP7Contrib.

private void HandleCalculateRouteClick(object sender, RoutedEventArgs e)
{
    var waypoints = new List<WayPoint>
                        {
                            new WayPoint {Landmark = new Landmark {AreaName = this.startText.Text}},
                            new WayPoint {Landmark = new Landmark {AreaName = this.finishText.Text}}
                        };

    var criterion = CriterionFactory.CreateRouteSearch(waypoints);

    bingMapsService.CalculateARoute(criterion)
        .ObserveOnDispatcher()
        .Subscribe(this.DisplayRoute, this.FailedRoute);
}

This event handler is used for the following UI. This is a very simple UI, allows you to enter 2 locations and click calculate. If successful it displays the high level information about the route and then inserts the complete itinerary into a list box.

The DisplayRoute method is the Rx (reactive extensions) subscriber method, this does the binding of the results to the UI and is shown below:

private void DisplayRoute(RouteSearchResult result)
{
    this.resultStatus.Text = string.Format("Response: {0} - {1}", result.StatusCode, result.StatusDescription);

    if (result.HasSucceeded)
    {
        this.resultDistance.Text = string.Format("Distance: {0} {1}", result.TravelDistance, result.DistanceUnit);
        this.resultDuration.Text = string.Format("Duration: {0} {1}", result.TravelDuration, result.DurationUnit);

        this.resultRouteLegs.Text = string.Format("Iternary Count: {0}", result.RouteLegs[0].ItineraryItems.Count);

        this.routeLegs.ItemsSource = result.RouteLegs;
    }
}

I'm not going to go any further with examples of how to use the parameters you can specify with the Criterion Factory - hopefully they should be self explanatory.

What I am going to show is a real world example of where Rich & I are using the route search. This app is currently awaiting certification and therefore we don't want to release the name at the moment, hence the big black marks across the screen shots. The app uses the route search to find a route between 2 exact geo-locations. This is then overlaid as a set of pins and route line on the Bing Maps control. What is interesting with the results is the difference in total distance for each route - both routes start and end at the same locations but the difference is mode of travel. The left screenshot is by car and the right by foot.

As you can see from the code snippet below, we use the Criterion Factory and Bing Maps Wrapper service in exactly the same manner as the demo. Except this time we are specifying the Waypoints as exact geo-locations, the mode of travel and the distance units.

private void CalculateRoute(GeoCoordinate geoCoordinate)
{
    var waypoints = new List<WayPoint>
            {
                new WayPoint {Point = geoCoordinate},
                new WayPoint {Point = this.CurrentlySelectedProperty.GeoCoordinate},
            };

    var distanceUnit = this.settings.CurrentlySelectedCountry.IsMetric ? DistanceUnit.Kilometer : DistanceUnit.Mile;
    var modeOfTravel = this.IsCarRoute ? ModeOfTravel.Driving : ModeOfTravel.Walking;

    var criterion = CriterionFactory.CreateRouteSearch(waypoints, modeOfTravel, distanceUnit, Optimize.Time);

    this.bingMapService.CalculateARoute(criterion)
        .ObserveOnDispatcher()
        .Subscribe(this.ProcessResponse,
                   exception => this.FailedBingRouteSearch(exception, geoCoordinate),
                   this.CompletedBingRouteSearch);
}

If you want to use the demo you can, it can found in the WP7Contrib Spikes in the 'BingMaps_CriterionFactory' directory. You'll have to have a Bing AppID to use the service & demo, you can register here.

Geo-location on WP7 - don't trust the first value returned

2011-09-27T13:28:00.000-07:00

Rich & I have been working on app which makes heavy use of geo-location information provided by the GeoCoordinateWatcher class on the WP7 platform. As the documentation on MSDN states this class exposes the Windows Phone location services. The GeoCoordinateWatcher class implements the INotifyPropertyChanged interface and all the events generated will be fired on the UI thread allowing you to easily bind the class to the UI, but as we already knew this is not always a good idea - for a detailed reason why this can be a bad idea check out this post by Jaime Rodriguez.

What we also discovered is that you can't always trust the first position event generated by this class.

We have a requirement to get the current location when a user clicks a button, the user could do this at any time when using the application - they could click once, a dozen times or not at all. Every time they click the button we need to get an accurate single value. The accuracy of the value depend on both the actual value and the age of the value. Every value generated by the GeoCoordinateWatcher class is published by via the PositionChanged event and this is made up of 2 components - the location value and the timestamp when the location value was generated, this is exposed as the GeoPosition<T> class.

The PositionChanged event is defined as follows. I've included the StatusChanged event to show all the event signatures for the class:

public class GeoCoordinateWatcher : IDisposable, INotifyPropertyChanged, IGeoPositionWatcher<GeoCoordinate>

{
    public event EventHandler<GeoPositionChangedEventArgs<GeoCoordinate>> PositionChanged;
    public event EventHandler<GeoPositionStatusChangedEventArgs> StatusChanged;

    ...
}

The point of interest is the type used with the event handler. The GeoPositionChangedEventArgs class has the following definition.The Position property exposing the GeoPosition<T> value, this has the time stamp value.

public class GeoPositionChangedEventArgs<T> : EventArgs
{
    public GeoPositionChangedEventArgs(GeoPosition<T> position);
    public GeoPosition<T> Position { get; }
}

public class GeoPosition<T>
{

    public GeoPosition();
    public GeoPosition(DateTimeOffset timestamp, T position);
    public T Location { get; set; }
    public DateTimeOffset Timestamp { get; set; }
}

We use the following code to return a single geo-location value when the button is clicked. It uses Rx (reactive extensions) to wrap up the call to the GeoCoordinateWatcher class. We don't just use the 'FromEventPattern' Rx method because we don't want the instance of the GeoCoordinateWatcher running riot and generating a gazillion location results and killing the UI thread!

The highlighted areas show how I am using the time offset to determine the validity of the location published by the GeoCoordinateWatcher class. In this demo instance I am saying - 'if the position timestamp is greater than 20 seconds ago then ignore the value...'. When valid the new location is published using the Rx method 'OnNext' on the returned Subject<T>. We also call the Rx 'OnCompleted' method to make the 'Finally' method execute and shut down the watcher by calling 'watcher.Stop()'.

Note: We also do the 'Start' of the GeoCoordinateWatcher on a background thread to prevent blocking of the current thread - in this case the UI thread.

This class is the used in the page class as follows:

When run for the first time (on the emulator) I get the following in the output window of visual studio:

When this is run for subsequent times the debug statements in the output window of visual studio depend on how long the interval between clicking the button.

The following shows 2 values because the time interval between clicks is greater than 20 seconds. The first value generated by the instance of the GeoCoordinateWatcher class is ignored.

To show this is not an attribute of the currently executing application session, I've added an explicit finalise to the main page as well as a debug statement in the constructor. This shows that once the location services are initialised on the phone and the current location is requested then the last value is always stored by the device and published as the first event when the GeoCoordinateWatcher is started.

The above screen shot shows 3 distinct activations of the application after tomb-stoning the device twice.

As you can see the first run shows the last geo-location generated by the device was 4 hours prior, then we tomb-stoned the app for 30 seconds, then re-activated the app with a back press. Again because the previous geo-location was generated greater than 20 seconds ago it is ignored. Finally the last activation after tomb stoning was not greater than 20 seconds so it was not ignored.

This code has been incorporated into the WP7Contrib as the LocationService. It has method for getting the geo-location using time & distance thresholds as well. It also has provides the GeoCoordinateWatcher Status event as an observable method.

The code is available in this change-set or will be part of the 1.4 release due at the end of the month.