Project: Facebook Data Liberation — Part 4 — Reading Feeds

Back in Part 1, I explained why I’m making this HTML5 application. The condensed version of the story so far is that I’m making is a web/mobile app that can read a running/fitness Facebook group feed. Now we are up to Part 4 where I will show you how to pull a group feed using JavaScript.

I want to get all the feed data for the group.  Since there are more than 1000 posts, I can’t just grab everything in one pass.  Instead I will be using the “since” and “until” parameters to break the posts up by time.  For the Facebook API, you specify the since/until using a Unix timestamp, which is pretty much just the number of seconds since January 1, 1970.  Here is a JavaScript snippet to set two timestamps, one for now and one for 30 days ago:

var date = new Date;
var timeend = parseInt(date.getTime() / 1000);
var timestart = timeend — (30 * 24 * 60 * 60)

You can see that I need to divide the getTime() call by 1000.  That’s because the JavaScript Time uses miliseconds since Jan 1, 1970 rather than seconds.    

Now that I have the start and end time, I will use jQuery to make an Ajax call to get the feed:

function getBatch() {    
    var accessToken = window.location.hash.substring(1);    
    url = “https://graph.facebook.com/YOUR_GROUP_ID/feed?limit=500&since=” + timestart + “&until=” + timeend + “&” + accessToken;    
    $.ajax(url, { complete: parseFeed });
}

function parseFeed(jqXHR, textStatus) {    
    var data = $.parseJSON(jqXHR.responseText);   
    displayData(data);    
    timeend = timestart;    
    timestart = timeend — (30 * 24 * 60 * 60) ;   
    if (timeend > stop_here) { getBatch(); }
}

When getBatch is called it will build up a URL and then make an Ajax call to Facebook.  The URL for that call is constructed as described in Part 1, but the API is simple enough that you can probably tell what each parameter does just by looking at it.  When the Ajax call returns with the data, parseFeed is executed.  You can see that parseFeed does three things:  First it reads the data.  Second, if moves the start/end timestamps back another month.  Finally, if the timestamps haven’t gotten back to my hard coded “stop_here” timestamp, it will call getBatch again to grab the next set of posts.

This is a simple way of paging, and it works fine for my group because I know that I can retrieve all the posts in a time window with one call.  A production level getBatch/parseFeed pair would use the previous and next page URLs that Facebook provides as part of the feed.  I’ll leave that as an exercise for the reader for now.  That is pretty much all the “moving parts” for my project.  I have a prototype working and it’s doing exactly what I want.  Right now the code is locked into working with a particular group, and it only does two small things: list all the posts in the group and make a guess at the number of miles run by group members.  The next step is taking a critical look at the whole thing and deciding if I should try to build this out into a “real” app that anyone can use.

Project: Facebook Data Liberation — Part 4 — Reading Feeds

Back in Part 1, I explained why I’m making this HTML5 application. The condensed version of what I’m making is a web/mobile app that can read a running/fitness Facebook group feed. Now we are up to Part 4 where I will show you how to pull a group feed using JavaScript.

I want to get all the feed data for the group.  Since there are more than 1000 posts, I can’t just grab everything in one pass.  Instead I will be using the “since” and “until” parameters to break the posts up by time.  For the Facebook API, you specify the since/until using a Unix timestamp, which is pretty much just the number of seconds since January 1, 1970.  Here is a JavaScript snippet to set two timestamps, one for now and one for 30 days ago:

var date = new Date;
var timeend = parseInt(date.getTime() / 1000);
var timestart = timeend — (30 * 24 * 60 * 60)

You can see that I need to divide the getTime() call by 1000.  That’s because the JavaScript Time uses miliseconds since Jan 1, 1970 rather than seconds.    

Now that I have the start and end time, I will use jQuery to make an Ajax call to get the feed:

function getBatch() {
    var accessToken = window.location.hash.substring(1);
    url = “https://graph.facebook.com/YOUR_GROUP_ID/feed?limit=500&since=” + timestart + “&until=” + timeend + “&” + accessToken;
    $.ajax(url, { complete: parseFeed });
}

function parseFeed(jqXHR, textStatus) {
    var data = $.parseJSON(jqXHR.responseText);
    displayData(data);
    timeend = timestart;
    timestart = timeend — (30 * 24 * 60 * 60) ;
    if (timeend > stop_here) { getBatch(); }
}

 

When getBatch is called it will make an Ajax call to Facebook.  The URL for that call is constructed as described in the previous parts, but the API is simple enough that you can probably tell what each parameter does just by looking at it.  When the Ajax call returns with the data, parseFeed is executed.  You can see that parseFeed does three things:  First it reads the data.  Second, if moves the start/end timestamps back another month.  Finally, if the timestamps haven’t gotten back to my hard coded “stop_here” timestamp, it will call getBatch again to grab the next set of posts.

This is a simple way of paging, and it works fine for my group because I know that I can retrieve all the posts in a time window with one call.  A production level getBatch/parseFeed pair would use the previous and next page URLs that Facebook provides as part of the feed.  I’ll leave that as an exercise for the reader for now.  That is pretty much all the “moving parts” for my project.  I have a prototype working and it’s doing exactly what I want.  Right now the code is locked into working with a particular group, and it only does two small things: list all the posts in the group and make a guess at the number of miles run by group members.  The next step is taking a critical look at the whole thing and deciding if I should try to build this out into a “real” app that anyone can use.