As a result, I couldn’t really contribute that much to the higher-level discussions that were going on – I did more observing than talking. That did give me the chance to lurk around the edges and come away with some general impressions.

I sort of expected that this could have been a gathering of panicking people who are about to have their funding cut – but it wasn’t. Instead there seemed to be a general acceptance that there isn’t any money, anymore, and we’ve all got to get to grips with this. And it wasn’t political – I suspect that this wasn’t a gathering of natural Tory sympathisers, but it was interesting that more than one speaker explicitly ruled out outright opposition. Or indeed the less confrontational approach of just waiting another five years in the hope of a change of government.

There’s a real danger of sounding like a Daily Mail reader channelling the Taxpayers Alliance – and this isn’t intended as an ad hominem judgement of the people in the room last night – but I suspect that this is an area is similar to advertising – half of all the money pumped in is wasted, it’s just that we don’t know which half.

Sometimes it seems that for every person who delivers tangible projects that actually DO something, there about another three who spend their professional lives “coordinating”, “strategising” and producing policy papers. I’ve had enough experience of engaging with public sector funding sources to be very wary of the processes and hoops which have to be jumped through, and I wonder if we haven’t created an environment with an incredible amount of (albeit well-meaning) friction.

I can’t admit to having really understood some of the project pitches that took place – some seemed to be less tangible and more strategising – but one did strike me as having some potential, and something of a tech angle. The App Store is probably a poor title, though, because I’m not convinced that apps in the technical sense are what’s needed.

I see it as being more akin to the online stores that sell boiler-plate contracts – instead of going to a solicitor for a bespoke contract, you can buy one online for £50 and fill in the blanks. This could also get adapted to common things that seem complicated if you’ve never had to deal with them before – indemnity forms for events, what kind of liability insurance should I have for this event I’m putting on, that kind of thing.

And no doubt there *are* some things which are applications – community forums in a box, for example? It would be fairly straight-forward to assemble a toolbox of open source building blocks which could be assembled for specific online purposes on demand.

The official hub for the activities is at the Big Society In The North forum, and there’s much discussion on Twitter with the #bsitnorth tag. Watch this space, as they say…

[Update: Saul has his take on the event on his blog]

Facebook’s API enables the programmatic creation of events in much the same way as you can do through the web interface. Events can be personal, or they can be associated with groups, but either type has the same data and behaviour.

Although the “official” way of interacting with Facebook is through the Graph API, you quickly come to realise that actually, that’s not the full picture. To create and publish things like events, you end up having to tangle with the “legacy” API.

There are two basic ways of doing this, assuming that you’re using PHP. The first is to make calls to the API directly, by calling URLs like

https://api.facebook.com/method/method_name?access_token=oauth_access_token&arg0=value0&arg1=value1

using cURL or something similar. Assuming the call works, this spits back an XML message which will contain the return values.

The other (and quicker) way is to use the semi-official PHP SDK, which is available on GitHub. It’s very, very sparsely documented so can be a bit of an uphill struggle if you’re still feeling your way with the API in general.

What follows is how I’ve implemented it – it presupposes that you’ve created an application and obtained an app ID and app secret, and downloaded the SDK files.

Background

The prerequisites for all of this is being able to get a connection to the Facebook API. That goes like this:

• include the SDK files and create a new Facebook object with your app ID and app secret:

  
  // Require the SDK file from wherever you've located it
  require 'classes/Facebook/facebook.php';
  
  // Create an instance of the Facebook object, with our app's parameters:
  $facebook = new Facebook(array(
          'appId'  => $APP_ID,
          'secret' => $APP_SECRET,
          'cookie' => true,
  ));
  
  

• check that we can get a correctly-signed session using the app secret:

  
  $session = $facebook->getSession();
  
  

• now check that the session is still valid. If this works, we’re good to go.

  
  $me = null;
  // Session based API call.
  if ($session) {
          try {
                  $uid = $facebook->getUser();
                  $me = $facebook->api('/me');
          }
          catch (FacebookApiException $e) {
          error_log($e);
          }
  }
  
  

• now that we’ve got a valid session, we can start doing Facebook stuff – for example, this will display the login/logout button depending on whether the session is valid:

  
  if ($me) {
          $logoutUrl = $facebook->getLogoutUrl();
  } else {
          $loginUrl = $facebook->getLoginUrl();
  }
  
  

Creating the event

The point of this exercise is to create a Facebook event, which involves calling the events.create method. The generic way of using the PHP SDK to call API methods is:

$param  =   array(
                'method' => 'method_name',
                'method_parameter' => 'data'
                'callback'  => ''
        );
$eventInfo   =   $facebook->api($param);

The parameters that each method takes are different, and are listed on the relevant documentation page. So for events.create for example, you’d need:

$param  =   array(
        'method' => 'event.create',
        'event_info' => json_encode($event_data_array),
        'callback'  => ''
);

where

event_info

is the event information, passed as a JSON-encoded object literal. In this case, I’m doing the JSON encoding on the fly by passing in an array of the event data to the json_encode function

callback

is a string containing a function to callback (this isn’t required in this case, so is null)

Just to make figuring this out even more of an adventure, you need to cross-check the Facebook Query Language documentation to find out the full list of parameters which can go into the event data array. And even this isn’t the full picture – because it misses the fact that you can pass an additional argument called page_id to pass in the uid of a group or page, which then creates the event for that group or page. You’ll find *that* particular nugget on the Developer wiki page, which is why it pays to check ALL the documentation…

So the full code to create an event looks like this. First, build an array containing the event data:

$fb_event_array = array('name' => "Test event in Group nnn",
                        'start_time' => mktime("14","30","00","08","01","2010"),
                        'category' => "1",
                        'subcategory' => "1",
                        'location' => "Location",
                        'end_time' => mktime("15","30","00","08","01","2010"),
                        'street' => "123 Street Address",
                        'city' => "Sheffield",
                        'phone' => "0123 456 7890",
                        'email' => "info@email.com",
                        'description' => "Description of the test event",
                        'privacy_type' => "OPEN",
                        'tagline' => "Event tagline",
                        'host' => "Event host",
                        'page_id' => "nnn"
        );

[Another gotcha is that you *may* need to convert the time into UTC-10, as the API is using California time.]

Then convert that array into UTF8 encoding:

$fb_event_utf8 = array_map(utf8_encode, $fb_event_array);

Create a bundle of parameters for the SDK API call, including our UTF8-encoded event data:

$param  =   array(
                'method' => 'events.create',
                'uids' => $uid,
                'event_info' => json_encode($fb_event_utf8),
                'callback'  => ''
                        );

Then make the API call, which should return the UID of the newly-created event:

$eventID   =   $facebook->api($param);

It probably makes sense to check at this point that an event UID *has* been returned – the lack of this suggests that something has gone horribly wrong and the event wasn’t created.