Readify's shared items in Google Reader

Log Tapping

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

Octopus uses log4net, my favourite logging library. It also performs a lot of background tasks - for example, deploying applications.

I wanted the output from log4net to be written to the event log (in the case of warnings/errors), as well as to the UI. However, I didn't want to end up with this:

log.Error(ex);
job.Output.Append(ex);

One of my tricks was to set up a "log tapper" - much like a wire tap. This allows me to "listen in" on the log4net chatter within a specific context. For example:

var output = new StringBuilder();

log.Info("Starting the job");

using (LogTapper.CaptureTo(output))
{
    log.Info("Doing the work...");

    someObject.DoSomethingThatAlsoHappensToLog();
}

log.Info("Finished the job");

The LogTapper sets up a scope - within the current thread, and as long as the using block is open, and log messages written by log4net will be appended to the StringBuilder in addition to their normal destinations.

Doing this means I can present the log4net output of a job in the UI, without it being mixed up with the output from lots of other jobs.

The LogTapper implementation is quite simple:

public class LogTapper : IDisposable
{
    LogTapper(StringBuilder builder)
    {
        ThreadContext.Properties["LogOutputTo"] = builder;
    }

    public static IDisposable CaptureTo(StringBuilder builder)
    {
        return new LogTapper(builder);
    }

    public void Dispose()
    {
        ThreadContext.Properties.Remove("LogOutputTo");
    }
}

ThreadContext is a log4net class, and it stores properties that are available to all log4net appenders on a per-thread basis.

To make the implementation work, I then set up a log4net Appender. Whenever a log is written, if a "log tapper" is active on the current thread, it will log the same message to the tapper:

public class LogTapAppender : IAppender
{
    public string Name { get; set; }

    public void DoAppend(LoggingEvent loggingEvent)
    {
        var capture = ThreadContext.Properties["LogOutputTo"] as StringBuilder;
        if (capture == null)
            return;

        capture.AppendLine(DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss") + " " + loggingEvent.Level.DisplayName.PadRight(6, ' ') + " " + loggingEvent.RenderedMessage);

        if (loggingEvent.ExceptionObject != null)
        {
            capture.Append(loggingEvent.ExceptionObject.ToString());
            capture.AppendLine();
        }
    }

    public void Close()
    {
    }
}

What I like about this approach is that all of my components just write useful information to the log4net ILog - they don't need to know if they are being called within the context of a UI, or a job, or any other alternative way of recording their progress. My higher-level controlling classes can siphon the output of any components they call into the place that makes the most sense for them.

Some early thoughts on Node.js

Mitch Denny — Mon, 10 Oct 2011 19:36:36 PDT

I’m pretty late to the Node.js party but I’ve found myself with some imposed free time this week so I thought I would spend some time getting across this newcomer. To get thing started I watch this video featuring Ryan Dahl. What follows is some reflection on what I see as the state of the platform.

Node.js is a Mashup

The first thing to remember is that Node.js is standing on the shoulders of giants. It hosts Google’s open source JavaScript engine (V8), so the runtime and the language are a known quantity – this is good! JavaScript performance has come a long way since I first starting dabbling with it.

Because they haven’t invented their own language, and because they haven’t invented their own execution engine I put Node.js in the mashup category – and in doing so made JavaScript easily available as a server-side programming language. Of course, no modern web platform is completely without a package management tool – here you’ll find this space filled by NPM.

Process Model and Hosting

Even though Node.js seems to be the new black, I think that is has some major hurdles to overcome around its process model. Each node process has one thread, so you might have a fantastically powerful box, but you aren’t going to be able to leverage it unless you are into cross process communication. Its easy enough to get Node to balance incoming requests across multiple processes using the “-balance” switch but if you do want to share data between those processes you need to serialise transmit and deserialise the data.

When you start working at massive scale those tend to be some of the problems you need to deal with anyway, especially in the area of distributed caching, but these are also problems that not everyone has. A vast majority of software developers out there work within enterprises writing relatively low-load applications that just get uploaded to a server somewhere and tick along. Mind you, by that logic a single process with a single thread might serve their purposes just fine

Ultimately – the thing that worries me is the assumption that server == application == process. When you have a dedicated web server infront of your web application platform it can do useful things like sharing the same port/URL space with multiple applications. You can patch through specific requests to Node JS and I see this becoming the most common hosting scenario for Node.js considering the kind of site density you get on some hosting providers.

Overall – I can’t see why Node.js won’t be a viable web development platform moving forward. I think problems are being solved almost as quickly as they are being discovered which is what happens when you start trying to solve real problems with a new technology.

Debugging

I’m actually very spoilt. I do most of my development with Visual Studio targeting the .NET platform, and Microsoft has bar none to most powerful debugging experience in any tool that I’ve ever used – so when I see things like “debugger;” in code I just want to cry. I suspect that debugger UX and debugger support are two completely different things. See, the UX that Microsoft has in Visual Studio has evolved for over a decade. The UX has been enhanced to support dealing with things like concurrency and adding first class support for TPL. Its hard for a newcomer to compete with hundreds of man years of investment, if I want to play with Node.js, I need to deal with a limited debugger experience.

What I didn’t know, and what I do find interesting however is the way that the V8 engine exposes debugger information in the form of a JSON messages. In theory you could build a bridge between Node/V8 to Visual Studio and end up with quite a powerful combination. The model is a lot like the profiler API in .NET actually.

Packages

Node.js by itself isn’t that interesting. Its got the fundamentals to get a server up and running, but if you commit to Node.js, you are also committing to learn at least half a dozen other frameworks in order to do something productive – same old story with any platform I guess.

A Final Thought – Why Bother

I think the novel thing about Node.js is the fact that it is a viable server-side JavaScript execution environment. I don’t think its process model has any special scalability benefits (at least not beyond what I am experience with in .NET), so for a .NET developer I have to ask the question – why would I bother? Natural geek curiosity is the first part of the answer, but a lot of good comes from investigating other platforms. Sometimes you pick up new techniques can be migrated back to your home turf, and vice-versa, and of course if Node.js really takes off (its getting some hot press these days) then you’ll be better prepared.

Filed under: Uncategorized

Switching to Trello

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

One of the things I'm noticing about running my Micro ISV is that I have to constantly change my mind :)

Until today I had been using AgileZen to manage the Octopus backlog. There is also a discussion board on Tender for people to post suggestions/ideas on improving Octopus.

AgileZen is great, but one of the downsides was that a suggestion would get added to the board, but people could never see how it was progressing or where it sat in the queue. There was also no voting, so I couldn't gauge how many people thought a suggestion was good.

Today I switched to Trello, which is very similar to AgileZen but also allows public visibility. I'm hoping this will create much more transparency in how Octopus develops:

View the Octopus Trello

If you create an account on Trello (or use your Google account) you can:

Vote for suggestions/features you like
Add comments to items
See how a suggestion progresses

Trello doesn't yet allow you to create new suggestions, so they should still be posted to the Octopus discussion board. I'll then add the suggestion to Trello so you can see how it progresses.

iPhone/MonoTouch Unit Testing with Team Foundation Server

uglybugger — Sun, 25 Sep 2011 16:19:59 PDT

I know, I know: apples, oranges etc. It’s not really, though – this is actually quite straight-forward. But first, some background.

I was recently involved in building another iPhone application for an enterprise customer. We had previously dealt with that customer and had a good working relationship and level of trust with them, but a huge part of that trust was the visibility that we provided as to what was going on. It’s mostly off-topic for this post, but the way we did it involved using Team Foundation Server, giving the client’s people accounts and making sure that the client’s product owner could log in at any time and see how the project was going.

With the iPhone application, we wanted to do exactly the same. The problem was that we hadn’t had that much experience using TFS to build iPhone apps. Most of our collective efforts had either been in Objective C using git (the stock-standard approach that Xcode pushes) or C#/MonoTouch using Mercurial (my experience). While both of those approaches are fine for personal and small projects, we really wanted all the other bonus points that TFS provides (continuous integration, work item tracking, reporting, web-based project portal etc.)

So how’d we do it? Well, the first thing to note is that we’re not actually building the application bundle using TFS – yet. That still requires a MacBook, MonoDevelop and a bunch of other stuff. We’ll probably get there soon using custom build tasks, rsync, ssh and a few other things, but we’re not quite there yet.

What we do have is a working continuous integration and nightly build, plus running tests using MSTest. The nice thing is that it actually wasn’t that hard.

Open the project in Visual Studio (not MonoDevelop). You’ll probably need something like Chris Small’s MonoTouch Project Converter to make this work happily.
Include monotouch.dll in your /lib directory and reference it from there rather than from the GAC. (It won’t be in the GAC on your build server, and nor should it be.)
If you have other dependencies (e.g. System.Data), copy those from your MacBook into /lib as well and reference those from there.
Done :)

