Categories
App PHP

How to Create a Facebook Application to Get an App ID for my Website or Blog

Facebook has updated the way you integrate your website into its Open Graph, and how you set up Insights, Facebook’s analytics tool, to see how users are interacting with the social plugins — primarily the Like Button and the Comments Box — you’ve added to your website’s pages.

In this tutorial, I will describe the steps necessary to integrate your website with Facebook, by getting an App ID for your site and adding the Open Graph meta tags to your site’s pages.

Setting up your Website as a Facebook Application
First, you must set up your website as a Facebook “application” which provides you with an Application ID you use to integrate your website into Facebook’s Open Graph, so you can add Facebook’s Social Plugins to your site.

Installing the Facebook Developer Application
The first step in creating an application in Facebok is to install the Facebook Developer application.
To do that, log in to Facebook and then visit the URL http://facebook.com/developers.
If this is the first time you’ve installed the Developer Application, you will see the Request for Permission dialog show below:

Click the Allow button to proceed.

Creating the Facebook Application for your Website
Now that you have the Developer App installed, click on the Create New App button.

Give you application an “App Display Name” (the name displayed to users).

For purposes of this tutorial, you don’t need to have a “Namespace”.

Click the “I agree to Facebook Platform Policies” box; then click the Continue button.

On the next screen, enter the security phrase and then click Submit.

There are a lot of options you can tweak related to your application. In this post, we are going to focus on the basics needed to get your website set up with a Facebook App ID.

The Settings Tab
This is where you do the basic set up for your app.

For the purposes of this tutorial, you need to concern yourself only with the Basic Settings which will suffice for setting up your website as an application to get an App ID.

OK, there’s your App ID! You’re almost there. Your App ID is the value you’ll be using to integrate your website with Facebook’s APIs so you can add the Social Plugins (Like Button, Send Button, Comments Box, etc.).

For the purposes of this tutorial, you won’t need your “App Secret” value.

Second, notice the “edit icon” below the App Secret. You don’t need to add an icon. If your website has a favicon, it will be displayed next to your site’s URL in Facebook Insights.

Basic info:

  • App Display Name: Make this the same as the original value you provided;
  • App Namespace: Leave blank;
  • Contact Email: Where you want Facebook to send emails regarding your app;
  • App Domain: just put “mydomain.com” where “mydomain.com” is your website’s domain URL (TLD);
  • Category: Select a category from the pulldown list (optional).

Cloud services
This is not applicable for a “website” Facebook application.

Select how your App integrates with Facebook
It’s here where you tell Facebook that your App is a website or blog.

Once you’ve filled in your website or blog URL, click the “Save Changes” button and you’re done!

Your website is now an “object” in Facebook’s Open Graph, with its own App ID.

'Coz sharing is caring
Categories
PHP

OOP vs Procedural Code

After being the part of long discussion this evening, I felt that I should write a post about the real differences between OOP and Procedural coding styles. Hint: whether you use classes and objects or not has very little to do with the answer…

Procedural Programming

Wikipedia defines procedural programming as:

Procedural programming can sometimes be used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm, derived from structured programming, based upon the concept of the procedure call.

That’s a decent definition, but let’s see if we can improve upon it. I’m going to assert here that procedural programming is really just the act of specifying a set of ordered steps needed to implement the requested functionality. How those steps are implemented is a detail that’s not related to the paradigm. The important thing is that it’s imperative in how it works. Let’s look at a few examples:

Obviously procedural:

$m = mysqli_connect(...);
$res = mysqli_query($m, $query);
$results = array();
while ($row = mysqli_fetch_assoc($res)) {
    $results[] = $row;
}

This is also procedural, even though it uses an object:

$m = new MySQLi(...);
$res = $m->query($query);
$results = array();
while ($row = $m->fetch_assoc($res)) {
    $results[] = $row;
}

This is still procedural, even though it uses a class:

class GetResults {
    public function getResults() {
        $m = new MySQLi(...);
        $res = $m->query($query);
        $results = array();
        while ($row = $m->fetch_assoc($res)) {
            $results[] = $row;
        }
        return $results;
    }
}

