Passing Objects between Silverlight Applications

This week I have been making some prototype applications using Silverlight, which has been awesome, and I decided that I wanted to pass a few objects between these applications. If this wasn't a quick prototype and didn't have to run off of a Sales person's laptop I would have whipped together a quick bit of RIA Services and got them talking that way. However these are just two out of browser applications.

Enter Local Messaging.

Silverlight has a great little feature, that I'm not sure is too often used, Local Messaging. Local Messaging allows you to send simple string messages between two Silverlight applications running on a local computer. This can be within the same Web Page or two Out of Browser Applications

Local messaging works by having a LocalMessageReciever listening for messages in one application and then a LocalMessageSender sending messages from the other. If you want two way communication you simply have a listener and sender in each application.

// In the receiving application:
LocalMessageReceiver messageReceiver = new LocalMessageReceiver("receiver");

// In the sending application:
LocalMessageSender messageSender = new LocalMessageSender("receiver");

I'm not going to explain how you send messages between the applications as MSDN does a far better job of doing so. However MSDN only talks about simple string messages, I wanted to send objects.

Serialising the objects

The obvious solution I thought was to just serialise the objects to a string and then back at the other end. Silverlight doesn't support binary serialisation and as we have to send the message as a string the Serialisation could be XML, which is common practice and I'm sure most people know instinctively how to do so, however XML is bloated. Alot of our message string would be information we aren't interested in. Now in most applications we don't worry about this and XML is fine however this local app messaging has a maximum string size of 40 kilobytes. We don't want to fill this up with XML notation, instead we want something alot leaner.

Although Silverlight doesn't support Binary Serialisation it does however support JSON. JSON is a far less verbose markup which will mean our messages will be more about the object data and structure rather than syntax which is a good thing

When it comes to JSON serialisation there are a few options, the built in DataContractJsonSerializer , JSON.Net etc. For the ease of setup I have gone for using the build in DataContractJsonSerializer. Here i take a generic object and serialise it to a stream which we can then use in our message.

DataContractJsonSerializer serialiser = new DataContractJsonSerializer(message.GetType());
var stream = new System.IO.MemoryStream();
serialiser.WriteObject(stream, message);

With this string we can simply use a streamreader to get the string that our sendasync message sender method requires.

 new System.IO.StreamReader(stream).ReadToEnd())

But there's a problem, we cant just send the json object, as at the other end we won't know the type. What we have to do then is send the type and the serialised form. This leaves us with the following:

stream.Position = 0;
sender.SendAsync(String.Format("{0}|!|{1}", message.GetType(), new System.IO.StreamReader(stream).ReadToEnd()));

Note: I have used |!| as a way to know where the type name ends and the stream begins, I could have said {type}={jsonserilaisedobject} but I chose not too, for neatness though this should be possible I just chose to use a delimiter I knew wouldn't appear in my serialised object.

Receiving the message and getting the object back

To get the object back in the other application, after receiving the message from the sender we have to split the string based on the delimeter and then deserialise the object.

var type = e.Message.Substring(0, e.Message.IndexOf("|!|"));
var data = e.Message.Substring(e.Message.IndexOf("|!|") + 3);

The DataContractJsonSerializer requires a stram not a string to deserialise an object so next take the data string and turn it into a stream. Then just deserialise.

var stream = new System.IO.MemoryStream(System.Text.Encoding.UTF8.GetBytes(data));
var serialiser = new DataContractJsonSerializer(Type.GetType(type));
if(type == "OurCustomType"){
    var result = (OurCustomType)serialiser.ReadObject(stream);
}

And that's it, obviously handling lots of types would mean not using an if statement, maybe a switch or whatever but the principle is the same.

I hope you find this of use, it certainly made my prototype far more functional and proved a neat way of doing it

linq to lucene magic unicorn edition

This week I started to look at using Lucene.Net again in a project. Previously I have used it directly however whilst on the new look Lucene.Net website I noticed the linq to lucene project. Which at first look seemed pretty good. However upon looking at the source I found it only works with XML and LinqToSql, this prototype project however was in .Net 4 and used Sql CE4 with Entity Framework 4.1 Code First.

Rather than abandon linq to lucene I decided it should be easy enough to get it working with EF4.1. DatabaseIndexSet contains the LinqToSql specific code so for the purpose of producing a proof of concept this is where all the changes go.

The first item to change is to rescope the generic where clause to be DbContext rather than the linq context.

 public class DatabaseIndexSet : IndexSet
        where TDataContext : DbContext

Next the Write Method needs altering, the LinqToSQL implementation uses the GetTable method, however E.F doesn't really have the same methods. Instead with E.F we can use the Set method with our entity as the generic, this will allow us to obtain all of the records