The key point to note when you’re building your app is that you’re not going to be able to easily test your ViewController classes using MSTest, so make them dumb. If there’s business logic in there, extract it out into your domain model. If there’s data access logic in there… well… you’re doing it wrong anyway and you should definitely extract that out :)

You’ll end up with an app that has a dumb(ish) UI shell wrapped around a bunch of well-tested business logic classes. The added bonus of doing it this way is that you can then re-use a lot of that code when you write your WP7 or Android version.

The outcome? The visibility we wanted from the reporting and work item tracking side of things, plus a CI build that didn’t require witchcraft to configure, plus automated unit tests.

The only real down-side of this approach is that the build we’re unit-testing isn’t the build we’re shipping – we still have to build that manually on a MacBook somewhere. It does, however, give us a good indication of our overall code quality and a reliable safety net for refactoring.

5 Minute Screencast: Stop helping your users. Help yourself.

Tatham Oddie — Wed, 14 Sep 2011 16:23:10 PDT

A few weeks ago I spoke at Web Directions’ What Do You Know event. The event consisted of 10 speakers each doing a 5 minute presentation about some technique or idea that they find useful in web development.

Here’s my talk:

Ros Hodgekis won the night with her awesome email-related talk (all delivered with champagne glass still in hand):

Octopus: V1 backlog

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

When I started building Octopus and released a first beta, I had a pretty rough idea of what Octopus would be about. The beta experience has definitely shaped the product, and I'm much happier with the result that has been created by so much good feedback from the Octopus beta testers. Last week I had a couple of really useful phone calls with Octopus users, and I used some of that feedback to come up with a list of features that will make the final 'v1' cut of Octopus.

What does v1 actually mean?

Octopus currently has version numbers starting with 0.8, suggesting it's still in beta. Octopus 1.0 will be the version that is ready for production use (though a few companies are already using Octopus in production at the moment). The 1.0 builds will also be the first builds where a license key will be required to unlock multiple projects. But in truth, there will still be new builds every few days after 1.0, and the product will continue to evolve incrementally.

V1 features

Before 1.0 is stamped, I'll add the following 'big' features:

Auto upgrade Tentacle
Tentacles will be automatically kept up to date with the Octopus (as per this blog post).
Ad-hoc PowerShell execution on Octopus
As a user, I can define a deployment step that involves executing arbitrary PowerShell scripts on the Octopus, so I can perform tasks like configuring load balancers.
Role based security
Create application-managed groups of Windows groups/users, and give them project/environment permissions - e.g., only 'Release Managers' can deploy Project A to Production (suggestion)
Pre-defined variable substitutions
For example, you can define VarA = Hello${VarB}, and a number of useful pre-defined variables will be available (current path, date, etc.) (suggestion)

Those features will be built first, so they have the most time to be tested and to get feedback on.

The following small features/bug fixes are also going to be added:

Download log files
When viewing the results of a deployment, instead of trying to read the results in my browser, I'd like a link to download the output as a .txt file that I can open in my preferred text editor (suggestion)
Show NuGet descriptions
When viewing a release, I want to see the the NuGet package description and release notes in the 'Packages' tab (suggestion).
Proxy server support
Ensure Octopus can contact Tentacles and NuGet repositories via the default proxy server (suggestion)
Command line
A command line Tentacle.exe, and a command line Octopus.exe, for programmatically executing a deployment (either locally or remotely) (suggestion)
Project clone
Create a copy of an existing project to reduce effort required. Useful for example when setting up deployment of a branch of the same code (suggestion).

There are also some small usability features, like better rendering of times, making it obvious deployment steps can be sorted using drag and drop, better naming of some buttons, and adding a favicon.

There's also a nice long backlog of post-v1 features, such as automatic deployments, pull-based deployments,

I estimate that this will take 6 to 8 weeks. Tomorrow I'll announce a special discount that will apply until v1 is released.

What price Cloud?

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

I wanted to set up the infrastructure for Octopus properly. This meant that I needed:

A SQL server
A TeamCity server
A Web server or two (for OctopusDeploy.com)
A domain controller
A handful of servers for an Octopus test farm

Some of these servers are public, most would be private. I just moved overseas so I didn't want to put another server in my living room. I started by looking at some cloud providers. Here are some really rough, back-of-the-envelope calculations (for Windows servers):

Provider	CPU	RAM	Per hour	Per month (750 hours)
Amazon EC2	1 core	1.7gb	$0.12	$90
Azure Compute	1 core	1.75gb	$0.12	$90

Discounts are available if you buy spot instances or reserve hours, but from what I can gather, I'd be looking at $400-$500/month to have half a dozen 'small' servers on the cloud.

For my needs, it turned out to be cheaper to rent a high-spec dedicated server, and to have my own mini-cloud. LeaseWeb came to the rescue - for the last three months I've been renting a Quad core, 24GB RAM server for €190 (about $270 today). With 24gb I can run 10 'small' Azure instances, or about $900 worth of 'cloud'. What I do miss out on is the rapid provisioning. If I needed a second of these servers, it could take over a week to provision one.

If Octopus was a cloud service, I'd definitely look at offloading this to a real cloud provider. But for running TeamCity and a handful of test VM's, it appears to me that putting a server in a data centre is still more cost effective. Is that your experience?

WP7 Essentials Settings Provider

Jake Ginnivan — Fri, 09 Sep 2011 16:14:14 PDT

Settings Provider?

The settings provider is a port from the FunnelWeb settings provider to Windows Phone. It is a really simple interface

public interface ISettingsProvider
{
    T GetSettings<T>() where T : ISettings, new();
    void SaveSettings<T>(T settings) where T : ISettings;
}

So what does T actually look like:

public class ApplicationSettings : NotifyPropertyChanged, ISettings
{
    [DefaultValue(5)]
    [DisplayName("Number Results")]
    public int NumberResults { get; set; }

    public string Nickname { get; set; }

    [DefaultValue(true)]
    [DisplayName("Enable Stuff")]
    public bool EnableStuff { get; set; }

    public DateTime? Birthday { get; set; }

    [DisplayName("Some Options")]
    public Options SomeOptions { get; set; }
}

public enum Options
{
    Value1, 
    Value2
}

Pretty easy right? We can use NotifyPropertyWeaver to keep the class nice and clean. Then to fetch or persist our settings we just need to do

var applicationSettings = settingsProvider.GetSettings<ApplicationSettings>();
applicationSettings.SomeOptions = Options.Value2;
settingsProvider.SaveSettings(applicationSettings);

The Settings Provider is limited to types supported by the Convert.ChangeType method (for a number of reasons, if this is too restrictive, let me know and why).

So in the last release we added the SettingsList control, which will generate this for you (just the settings control, not the page, highlighted in red is what you get generated)

This is a first cut, and over time I will polish this page, and add support for ordering the properties and stuff (or feel free to submit pull requests :)). But I recon this is pretty cool for a first cut.

Also the reason I am using a combobox instead of the ListPicker is there is a bug where the control simply doesn't work inside a scroll viewer. Bah. Anyone interested in doing a community fork which simply fixes bugs in the toolkit and doesn't add any new features?

Get it

This control is in a separate package (to keep the essentials package lean and mean :P).

Install-Package WindowsPhoneEssentials.Controls.Settings

Codeplex
NuGet

Octopus: Keeping Tentacles up to date

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

