Today we are going to build a custom formatter for ASP.NET WebAPI, deriving from MediaTypeFormatter class. It will return our model (or collection of models) in RSS or Atom format.
The Formatter is supposed to react to requests sent with request headers “Accept: application/atom+xml” and “Accept: application/rss+xml”.

Let’s get going.

I recently got a bit depper into Bing Maps development, and I have been mesmerized by their richness and capabilities.

With that said, I had an idea that Bing Maps are one of those products that are simply tailor made for full screen viewing. So I thought, why not bring that to life with the new HTML5 Full screen API? Noteworthy, Facebook recently rolled out an update including the full screen API in their photo viewing service.

More after the jump.

I was really excited when I heard the announcement of the ESPN API. Being a sports freak like me, that opens a tremendous amount of possibilities for application development. Today, let’s build our own sports news single-page application, fueled entirely by Knockout.js.

You will be able to browse the latest news from ESPN from all sports categories, as well as filter them by tags. The UI will be powered by KnockoutJS and Twitter bootstrap, and yes, will be a single page. We have already done two projects together using knockout.js - last.fm API infinite scroll and ASP.NET WebAPI file upload. Hopefully we will continue our knockout.js adventures in an exciting, and interesting for you, way.

More after the jump.

Today we are going to build a neat HTML5 file uploader using ASP.NET Web API and jQuery. We are also going to include knockout.js to keep the list of uploaded files updating smoothly in real time.

In addition to all that, we will leverage on HTML5 drag and drop events , as well as HTML5 File API, to provide the file input to the application. Finally, we will use FormData JS interface to build up the request, and we will use ApiController of our ASP.NET MVC 4 application to pick up the files and save them on the server using an instance of MultipartFormDataStreamProvider.

More after the jump.

So last time around we built together a small p2p chat app using WPF and ASP.NET Web API. Today, we are continuing our experiments with ASP.NET Web API and setting up a simple push (or push-like) messaging system between different apps using self hosting.

In fact, we’ll use one app (“server”) to push out messages to a number of other apps (“clients” or “subscribers”). Even though we have the (in)glorious WCF callbacks at our disposal, I thought it might be fun to try it that way. Hopefully, that sounds interesting, or at least intruiging. In the process we’ll also serialize custom types to JSON using JSON.NET and pass them between self-hosting applications.

More after the jump.

Recently I’ve been really enjoying myself with ASP.NET Web API. It is a tremendous beast, and with it’s self-hosting capabilities, it’s suitable as an HTTP-channeled-communication not only for ASP.NET websites, but also for any other .NET applications. In this post, I’m gonna try to show you the outcome of my weekend mash up - a peer-to-peer WPF chat application (clients connect directly to each other), fueled by ASP.NET Web API.

More after the jump.

Recently, I’ve been playing a lot with ASP.NET Web API, as it is really an exciting technology. It works exceptionally well with JSON.NET (Henrik Nielsen wrote a great post on how to return JSON from ASP.NET Web API using JSON.NET).

However, as it’s been the case in the past with i.e. WCF, I’ve run into a issue with serializing Entity Framework object to JSON when returning them from the ApiController. This is not, by any means, an issue in ASP.NET Web API, as the problem in this case lies in the EF lazy loading, which causes circular reference between the objects. This then throws a corresponding error - “A circular reference was detected while serializing an object of type (…)” if you are using JavaScriptSerializer, “Self referencing loop detected for type (…)” if you are using JSON.NET and so on.

I thought it might be useful to remind about possible solutions to this. There is an easy workaround.

More after the jump.

I’m convinced that most of us web developers often have to struggle with some sophisticated Javascript driven UI that tend to get out hand with their complexity, dependencies and relationships.

With that in mind, I wanted to show you an example of a knockout.js code in action.

Since knockout.js is one of the most amazing and innovative pieces of front-end code I have seen in recent years, I hope this is going to help you a bit in your everday battles. In conjuction with Last.FM API, we are going to create an infinitely scrollable history of your music records - just like the infinite scroll used on Facebook or on Twitter.

More after the jump.

Whenever handling an event in jQuery, be it a UI event or a programmatic event, it is very often required to pass some piece of data to it. It is common for novice developers to pull that data directly from globally scoped objects - variables or global DOM selectors - which is not the best practice, and with more sophisticated dynamic UIs it easily gets out of hand and becomes impossible to maintain in the longer run.

To avoid such issues, jQuery provides two easy mechanisms for passing data to event handlers. More after the jump.

A while a go, the C# community got surprised by another GOTCHA, discovering that using a foreach iteration variable inside a LINQ query, may not always yield the expected results. The variable gets captured by the foreach loop and, due to the evil work of closure, it remains scoped outside of the LINQ query itself living its own life so to speak. This has now been corrected in the Visual Studio 11 Beta.