One of the cooler features that comes with LightSwitch in Visual Studio 11 Beta is it’s support for attaching to OData Services and exposing it’s own data as an OData Service.
OData stands for Open Data Protocol. It’s an open protocol that defines how to expose your data for querying and updating. This enables consumers (like LightSwitch) to connect to an OData service like it would with other data sources, for example SQL.
There’s more and more places out there exposing their data through an OData service (see some at http://odata.org/producers).
One of the slickest ones that I have found is the Public Transit Data Community (PTDC) service. This OData feed is combining all the different public transit data feeds from around the United States and exposing them through one well defined OData feed.
The PTDC has made some nice progress so far and is exposing transit information for over a dozen different agencies. I’ve got a favorite agency on this list and that would be the Washington DC Metro agency or ‘WMATA’ for short.
If you’ve ridden the DC metro (or any subway system) more than a couple times you’ve probably found yourself wondering a few things like:
2) When is my train arriving?
4) My personal favorite – how many escalators will be broken today?
We can figure all this out by making a LightSwitch app that consumes this OData Service.
We’ll keep it simple for this blog post, and then expand on some features over a couple more blog posts. Here’s the rundown of what we are going to accomplish in this blog post (we’ll add some more functionality in the next post):
For those of you familiar with LightSwitch V1, you’ll find that consuming OData with LightSwitch is just as easy as if you were consuming a SQL database.
Let’s get started walking through the creation of our simple app to simplify our life on the DC Metro.
We need to limit the data that we get back to be specific to the DC Metro for the purpose of our app. To do that we can create some queries based off the entities to limit it to just the DC Metro agency.
You should have three queries now, one each under entities: Arrivals, Routes, and Stops.
Each query makes sure that we only get data for the DC Metro system. Additionally the Arrivals query makes sure that we get the data returned to us in order of their arrival time with the “arriving” trains coming back first.
The Routes entity has a FinalStop0Id and a FinalStop1Id. These two properties represent the two different ending “Stops” of the Metro route. These aren’t very intuitive when viewed on a screen and we need to clean these up a little bit to give them a proper readable name.
We’ll add some computed properties now to accomplish this. Add two properties to this entity called FinalStop0Name and FinalStop1Name. After this is done, right click the table entity “Routes” and select View Table Code.
There’s a couple things going on here. The FinalStopName_Compute methods find the Route’s two different stop’s name instead of just using the Id. They do this by using a LINQ query which says: For some variable q, find me all the stops on the Stops entity that have the same Id value as this Route’s stop.
The only trick here is that we cached all of the stops on the Stops entity the first time that we launched our screen. We do this because Metro Stops don’t ever change their names. So we can safely cache this information and then our Compute methods can query against the cached list of Stops which will speed things up a bit.
I want to stress here though that this method of caching is really ONLY appropriate for "static" data. That is data that we know won't be changing. I felt comfortable caching the names of the Metro Stops as I said, because that really is data that won't change. But you obviously would NOT want to cache, for example, the "Arrivals" entity this way because that data is definitely not static and using this method would result in you having old data in your cache.
You should have a Routes entity that looks something like this:
Let’s create some screens around the queries that we made now. These screens will be read only, because the OData service we are querying against is read only. So we will want to remove our insert, edit, and delete buttons. Also, we’ll clean up our screens a bit to remove some useless data.
Hit F5 now in Visual Studio to run it and check out some of the features of the application and what LightSwitch provides.
The Metro By Arrival Time screen shows us the arriving metro trains, how many cars are arriving, what the status is (BRD for Boarding or ARR for Arriving), and what the destination stop is.
The Routes screen has the stop information for each route, as well as a clickable map of the route. If you click on the Kml link it will open up in an application like Google Earth and provide an overview of the route (see below).
And lastly the Stops DC Metro screen displays the location and name of each stop.
To summarize what we’ve covered up to this point - we gave a basic example of how Visual Studio Light Switch can attach to a public OData feed. We showed the new web address data type. We utilized computed fields with caching to improve our performance. And we used queries to narrow down our data.
We still have a few problems we need to get to in the next blog post. We will customize the Stops screen so that it can provide us with a map of the Stops location instead of just latitude and longitude coordinates. The Incidents data contains all the information we want regarding broken escalators, so we will need to hook that up too so that we can retrieve that information for each given stop. Also, since this data is done in “real time” it’d be nice to add some automatic refresh to our application so that our data we are viewing doesn’t get too stale.
I’ll be looking to update the blog again sometime next week, until then feel free to leave any comments or questions and I’ll do my best to get back to them.
Thanks a lot, Cheers -
CODE IS UPLOADED NOW FOR VB.NET