In Octopus, you use one central web portal to push NuGet packages out to many servers. On each server is a "Tentacle", a little Agent that receives NuGet uploads, and installs and configures packages according to conventions.

One of the annoying things about Tentacles at the moment is that as you get more than a few of them, the upgrade experience isn't very nice.

First you download the new Octopus installer
Remote desktop to the Octopus server and install it
Now download the new Tentacle installer
Remote desktop into every single staging/test/production server, and install it

Improving the upgrade process

I'd like to make this process easier, so I'm using this blog post as a way to come up with a solution. I'm going to make use of bootstrapping - that is, I'm going to use Tentacle to install Tentacle.

Currently, the Tentacle is a Windows Service EXE that works something like this:

It starts
It hosts a WCF service (net.tcp on port 10933)
Packages are uploaded to it, and it installs them

Bootstrapping the Tentacle

To allow Tentacle to bootstrap itself, I'm going to do two things:

Turn Tentacle into a Console App instead of a Windows Service
Create "Suction cup" - a bootstrapper Windows Service that launches Tentacle

New installs

When you first install Tentacle to your test/staging/production server, the MSI will include a bundled NuGet package. On start-up, Suction Cup will install the package using the standard conventions. Then it will launch Tentacle.exe as a child process (much like IIS's main process launches each ASP.NET application pool child process).

Upgrades

Suppose a few weeks later, you download and install a new version of Octopus. The Octopus will include a Tentacle NuGet package matching the Octopus version. You can then navigate to the Environments page in Octopus, and click a button to deploy the new Tentacle package.

Now, here's the interesting bootstrapping part:

Tentacle (v1) will deploy Tentacle (v2) to a side-by-side folder
Tentacle (v1) will shut itself down (Environment.Exit(0))
Suction Cup will realize that the Tentacle child process has shut down
Suction Cup will find the latest installed version of Tentacle (now v2) and launch the new child process

Notes

This has some added benefits - for example, if something catastrophic happened during a deployment and Tentacle crashes, Suction Cup will automatically restart it.

One thing I'll need to detect is that if Tentacle repeatedly crashes in a short period of time, e.g., 5 times in 30 seconds, Suction Cup should wait a while before trying again - this way we don't fill up the event log.

Finally, since Suction Cup itself isn't upgraded during this process, I'm going to go with the approach that Suction Cup just needs to be 100% perfect from day 1 :)

Octopus: planning for v1

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

Since I started working on Octopus, I've been using AgileZen as a task board. The graph below gives an idea of how the work has progressed:

There are a few nice things this graph suggests:

The backlog is always growing thanks to great suggestions from the beta testing group
The archive is also always growing, because work is actually getting completed

(The slowdown in change during July/August is due to my moving overseas)

On a fixed time, fixed scope project I'd ideally want to see backlog growing much slower, if at all, as the project nears completion. For product development, however, I think it's actually healthy for the backlog to be growing as quickly as the 'done' column.

So far I've been following this methodology, but as I prepare for an Octopus version 1.0, I want to get a little more disciplined about my process. One of the things I miss working as a one-man-band is the "closure" that comes when working on actual sprints - the sprint planning and sprint review sessions in Scrum are a good way to book-end a few weeks of work.

To improve my process, here's what I am going to start doing:

Run two-week 'sprints'
On the first Monday, choose the work to do, and move it from the backlog to the 'Sprint' column
Post the sprint plan on my blog
Do the work
On the last Sunday (since most of the Octopus work is done on weekends), move work from 'done' into 'archive'
Send an email to the beta testing list with what features were completed, so people know what to expect
Celebrate with cake

During the two weeks I'll also spend a good amount of time on support (I'll blog about how I use Tender for that), so each sprint probably won't go exactly as planned.

How do you approach your personal projects? What else could I do to improve my process? My first 'sprint' should start on Monday, 12th September.

My Sessions at TechEd 2011

Jake Ginnivan — Mon, 29 Aug 2011 05:27:55 PDT

DEV304 - Adding Value to Software Projects with VSTO (Wed, 11:30am)

This sessions will have something for everyone, if you have never used VSTO and are interested in it, I will be showing the value it has. If you have used it, and hated it, I will also be showing how to improve your experience and give you a way of approaching the problems and some nice ways to improve the default experience. Part of this is a quick intro to COM Interop, how it works and how to make sure you avoid problems with it. And finally, I will be showing a bit of VSTO contrib and how you can use IoC and other cool enhancements to the platform.

WPH305 - Multi-Tasking and Application Services (Fri, 8:15am)

In this session with Chris Walsh, we will be going through a whole lot of App services related features in Windows Phone Mango. We will cover things like Multi-Tasking, Background agents, Tiles, Notifications and Search extra's. We have some cool demo's and it will be a fun session.

Demos

I also have a few demo's lined up - Unit Testing with WP7 (1:30pm Wednesday) - Windows Phone MVC Intro (2:00pm Wednesday)

Unit Testing with WP7 (1:00pm Wednesday)
Windows Phone MVC Intro (1:30pm Wednesday)

If you attend, feedback is always welcomed and please submit your evals, it helps us as speakers a lot.

New Octopus build, website and screenshots

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

New builds of Octopus are available immediately from my CI server, and can be downloaded from the Octopus downloads page. Every couple of weeks, though, I'll publish a short list of what's going on.

The last couple of weeks saw a lot of new features added.

A dashboard, to give you a high level overview of which projects are deployed to what environment.
Edit release notes for releases that have already been created.
Scope variables on a per-package basis, in addition to per-environment and per-machine
A more streamlined release user experience

A number of bug fixes and tiny enhancements are also included, from a quick list of projects that appear when you hover over the Projects tab, to correctly uninstalling old NuGet packages.

Below is a screenshot of the new dashboard - you can see larger versions of this screenshot and more on the Features page of the new Octopus website.

Why Octopus?

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

Decades from now, I want the IT industry to be known not just for its innovation and creativity, but for its ability to deliver software projects reliably. There's a lot of work to do, and I think Agile principles of frequent, high-quality collaboration and embracing change are playing a big part in getting us there. Along with the human to human improvements, we're also adopting engineering practices to boost our chances of success - source control, continuous integration, and unit testing for example make an enormous difference.

Delivering even a small software project is a huge undertaking. There are an unlimited number of practices that we'd like to adopt, but since time is always so critical, we always have to make trade-offs. In my experience, there's one practice that always falls into the too-hard basket: automated deployment.

The state of the art in deployment on the .NET stack leaves a lot to be desired. At big companies and small, I see programmers routinely remoting into production machines to patch configuration files, or writing long and semi-complete documents because automating deployments was too time consuming. After months of repeated test deployments, production deployments still fail and are rushed because of bad automation or incomplete documentation. It's hampering our ability to deliver and give our customers confidence. We can do better.

I believe wholeheartedly that automated, frequent, repeatable deployments is one of the most important practices we can follow. There's no compelling, standardised, complete solution out there, and I don't know if Octopus will ever become one either. But I know that we as an industry would be much better off if we could nail this problem, and I'm going to try my best to do something about it.

Crash Logging in a MonoTouch App

uglybugger — Fri, 26 Aug 2011 18:23:00 PDT

Customer: Your app crashed again.
Developer: How? What were you doing when it crashed? What happened?
Customer: I don’t know. I was playing with it and it crashed.
Developer: Do you remember which page you were on?
Customer: ?
Developer: *bangs head against wall*
Sound familiar?
One of the first things I do when I start a project (or when I inherit one) is set up logging. You’d be amazed and depressed at how many projects just don’t have any, or bolt it on as an after thought. Here’s a hint: it’s much easier to debug your app while you’re developing it if you know where it’s breaking. Ground-breaking, I know
There are a couple of things we want to do:

Log when the app crashes. Do it quickly and reliably, and don’t rely on any app infrastructure (e.g. injected loggers) as it’s already been torn down at this point.
Send the log message the next time the app starts. This will allow us to use all our nice web services etc. and means we can use just the one logging mechanism rather than having several different ones.

MonoDevelop creates a fairly standard-looking Main.cs for us:

Let’s change that to add a simple try/catch block:

