For the recent SharePoint Saturday Atlanta event, I spoke about consuming Twitter data in .Net to push into SharePoint 2010 via the .Net Client Object Model. Twitter search has evolved to use a REST web service call which produces either JSON or ATOM. Since I had not yet used JSON anywhere, I decided to take the bullet and learn it, or rather at least understand it.
JSON is short for JavaScript Object Notation, all the information you might need to know can be found at http://json.org/.
Basically it is lightweight and constrains to a standard, and is being used even by the Client Object model itself.
The Twitter search term we used was #SPTwitter. We had colleagues of ours post items with the hash tag and turn on geolocation. Twitter Search API documentation can be found at http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search. When requesting the term, I used q for the query and rpp (requests per page) set to 100 to return a max of 100 results. I could use page to get more results, but 100 was more than enough to show on the Bing Maps/Silverlight example my co-worker was giving in his talk.
Code? Yep, here is what I used to query the REST service:
Now we have the JSON response in a string, and we can parse it into our .Net object. Wait, we need a .Net object AND something to de-serialize the JSON.
There are quite a few options that we could use and after working with a few of them I decided on JSON.Net. It was pretty straight forward, and is still being maintained.
JSON.Net - http://json.codeplex.com/
So I created a Tweet Class and a Container TweetCollection Class. The search results are returned in a collection, so we will have to also add some attributes to that class.
Notice the JsonProperty Attribute for “results”. This matches the collection of return results. Here is a sample:
From this example, we can see that the results collection will have individual Tweet/Status data.
So I started with a simple class, Tweet. I added the Profile Image Url and from_user fields to test it out.
Now that we have a simple class, and a collection for it, time to test the de-serialization.
The code above fills our collection and objects with real Twitter data! Not so hard, well, at least someone wrote the parser for us!
Next step was simple enough, just fill the rest of our object with the other data from Twitter. What about the GeoLocation data? It is stored in a format like the following: "geo":{"coordinates":[33.9154,-84.3518],"type":"Point"}… but can also be listed as null (see example data above). So the object geo, contains an array (coordinates) of two doubles and a key value pair for the “type”.
This turned out to be a little more complex than I thought… I followed the same pattern, geo, contained coordiates, and the type. So I created a Geo class, with coordinates and the type.
continued…
One thing to notice is that the type of coordinates did not serialize correctly. This type being null sometimes also provided some problems. I did a little research, and determined that a JsonConverter should work for what we needed. I created the following, using the JsonConverter abstract class, extracting the methods… ReadJson, WriteJson (we are not serializing it back into JSON, so I left this empty, and finally CanConvert.
Wrap that into a console or Windows app, and check your console!
Check back tomorrow for part 2, writing to SP using the Object Model.
0 comments:
Post a Comment