Note that all three of those examples use the exact same code structure. The only difference between them is the way the routines are resolved. But each is procedural. Each has discrete steps that must be taken. Let’s look at what OOP is and why this is different…

Object Oriented Programming

Wikipedia defines object oriented programming as:

Object-oriented programming (OOP) is a programming paradigm using “objects” – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstractionencapsulationmessagingmodularitypolymorphism, and inheritance.

Again, that’s a decent definition. But I only agree with the second part. The first sentence says that you must use object data structures to write OOP. That’s blatantly wrong. You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure. What I’d argue makes code OOP is a few things. First, it must abstract the data concepts into modular units. Second, it must have some way to polymorphically execute code. Finally, it must at least partially encapsulate that code and functionality. Let’s look at a few examples before continuing further:

A classic OOP pattern:

class Mediator {
    protected $events = array();
    public function attach($eventName, $callback) {
        if (!isset($this->events[$eventName])) {
            $this->events[$eventName] = array();
        }
        $this->events[$eventName][] = $callback;
    }
    public function trigger($eventName, $data = null) {
        foreach ($this->events[$eventName] as $callback) {
            $callback($eventName, $data);
        }
    }
}
$mediator = new Mediator;
$mediator->attach('load', function() { echo "Loading"; });
$mediator->attach('stop', function() { echo "Stopping"; });
$mediator->attach('stop', function() { echo "Stopped"; });
$mediator->trigger('load'); // prints "Loading"
$mediator->trigger('stop'); // prints "StoppingStopped"

The same pattern, using functions.

$hooks = array();
function hook_register($eventName, $callback) {
    if (!isset($GLOBALS['hooks'][$eventName])) {
        $GLOBALS['hooks'][$eventName] = array();
    }
    $GLOBALS['hooks'][$eventName][] = $callback;
}
function hook_trigger($eventName, $data = null) {
    foreach ($GLOBALS['hooks'][$eventName] as $callback) {
        $callback($eventName, $data);
    }
}

As you can see, both follow the Mediator Pattern. Both are object oriented, because they both are designed to de-couple caller from sender. Both provide state, and are modular. The difference here, is that one is implemented using a traditional object (and is hence reusable, a very good advantage) and the other is not reusable since it depends on a global variable. I used the term “hook” here for a very important reason. It’s the name of the event system that Drupal uses.

Drupal in a lot of ways is very object oriented. Their module system, their hook system, their form system, etc are all object oriented. But none of them use objects for that. They use functions and dynamic dispatch. This leads to some really awkward tradeoffs, so I’m not suggesting that it’s a good thing, just that it’s a proof that you don’t need classes to write OOP.

Why does it matter?

It matters for a very simple reason. A lot of developers think that just because they use classes, they are writing OOP. And others think that because they use functions, they are using procedural programming. And that’s not true. Procedural vs OOP is an approach to writing code, not how you write it. Are you focusing on “Steps” and an ordered way of writing a program? You’re likely writing procedural code. But if you’re focusing on state transformations and encapsulated abstractions, you’re writing OOP.

Classes are just a tool that make writing real OOP easier. They aren’t a requirement or a indicator that you’re writing OOP.

Just My $0.02…

Update: OOP Database Access

So, some of you are asking what database access would look like in OOP code. The reason that I didn’t include an example is that it’s all abstracted away. In reality, the way that I would do that query could be:

$mapper = new PersonDataMapper(new MySQLi(...));
$people = $mapper->getAll();

Where $people is an array of person objects. Note that it’s a responsibility that’s abstracted away. So in your business objects you’d never access the database directly. You’d use a mapper to translate back and forth from your business objects to the data store. Internally, a specific mapper will build a query, execute it, and fetch results, but that’s all abstracted away. We can change the implementation detail of the database layer by simply swapping out a mapper.

The responsibility of data persistence becomes an encapsulated abstraction. And that’s why it’s not procedural but object oriented…

'Coz sharing is caring