The key here is line 11 – it makes it simple and obvious as to what it’s doing.
So… the CrashLog class itself is a static class and doesn’t do very much at all. The idea is that it’s simple to call and doesn’t rely on having any of the app’s components still available.

We’re using the My Documents special folder as that’s where we’re reliably allowed to write things to on the filesystem.
So now that we have our crash logger, let’s hook things up so that we can log when the app starts again. In our AppDelegate class:

Yes, we’re using our IoC container as a service locator. This isn’t good, but we can’t use constructor injection in our AppDelegate as it’s the class responsible for creating our IoC container.
So how does the logger work? Well, that’s up to you. You can choose to make a web-service call; you could spit it to another text file and periodically upload it; you could even send an email if you really wanted to.
My preference is using a web service as I tend to just hook it straight to the server-side logger (which usually uses log4net under the covers), but your mileage may vary.
The next time a customer tells you that your app crashed, though, you’ll be able to respond with, “I know – and I’ve already fixed that bug.”

An iPhone Eye for the C# Guy at @dddbrisbane

uglybugger — Fri, 26 Aug 2011 17:28:17 PDT

I just submitted this abstract for DDD Brisbane 2011. Don’t forget to vote for me!

An iPhone Eye for the C# Guy

iPhone Development using MonoTouch

This session will cover the basics of developing an iPhone application using C#/MonoTouch, from how to create a “Hello, world!” app through to a look at a real-world, production codebase.

We’ll cover the use of web services, threads, databases, generics (yes, you can use generics), reflection, inversion of control (yes, you can use IoC, too!) and general application architecture, and finish with a look at some tools, tips and tricks to make life as an iPhone developer much less painful.

This session will assume prior knowledge of threading, reflection, generics, inversion of control and why you'd want to use all of these, but don't let that scare you :)

A Lap around business Connectivity Services in SharePoint 2010

Nalaka Withanage — Tue, 23 Aug 2011 17:39:27 PDT

Here’s is my slide deck and the Resources from the SharePoint Saturday Sydney 2011. Thank you for those who attended and voted for this session.

BCS Overview	http://technet.microsoft.com/en-us/library/ee661740.aspx
Plan to upgrade BCS	http://technet.microsoft.com/en-us/library/ff607947.aspx
BCS Resource Centre	http://msdn.microsoft.com/en-us/sharepoint/ff660755.aspx
BCS Video – Secure Store	http://blogs.msdn.com/b/bcs/archive/2010/05/06/bcs-team-channel-secure-store-service.aspx
BCS Security Overview	http://technet.microsoft.com/en-us/library/ee661743.aspx
How BCS & Azure play together	BCS Azure Integration

Tagged: Azure, BCS, Presentations

MultiTargeted WP7 Project

Jake Ginnivan — Mon, 22 Aug 2011 16:01:24 PDT

I saw Shawn Wildermuth's post on maintaining a project targeting multiple versions of windows phone, I thought I would share the way I do it as I think it is far easier than the alternatives. http://wildermuth.com/2011/08/23/MaintainingaProjectwithTwoWindowsPhone_Versions

Multi-Targeted .csproj file

First off I open up my .csproj file and add this under the initial property group

<TargetFrameworkProfile Condition="'$(TargetFrameworkProfile)' == ''">WindowsPhone71</TargetFrameworkProfile>

This means I target Windows Phone 71 by default, then I modify the define constants property under each build configuration to be conditional:

<DefineConstants Condition="'$(TargetFrameworkProfile)' == 'WindowsPhone'">TRACE;SILVERLIGHT;WINDOWS_PHONE</DefineConstants>
<DefineConstants Condition="'$(TargetFrameworkProfile)' == 'WindowsPhone71'">TRACE;SILVERLIGHT;WINDOWS_PHONE71</DefineConstants>

Now I can easily include files in only my mango build, for example:

#if WINDOWS_PHONE71
namespace WindowsPhoneMVC.Navigation
{
    public static class DeepLink
    {
        public static string UriFor(string controller, string action, IDictionary<string, string> parameters)
        {
            var parametersString = string.Join("&", parameters.Select(p => p.Key + "=" + p.Value));
            return string.Format("/Shell.xaml?controller={0}&action={1}{2}{3}", controller, action, 
                string.IsNullOrEmpty(parametersString) ?  string.Empty : "&", parametersString);
        }

        public static NavigationRequest DecodeUri(string navigationFrame, string deepLink)
        {
            var kvp = deepLink.Split(new[] {'&'})
                .Select(o => o.Split(new[] {'='}))
                .ToDictionary(k => k[0], k => k[1]);

            string controller = null;
            if (kvp.ContainsKey("controller"))
            {
                controller = kvp["controller"];
                kvp.Remove("controller");
            }

            string action = null;
            if (kvp.ContainsKey("action"))
            {
                action = kvp["action"];
                kvp.Remove("action");
            }

            return new NavigationRequest(navigationFrame, controller, action, new NavigationParameter(kvp));
        }
    }
}
#endif

This way in visual studio I always build for 71, then my build.cmd which looks like this

@echo off
call "%VS100COMNTOOLS%vsvars32.bat"
mkdir .\build\log\

msbuild.exe /ToolsVersion:4.0 "WindowsPhoneMVC.msbuild" 

pause

Then the important part of that msbuild script, which builds my project as 7.0 and 7.1. After it builds it goes on to create my NuGet packages and releases meaning I can make a fix and test the new NuGet package locally within minutes, it works quite nice.

<Target Name="Compile" DependsOnTargets="Version">
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC\WindowsPhoneMVC.csproj"
             Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build;TargetFrameworkProfile=WindowsPhone;" />

    <MSBuild Projects="$(Root)src\WindowsPhoneMVC\WindowsPhoneMVC.csproj"
             Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build_71;TargetFrameworkProfile=WindowsPhone71;" />
</Target>

Complete build script

Here is my complete build script if you are interested, or just go to http://windowsphonemvc.codeplex.com to grab the latest version out of source control.