Finally the GetTableTypes method needs "tweaking", I say tweak as so far its a bit of bodge. The GetTableTypes method is used to find all of the "tables" within our database context which are then later used to create lucene index files. The original LinqToSql method ensured that each property was a generic type and that it is assignable from the base type. For our initial run as our entity classes don't inherit anything I have removed that check, just ensuring the properties are generic. This will be added back in for the final release.

With those changes made we can then use LinqToLucene as follows:

 var index = new EnquiriesIndexContext();
            index.Write();
            var query = from p in index.Parts
                        where p.PartNumber == "ghjtyugfhj-61"
                        select p;
           Console.WriteLine("Simple Query:");
           ObjectDumper.Write(query);
           Console.WriteLine("Query Output: {0}", query.ToString());
           
            var results = query.ToList();
            Console.WriteLine("SimpleDemo returned {0} results", results.Count);

Have a go of the prototype code that is attached, I'll be aiming to tidy it up and get it pushed back to the main project on codeplex over the next week. Enjoy

Using the Razor Engine to create PDFs

I've been using MVC 3 and the Razor syntax for a while now, and a while ago whilst reading how people were using Razor for their email templates I had the idea to use Razor to help create PDF templates.

Now sadly it's been a while since I played around with this but I have only just started getting back on top of things so here's how I've done it.

Components Used

My solution is to write HTML templates using the Razor syntax and then to make use of the Razor View Engine for filling in the dynamic data. Then for the PDF creation to make use of iTextSharp library to generating the PDF documents from the generated HTML.

iTextSharp is a free library that allows you to create PDF's using C#, unfortunatley its API is a bit of a pain to use natively so I have made use of Hugo Bonacci's HtmlToPdfBuilder.cs class to simply my interaction with the library.

The first thing to do is to generate the HTML markup for out PDF. So fire up a new RazorViewEngine and load the view (template) you wish to use. We load the view by using the view engines FindView method. This method requires a ControllerContext so if you are using in an MVC site you can pass the current context, which is how for my protoype I used it, or you need to pass a custom one.

 var frontPageData = new RazorViewEngine().FindView(this.ControllerContext, "Newsletter", "", false);

In my example I wanted my Newsletter template, I have decided to not use a master view or caching but in a real application you may want to enable view caching.

Next you need a view context, a view context also needs a controller context, the view you found previously, a viewdatadictionary, a tempdatadictionary and a textwriter. The viewdatadictionary should be used to pass a model to your view or viewdata items, these will then be used within the view to populated your dynamic data items. The textwriter will be the object that the final generated HTML will be written to and this is what we will use to generate the PDF from.

  var textwriter = new StringWriter();
        var dataDict = new ViewDataDictionary<NewsletterData>()
        {
            Model = new NewsletterData{ Name = "Mike" }
        };
        var context = new ViewContext(this.ControllerContext, frontPageData.View, dataDict, new TempDataDictionary(), textwriter);

The final thing we do to get our generated HTML is call the Render method on our view, this render method requires our viewcontext and the text writer.

frontPageData.View.Render(context, textwriter);

Now the HTML is generated we can make use of the HtmlToPdfBuilder class to take our HTML and generate a PDF document. This is as simple as creating a new builder with a provided pagesize, calling add page and then appending our HTML. Hugo's HtmlToPdfBuilder class expects an array of values to use in the HTML, as it expects the HTML to have placeholders in the String.Format fashion {0} {1} etc. We don't need to do this as we have already finalised our HTML, if this was going to be production code I would seriously consider not using the HtmlToPdfBuilder class and instead write one that only uses iTextSharp and the RazorViewEngine, however for this simple prototype it makes things alot simpler.

var myHtmlPdfBuilder = new HtmlToPdfBuilder(PageSize.A4_LANDSCAPE);
//add a new page
myHtmlPdfBuilder.AddPage();
//using the current page take our html data from our view and write it
myHtmlPdfBuilder[0].AppendHtml(data, new object[]{ });

Now the PDF has been generated we can call the RenderPDF method on our HtmlPdfBuilder class to get an array of bytes back that represent the PDF. We can then use this array and write it to disk as a PDF document or to a response stream to have a dynamic PDF page on a website.

It really is that simple, I hope this prototype shows you the power the RazorViewEngine gives you especially when you start combining its output with other third party libraries. You can download my protoype MVC 3 site with this in and have a poke. It includes a simple PDFActionResult along with the above code.

Update

Whilst writing this blog post up I have decided to roll this prototype into a proper component which should simplfy the above and not require the use of Hugo's class. I will blog about this component when it is finished and publish it on CodePlex or something similar.