<Project DefaultTargets="Package" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSBuildCommunityTasksPath>$(MSBuildProjectDirectory)\build\lib\</MSBuildCommunityTasksPath>
    <Root>$(MSBuildProjectDirectory)\</Root>
    <Major>0</Major>
    <Minor>4</Minor>
    <Build>0</Build>
    <Revision>0</Revision>

    <NuGet>$(Root)build\lib\NuGet.exe</NuGet>
    <ContentSource>$(Root)src\SampleProjects\NuGetContentSource\</ContentSource>
  </PropertyGroup>

  <Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets"/>
  <Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Deployment.Tasks.Targets"/>
  <Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Mercurial.tasks"/>

  <Target Name="GetVersion">
    <Error Condition="$(MSBuildCommunityTasksPath) == ''" Text="MSBuildCommunityTasksPath variable must be defined" />
    <Error Condition="$(Root) == ''" Text="Root variable must be defined" />

    <HgVersion LocalPath=".">
      <Output TaskParameter="Revision" PropertyName="Revision" />
    </HgVersion>
    <!-- Diagnostics -->
    <Message Text="Diagnostics:"/>
    <Message Text="Build Number:    $(Major).$(Minor).$(Build).$(Revision)" />
    <Message Text="Project root:    $(Root)" />
    <Message Text="Drop path:       build\Artifacts" />

    <!-- Clean up -->
    <ItemGroup>
      <FilesToDelete Include="$(Root)**\bin\**\*.*" />
      <FilesToDelete Include="$(Root)**\obj\**\*.*" />
    </ItemGroup>
    <Delete Files="@(FilesToDelete)" />
  </Target>

  <Target Name="Version" DependsOnTargets="GetVersion">
    <RemoveDir Directories="build\artifacts\" />
    <RemoveDir Directories="build\temp\" />

    <AssemblyInfo CodeLanguage="CS"
	      OutputFile="$(Root)src\WindowsPhoneMVC\Properties\VersionInfo.cs"
	      AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)"
	      AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)"
	      Condition="$(Revision) != '-1' "/>
  </Target>

  <Target Name="Compile" DependsOnTargets="Version">
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC\WindowsPhoneMVC.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build;TargetFrameworkProfile=WindowsPhone;" />
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC.Extensions.Transitions\WindowsPhoneMVC.Extensions.Transitions.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build;TargetFrameworkProfile=WindowsPhone;" />
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC.Extensions.AutofacIntegration\WindowsPhoneMVC.Extensions.AutofacIntegration.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build;TargetFrameworkProfile=WindowsPhone;" />

    <MSBuild Projects="$(Root)src\WindowsPhoneMVC\WindowsPhoneMVC.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build_71;TargetFrameworkProfile=WindowsPhone71;" />
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC.Extensions.Transitions\WindowsPhoneMVC.Extensions.Transitions.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build_71;TargetFrameworkProfile=WindowsPhone71;" />
    <MSBuild Projects="$(Root)src\WindowsPhoneMVC.Extensions.AutofacIntegration\WindowsPhoneMVC.Extensions.AutofacIntegration.csproj"
         Properties="Configuration=Release;Platform=Any CPU;OutputPath=bin\Build_71;TargetFrameworkProfile=WindowsPhone71;" />

    <MSBuild Projects="$(Root)src\Templates\WPMvcTemplatesExtension\WPMvcTemplatesExtension.csproj"
         Properties="Configuration=Release;OutputPath=bin\Build" />
  </Target>

  <Target Name="NuGet" DependsOnTargets="Compile">
    <MakeDir Directories="$(Root)build\artifacts" />

    <ItemGroup>
      <AutofacContent Include="$(Root)build\autofaccontent\**\*.*" />
      <TransitionsContent Include="$(Root)build\transitionscontent\**\*.*" />
    </ItemGroup>

    <!--Main NuGet package-->
    <CallTarget Targets="MvcNuGet" />
    <CallTarget Targets="MvcLibsNuGet" />
    <CallTarget Targets="AutofacNuGet" />
    <CallTarget Targets="TransitionsNuGet" />
  </Target>

  <Target Name="MvcNuGet">
    <PropertyGroup>
      <NuGetManifest>$(Root)build\temp\WindowsPhoneMVC.nuspec</NuGetManifest>
      <MainNuGetContent>$(Root)build\temp\NuGet\content\</MainNuGetContent>
    </PropertyGroup>

    <MakeDir Directories="$(Root)build\temp\NuGet\WindowsPhoneMVC\lib" />
    <Copy SourceFiles="$(Root)build\WindowsPhoneMVC.nuspec"
		      DestinationFiles="$(NuGetManifest)" />

    <FileUpdate Files="$(NuGetManifest)"
				    Regex="0.0.0.1"
				    ReplacementText="$(Major).$(Minor).$(Build).$(Revision)"/>

    <Copy SourceFiles="$(ContentSource)Controllers\HomeController.cs" DestinationFolder="$(MainNuGetContent)Controllers\" />
    <Copy SourceFiles="$(ContentSource)ViewModels\Home\AboutViewModel.cs" DestinationFolder="$(MainNuGetContent)ViewModels\Home\" />
    <Copy SourceFiles="$(ContentSource)ViewModels\Home\MainViewModel.cs" DestinationFolder="$(MainNuGetContent)ViewModels\Home\" />
    <Copy SourceFiles="$(ContentSource)Views\Home\MainPage.xaml" DestinationFolder="$(MainNuGetContent)Views\Home\" />
    <Copy SourceFiles="$(ContentSource)Views\Home\MainPage.xaml.cs" DestinationFolder="$(MainNuGetContent)Views\Home\" />
    <Copy SourceFiles="$(ContentSource)Shell.xaml" DestinationFolder="$(MainNuGetContent)" />
    <Copy SourceFiles="$(ContentSource)Shell.xaml.cs" DestinationFolder="$(MainNuGetContent)" />
    <Copy SourceFiles="$(ContentSource)WindowsPhoneMVC_GettingStarted.htm" DestinationFolder="$(MainNuGetContent)" />

    <ItemGroup>
      <MvcContentFiles Include="$(MainNuGetContent)\**\*.*" />
    </ItemGroup>
    <FileUpdate Files="@(MvcContentFiles)"
				    Regex="NuGetContentSource"
				    ReplacementText="$rootnamespace$"/>
    <Move SourceFiles="@(MvcContentFiles)"
		      DestinationFiles="@(MvcContentFiles->'$(MainNuGetContent)%(RecursiveDir)%(Filename)%(Extension).pp')" />

    <!--SL3-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL3-WP\WindowsPhoneMVC.dll"/>
    <!--SL4-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone\WindowsPhoneMVC.dll"/>
    <!--SL4_71-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build_71\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone71\WindowsPhoneMVC.dll"/>
    <Exec Command='"$(NuGet)" pack "$(NuGetManifest)" -BasePath "$(Root)build\temp\NuGet" -OutputDirectory "$(Root)build\artifacts"' />
    <RemoveDir Directories="build\temp\" />
  </Target>

  <Target Name="MvcLibsNuGet">
    <PropertyGroup>
      <NuGetManifest>$(Root)build\temp\WindowsPhoneMVC.Libs.nuspec</NuGetManifest>
    </PropertyGroup>

    <MakeDir Directories="$(Root)build\temp\NuGet\WindowsPhoneMVC\lib" />
    <Copy SourceFiles="$(Root)build\WindowsPhoneMVC.nuspec"
		      DestinationFiles="$(NuGetManifest)" />

    <FileUpdate Files="$(NuGetManifest)"
				    Regex="0.0.0.1"
				    ReplacementText="$(Major).$(Minor).$(Build).$(Revision)"/>

    <!--SL3-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL3-WP\WindowsPhoneMVC.dll"/>
    <!--SL4-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone\WindowsPhoneMVC.dll"/>
    <!--SL4_71-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC\bin\Build_71\WindowsPhoneMVC.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone71\WindowsPhoneMVC.dll"/>
    <Exec Command='"$(NuGet)" pack "$(NuGetManifest)" -BasePath "$(Root)build\temp\NuGet" -OutputDirectory "$(Root)build\artifacts"' />
    <RemoveDir Directories="build\temp\" />
  </Target>

  <Target Name="AutofacNuGet">
    <PropertyGroup>
      <NuGetAutofacManifest>$(Root)build\temp\WindowsPhoneMVC.Extensions.AutofacIntegration.nuspec</NuGetAutofacManifest>
      <MainNuGetContent>$(Root)build\temp\NuGet\content\</MainNuGetContent>
    </PropertyGroup>

    <MakeDir Directories="$(Root)build\temp\NuGet\WindowsPhoneMVC.Extensions.AutofacIntegration\lib" />
    <Copy SourceFiles="$(Root)build\WindowsPhoneMVC.Extensions.AutofacIntegration.nuspec"
		      DestinationFiles="$(NuGetAutofacManifest)" />

    <FileUpdate Files="$(NuGetAutofacManifest)"
				    Regex="0.0.0.1"
				    ReplacementText="$(Major).$(Minor).$(Build).$(Revision)"/>

    <Copy SourceFiles="$(ContentSource)To_Enable_Autofac.txt" DestinationFolder="$(MainNuGetContent)" />
    <Copy SourceFiles="$(ContentSource)ApplicationModule.cs" DestinationFolder="$(MainNuGetContent)" />

    <ItemGroup>
      <AutofacContentFiles Include="$(MainNuGetContent)\**\*.*" />
    </ItemGroup>
    <FileUpdate Files="@(AutofacContentFiles)"
				    Regex="NuGetContentSource"
				    ReplacementText="$rootnamespace$"/>
    <Move SourceFiles="@(AutofacContentFiles)"
		      DestinationFiles="@(AutofacContentFiles->'$(MainNuGetContent)%(RecursiveDir)%(Filename)%(Extension).pp')" />

    <!--SL3-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.AutofacIntegration\bin\Build\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL3-WP\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"/>
    <!--SL4-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.AutofacIntegration\bin\Build\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"/>
    <!--SL4_71-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.AutofacIntegration\bin\Build_71\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone71\WindowsPhoneMVC.Extensions.AutofacIntegration.dll"/>
    <Exec Command='"$(NuGet)" pack "$(NuGetAutofacManifest)" -BasePath "$(Root)build\temp\NuGet" -OutputDirectory "$(Root)build\artifacts"' />
    <RemoveDir Directories="build\temp\" />
  </Target>

  <Target Name="TransitionsNuGet">
    <PropertyGroup>
      <NuGetTransitionsManifest>$(Root)build\temp\WindowsPhoneMVC.Extensions.Transitions.nuspec</NuGetTransitionsManifest>
      <MainNuGetContent>$(Root)build\temp\NuGet\content\</MainNuGetContent>
    </PropertyGroup>

    <MakeDir Directories="$(Root)build\temp\NuGet\WindowsPhoneMVC.Extensions.Transitions\lib" />
    <Copy SourceFiles="$(Root)build\WindowsPhoneMVC.Extensions.Transitions.nuspec"
		      DestinationFiles="$(NuGetTransitionsManifest)" />

    <FileUpdate Files="$(NuGetTransitionsManifest)"
				    Regex="0.0.0.1"
				    ReplacementText="$(Major).$(Minor).$(Build).$(Revision)"/>

    <Copy SourceFiles="$(ContentSource)To_Enable_Transitions.txt" DestinationFolder="$(MainNuGetContent)" />

    <ItemGroup>
      <TransitionsContentFiles Include="$(MainNuGetContent)\**\*.*" />
    </ItemGroup>
    <FileUpdate Files="@(TransitionsContentFiles)"
				    Regex="NuGetContentSource"
				    ReplacementText="$rootnamespace$"/>
    <Move SourceFiles="@(TransitionsContentFiles)"
		      DestinationFiles="@(TransitionsContentFiles->'$(MainNuGetContent)\%(RecursiveDir)%(Filename)%(Extension).pp')" />

    <!--SL3-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.Transitions\bin\Build\WindowsPhoneMVC.Extensions.Transitions.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL3-WP\WindowsPhoneMVC.Extensions.Transitions.dll"/>
    <!--SL4-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.Transitions\bin\Build\WindowsPhoneMVC.Extensions.Transitions.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone\WindowsPhoneMVC.Extensions.Transitions.dll"/>
    <!--SL4_71-->
    <Copy SourceFiles="$(Root)src\WindowsPhoneMVC.Extensions.Transitions\bin\Build_71\WindowsPhoneMVC.Extensions.Transitions.dll"
		      DestinationFiles="$(Root)build\temp\NuGet\lib\SL4-WindowsPhone71\WindowsPhoneMVC.Extensions.Transitions.dll"/>
    <Exec Command='"$(NuGet)" pack "$(NuGetTransitionsManifest)" -BasePath "$(Root)build\temp\NuGet" -OutputDirectory "$(Root)build\artifacts"' />
    <RemoveDir Directories="build\temp\" />
  </Target>

  <Target Name="Test" DependsOnTargets="NuGet">

  </Target>

  <Target Name="Package" DependsOnTargets="Test">
    <Copy SourceFiles="$(Root)src\Templates\WPMvcTemplatesExtension\bin\Build\WindowsPhoneMvcTemplatesExtension.vsix"
		      DestinationFiles="$(Root)build\artifacts\WindowsPhoneMvcTemplates.vsix" />
  </Target>
</Project>

Windows Phone MVC Update

Jake Ginnivan — Mon, 22 Aug 2011 07:17:28 PDT

Windows Phone MVC?

So to get started, let me explain what it is.
It is a MVC + MVVM Hybrid framework, I think MVVM falls down in a few area's, and by teaming up with the MVC pattern we can achieve great testability, performance, navigation, lifecycle etc..

The aim of Windows Phone MVC is to make windows phone development quicker, easier, more enjoyable and most of all help you build a nice performant app which gives an awesome user experience.

This is going to be quite a long post going through many features of Windows Phone MVC, I hope it gets across what I am trying to do with the framework, and how it can help you out!
I am still a little way from v1, so there will be API changes, but I am more than happy to field some questions about how to use it.

Many of the improvements on this release are due to http://transhub.wordpress.com/ using Windows Phone MVC and I have been working close with the transub team to make sure the framework helped them deliver a killer app!

Important Links

NuGet Package Name: WindowsPhoneMVC
Codeplex URL: http://windowsphonemvc.codeplex.com/
Documentation: http://windowsphonefoundations.net/windowsphonemvc

MVC

First off it is important to understand how a MVC framework works.

It all starts off with a Controller, and an Action.

public class HomeController : Controller
{
    public ActionResult Main()
    {
        return Page(new MainViewModel());
    }
}

An action is simply a method on a class which inherits from Controller. The Controller returns an ActionResult, there are helper methods in the controller base class which let you do this with ease.

Note: is actions are invoked on a background thread and you should do work synchronously, we have made this easy with:

public ActionResult GetWebData()
{
    var request = WebRequest.CreateHttp(url);
    var response = (HttpWebResponse)Execute.AsyncPatternWithResult(request.BeginGetResponse, request.EndGetResponse);
    return Result(response.GetResponseString());
}

Will talk a bit more about threading later..

ActionResults

We have a few different action results, they include:

PageResult (Navigates to a new page, the parameter you pass becomes the datacontext for that page)
DialogResult (Shows a dialog over the top of your current page)
NothingResult (Allows you to finish a controller action without doing anything. i.e if (TrialExpired) return Nothing();
BackResult (navigates back)
BackToResult (navigates back to a particular view. i.e to go back to home, no matter how many between return BackTo<HomeController>("Main");)
DataResult (used to return data to the previous view, more info below!)

Using these, you can do most things you need to pretty easily.

Invoking actions

Generally you will invoke ALL actions from the viewmodel, currently all the API's are named around navigation, this may change in the future. What do you think?

//MainViewModel ctor
public MainViewModel()
{
    SearchCommand = Controller<SearchController>.NavigationCommand(c=>c.SearchLocations(SearchCriteria));
}

public SearchCriteria SearchCriteria { get { return searchCriteria; } }
public ICommand SearchCommand { get; private set; }

Performance

One of the first things that people say to me when I say I am building another framework for windows phone is, 'I don't use frameworks, they are too slow'.
Something to keep in mind is that there are two types of performance, actual performance and perceived performance. The latter is actually the more important of the two, because it is how the user perceives how fast the application is. I remember reading in a book the story about how back in the day Microsoft got told that their c++ compiler was slow vs the borland one, even though it WAS faster, so they then made it output everything that it was happening onto the console and the users congratulated them on the improvement. It was about 5% slower because of the output.

Windows Phone MVC tries to achieve both by default, I am trying to optimise the framework as much as I can, the overhead in startup time & memory usages is 15-20% at the moment based on some initial testing, I hope to drop this over time and put some neat perf tricks in.

There is a few things to note here, Windows Phone MVC has a rich navigation system, so you can do work, load data, THEN navigate. You can also invoke an action which simply returns you data, or navigates to a page, then returns you the result from that page!

Performance Progress Bar included out of the box (original, if you add transitions extension which needs Silverlight Toolkit, we switch to using the new one from Silverlight Toolkit).
As soon as you invoke any action the Progress bar will be shown, and the screen grayed. You can also easily show text by just going LoadingMessage("Search in progress.."); from your controller action.
The app bar buttons are all disabled (we also give you full Commanding support in the app bar! more info on that later).

I still have some tuning and plan on rounding up some WP7 performance experts at TechEd to give me more tips about how I can improve the performance of this, but it feels and looks nice at the moment.

MVVM/Commanding Support

Out of the box there are some really nice helpers for you.

Buttons

<Button commands:Click.Command="{Binding AboutPageCommand}"
        Content="About" />
<Button commands:Navigate.To="Home.ViewItem"
        DataContext="{Binding }" <!--Action can be ViewItem(ItemViewModel item)-->
        Content="View Item" />

The second can optionally pass the datacontext to the controller action, really useful when you have a button in a list of items.

App Bar

As you probably know, the Application Bar is not a DependencyObject, so we can't use any of the nice silverlight goodness we are used to. I have taken the following approach:

<phone:PhoneApplicationPage.ApplicationBar>
    <shell:ApplicationBar IsVisible="True"
                          IsMenuEnabled="True">
        <shell:ApplicationBarIconButton IconUri="/Icons/dark/appbar.add.rest.png"
                                        Text="new[AddCommand]" />
        <shell:ApplicationBar.MenuItems>
            <shell:ApplicationBarMenuItem Text="settings[ShowSettingsPageCommand]" />
            <shell:ApplicationBarMenuItem Text="about[ShowAboutPageCommand]" />
        </shell:ApplicationBar.MenuItems>
    </shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>

Simply put the command name in square brackets in your appbar text, and they will be wired up to your viewmodel. Including listening to CanExecuteChanged to enable and disable appbar buttons!

ListBoxes

Another handy addition is if you have a list of items, and you want to view details when any one of them is selected.

<ListBox ItemsSource="{Binding Items}"
            Commands:Navigate.OnItemSelected="AnotherController.ItemAction"
            DisplayMemberPath="Title" />

On the ViewModel

How often do you write something like new DelegateCommand(()=>DoStuff()) in the case of MVC it would be new DelegateCommand(()=>Controller<HomeController>().DoStuff()). That is kinda ugly, so I have provided a nicer API for defining Commands:

ShowGreetingPageCommand = Controller<HomeController>().NavigationCommand(c => c.SayHelloTo(Name));
//or if you want to fetch some data/refresh the page: 
RefreshCommand = Controller<AnotherController>().NavigationCommandWithResult<ObservableCollection<SearchResult>>(c => c.PerformSearch(Parameter), HandleCallback);

Navigation

I mentioned earlier that Windows Phone MVC has a really powerful navigation system. It actually does not use the inbuild NavigationService, it navigates once at the start of the all to your Shell.xaml, which hosts your app, the framework then takes care of switching out the content, and maintaining it's own journal. This has a number of advantages.

Be aware that Navigation with Windows Phone MVC is equivilent to Tombstoning that view, when you navigate the controller action will ALWAYS be executed. The advantage of this is that your views/viewmodels can be garbage collected as soon as you navigate away from that view.

Type safe navigation WITH arguments

Take this navigation:

Controller<HomeController>().NavigateTo(c => c.MyAction(ComplexProperty));

This is all type safe, and I am passing any class as an argument to my action, I don't need to know the view name, and I get full intellisense on the arguments.

NOTE: Due to WP7 limitations around reflection, you cannot pass local variables (declare in the same method), method arguments, or protected/private fields. All of these things require reflection on non public types, which is not supported.
Never fear!

If you try and do this:

private void NavigateWithPrivate()
{
    var local = new SomeClass();
    Controller<AnotherController>().NavigateTo(c=>c.PerformSearch(local));
}

You will get a nice helpful error message:

You can literally copy and paste the suggested syntax (check it first, and let me know if I get any cases wrong) over your code, then it will start working!

Back stack manipulation (without Mango :P)

At any time in a viewmodel or a controller you can write:

Navigator.RemoveBackEntry();

That is pretty cool, and works without mango. But to go one better than what you get in Mango:

Navigator.NavigateBackTo<HomeController>("Main");
// or in controller:
return BackTo<HomeController>("Main");

This will unwind the backstack until you get to the matching controller and action! If it can't find it, it will let you know.

Returning data to previous page

A great example of this is the DateTimePicker in the toolkit, when you click on it, it actually hijacks the navigation service, navigates to a page inside the toolkit, then when you click on one of the appbar buttons it navigates back, then updates the control. Sound useful? It really is..

Without a navigation

This performs a search in a controller action, then returns the data without navigating.

private void PerformSearch()
{
    Controller<SearchController>().NavigateToWithResult<JourneyPlanningResponse>(c => c.PerformSearch(SearchCriteria), SearchComplete);
}

private void SearchComplete(JourneyPlanningResponse response)
{
     ....
}

With navigation

What about the datepicker example:

GetValueCommand = Controller<DebugController>().NavigationCommandWithResult<string>(c => c.PageWithResult(), HandleCallback);

Then on our viewmodel looks like this:

public class PageWithResultViewModel : ViewModelBase
{
    private string valueToReturn;

    public PageWithResultViewModel()
    {
        OkCommand = new DelegateCommand(() => Navigator.NavigationResult(ValueToReturn));
        CancelCommand = new DelegateCommand(() => Navigator.NavigateBack());
    }

    public string ValueToReturn
    {
        get { return valueToReturn; }
        set
        {
            valueToReturn = value;
            OnPropertyChanged(()=>ValueToReturn);
        }
    }

    public ICommand OkCommand { get; private set; }
    public ICommand CancelCommand { get; private set; }
}

I recon that is pretty cool! And super easy to use....

Threading

Mentioned earlier, actions are invoked on a background thread, and the Controller's lifetime scope (if using autofac) is disposed as soon as the action is invoked, so you shouldn't return from the action before you have fully setup the new view's viewmodel and you shouldn't be waiting for any callbacks. The way we have solved this is with the Execute class.

var response = (HttpWebResponse)Execute.AsyncPatternWithResult(svc.BeginGetResponse, someArg, request.EndGetResponse);

//or if the call doesnt return anything Execute.AsyncPattern(svc.BeginDoSomething, someArg, svc.EndDoSomething);

This will turn the async pattern Begin/End pair into a synchronous call. You should not use this class on the UI Thread obviously...

Talking about the UI Thread, what happens if you want to do stuff on the UI Thread?

Execute.OnUIThread(()=>{/*dostuff*/});
Execute.OnUIThreadSync(()=>{/*do stuff synchronously*/});

These two methods invoke an action(or func with the synchronous option) on the UI Thread asynchronously and synchronously respectively.

WP7 Lifecycle

Another very important part of developing for WP7 is the lifecycle management. We do a fair bit here to help you out.

If you want a property to be saved between navigations, and tomb-stoning simply mark it as transient like follows:

public RegisterViewModel()
{
    Transient(() => Name);
    Transient(() => Username);
    Transient(() => Password);
}

Because we recreate the view each time you navigate (I may possibly introduce caching of the view so it doesn't have to be recreated, but memory pressure is tight pre-mango so will investigate in the future), Panoramas will not restore to the same panel that was selected. This is easily fixed with an attached property

<toolkit:Panorama Title="my application"
                  Phone:Restore.PanoramaPosition="True">

Let me know if there any other things that you would like restored.

OnActivate/OnDeactivate

Windows Phone MVC changes the behaviour slightly from the default experience. When a view is navigated away from, OnDeactivate will be called, and whenever it is shown OnActivate will be executed. Simply override one/both of these methods to do anything you need to for tombstoning.

PageState

Earlier I mentioned that Windows Phone MVC has it's own NavigationService, and Journal. This means I cannot use the included PageState from the framework as it is tightly coupled with the phones NavigationService. So I have rolled my own.

public interface IPageTransientStore
{
    void Save<T>(string key, T obj) where T : class;
    T Load<T>(string key) where T : class;
    bool Contains(string key);
    void Remove(string key);
}

All serialisation in Windows Phone MVC is done using Mike Talbot's Silverlight Serializer. This means I can serialise complex types, without specifying known types very fast.

Obscured

If you are interested in being notified when your app is obscured, simple make your ViewModel inherit from IObscuredAware, like so:

public class ViewResultTestViewModel : ViewModelBase, IObscuredAware
{
    public void Unobscured(object sender, EventArgs e)
    {
    }

    public void Obscured(object sender, ObscuredEventArgs e)
    {
    }
}

Deep Linking

We also support Mango features! If you want to create a deep link into your Windows Phone MVC application, that is really easy too.. It is also type safe =)

private void CreateDeepLink()
{
    var deepLinkUri = Controller<HomeController>().UriFor(c => c.DeepLinkPage, new Dictionary<string, string>());
    ShellTile.Create(new Uri(deepLinkUri, UriKind.Relative), new StandardTileData
                                                {
                                                    BackgroundImage = new Uri("/ApplicationIcon.png", UriKind.Relative),
                                                    Title = "MVC Deep Link"
                                                });
}

Deep links can only take a collection of KeyValuePair for the parameters.

Transitions

Everyone loves a nice sexy app that has transitions. Jeff and the guys behind the Silverlight have made it pretty easy to get nice transitions working in your app. You will be happy to know it is just as easy for Windows Phone MVC. Simple run in your NuGet console Install-Package WindowsPhoneMVC.Extensions.Transitions. This relies on the Silverlight toolkit and will drop a To_Enable_Transitions.txt file into your project with the code required to wire it up (super easy). The usage is exactly the same after the setup.

IoC Container Support

By default, Windows Phone MVC has a DefaultControllerFactory, this isn't very interesting. So you can just run this in your NuGet console Install-Package WindowsPhoneMVC.Extensions.AutofacIntegration and you will get two files and a reference added to your project, the first is To_Enable_Autofac.txt, it will have code in it which you can copy/paste into App.xaml to enable the integration. The next is ApplicationModule.cs which is where you can register everything.

Performance

Once again, as soon as you mention an IoC container on the phone, people freak out. The performance penalty is next to nothing if you do a bit of work in your ApplicationModule class.

Use Register(()=>) rather than RegisterType. Out of the box (so it works by default) you have this in your ApplicationModule.

builder
    .RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
    .AssignableTo<Controller>()
    .AsSelf();

This has the cost of reflecting your assembly when starting your app, then the reflection cost of construcing the object. A more performant alternative is:

builder
    .Register(c=>new MainController(c.Resolve<ISomeService>()))
    .AsSelf();
builder
    .Register(c=>new SomeService())
    .As<ISomeService>()
    .SingleInstance(); //Lightweight services can be left as SingleInstance

Sure this has more maintenance costs, but the performance different is substantial. On my phone the a object graph of ~90 object constructions took about 30% of the time vs letting the container do the hard work.

Debugging

To make diagnosing issues, and to give warnings and suggestions, simply handle the Trace event on the NavigationApplication and write the message out to Debug.Write. Internally no logging will be executed if the debugger is not attached.

<Application.ApplicationLifetimeObjects>
    <AutofacIntegration:AutofacNavigationApplication Activated="AutofacNavigationApplicationActivated"
                                                     Deactivated="AutofacNavigationApplicationDeactivated"
                                                     Closing="NavigationApplication_OnClosing"
                                                     Trace="AutofacNavigationApplication_Trace"/>
</Application.ApplicationLifetimeObjects>

In the HelloWorld application this produces an output like this:

Navigator: Memory usage before navigation: 8.359375
Navigator: Memory usage after navigation: 9.42578125
Navigator: Memory usage before navigation: 9.46484375
Navigator: Memory usage after navigation: 15.55859375
Navigator: Memory usage before navigation: 13.84765625
Navigator: Passing ViewModels as parameters may cause memory pressure as they are not disposed! Consider using base type of NotifyPropertyChanged if the parameter is actually an entity, not a ViewModel.
Navigator: Memory usage after navigation: 19.08203125
Navigator: Memory usage before navigation: 11.46875
Navigator: Memory usage after navigation: 12.62890625
Navigator: Memory usage before navigation: 11.828125
Navigator: Memory usage after navigation: 16.98828125
TimerScope: Beginning Parsing Navigation Expression
Navigator: Memory usage before navigation: 15.3203125
TimerScope: Ending Parsing Navigation Expression. Took 13ms
Navigator: Memory usage after navigation: 19.84765625

Logging is pretty light at the moment, as I try and identify performance bottlenecks and other things I will likely introduce logging levels and lots more of it. I also hope to add helpful warnings for best practices as I have done with the note about ViewModels.

The downside of such a rich navigation model, is that you can pass very large things around, and parameters are always kept in memory, and viewmodels often have a lot more data than actually needs to be kept in memory.

Conclusion

I hope this is a useful post as a introduction to Windows Phone MVC, and shows off many of the features which make it really easy to write WP7 applications.

Please leave feedback, ping me on twitter (@JakeGinnivan), or email me at jake@ginnivan.net with suggestions/issues. I want to power towards v1.0 when I will lock down API's and consider the framework stable. The framework is reasonably stable now, and is being used in a decent size app. But there will likely be situations I haven't thought of, or haven't tested.

Go get it!

Simply add WindowsPhoneMVC to your project via NuGet to get started, there will be a readme added to your project and a sample controller/ViewModels etc. If you don't want the files to get you started, choose the libs project

Phone Test Project Template

Jake Ginnivan — Sat, 20 Aug 2011 18:12:36 PDT

Last week I put together a project template for a windows phone 7 test project. At the moment there isn't a really good story for unit testing on the phone. If you have the mango tools you have to grab the Mango Silverlight Unit Test assemblies from Jeff Wincox's blog.

The Project Template available at http://visualstudiogallery.msdn.microsoft.com/6819514d-4bd6-4f31-a231-48c6530ed03b is really basic, and you then have to add a reference via NuGet of either the Silverlight Unit Testing Framework (doesn't work with Mango), or WindowsPhoneEssentials.Testing.

The advantage of the WindowsPhoneEssentials.Testing project is it contains the Mango compatible versions, sets everything up and has a collection of really useful testing related helpers/abstractions for WP7. Check out http://windowsphonefoundations.net/windowsphoneessentials or the source at http://wp7essentials.codeplex.com/ for more information.

But what you get after you install it is:

Then you add the NuGet reference to WindowsPhoneEssentials.Testing

Enjoy!

ThreadPool vs. Tasks

Paul Stovell — Sun, 26 Feb 2012 18:14:07 PST

.NET 4.0 includes a new few new classes called Tasks, which are part of the Task Parallel Library. You can learn all about them in an article by my friend Sacha on Code Project.

The TPL is useful, but I'm starting to see a lot of coders using the Task class. I may be an old fuddy-duddy, but I can't quite understand what advantage Task gives me over plain old ThreadPool in .NET 2.0. Here are some examples of how the Tasks "features" would be implemented using ThreadPool.

Starting a task

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();
});

Waiting for a task to complete

var handle = new ManualResetEvent(false);
ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();
    handle.Set();
});
handle.WaitOne();

Returning

int result = 0;

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();

    result = 42;

    handle.Set();
});
handle.WaitOne();

Console.WriteLine(result);

Chaining tasks

var handle = new AutoResetEvent(false);
ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();
    handle.Set();
});
handle.WaitOne();

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeMoreWork();
    handle.Set();
});
handle.WaitOne();

Waiting for multiple tasks to complete

var handle1 = new ManualResetEvent(false);
var handle2 = new ManualResetEvent(false);

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();
    handle1.Set();
});

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeMoreWork();
    handle2.Set();
});

WaitHandle.WaitAll(new WaitHandle[] { handle1, handle2 });

Exception handling

var handle = new ManualResetEvent(false);

Exception error = null;
ThreadPool.QueueUserWorkItem(delegate
{
    try
    {
        DoSomeWork();
    }
    catch (Exception ex)
    {
        error = ex;
    }
    finally
    {
        handle.Set();
    }
});

handle.WaitOne();

if (error != null)
    Console.WriteLine("Error! " + error);

Word of caution: you should probably always do this when using ThreadPool, since exceptions thrown on a ThreadPool thread will tear down the AppDomain if not caught

Cancellation

var cancel = false;

ThreadPool.QueueUserWorkItem(delegate
{
    while (!cancel)
    {
        Thread.Sleep(100);
    }
});

cancel = true;

Note: this is like a gazillion times more complex in Tasks

Dispatching to UI thread

var dispatcher = Application.Current.Dispatcher;

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();

    dispatcher.BeginInvoke(new Action(() => progressBar.Value += 10));

    DoSomeMoreWork();

    dispatcher.BeginInvoke(new Action(() => progressBar.Value += 10));
});

Being notified when a task is complete without blocking

Action<int> done = (int x) => Console.WriteLine("Done! " + x);

ThreadPool.QueueUserWorkItem(delegate
{
    DoSomeWork();

    done(42);
});

So help me learn the Task API - how would using Task make the examples above look better?