The Naked Technologist

It’s no secret that in the group of major social networking containers they all implement their own set of rules on how developers may interact with their applications, even those “OpenSocial” compliant containers usually don’t implement the full standards body. This problem usually gives developers a great deal of stress when it comes time to move their application to another container.

For much of the high animation, interactive components flash is an excellent medium to decrease the time that you, the developer, will have to spend adjusting your app to get it working perfectly for a new container. In our case, we used the Yahoo! ASTRA library to replace some of our graphing components. We passed a JSON string to the flash object, used a JSON serialization library to parse the data and then used those data structures to build out our components.

We wanted to display a graph detailing positive versus negative voting with an overall vote line running through the middle. Below is a stripped version of the code base we used to initialize our graphing utility. The pieces that have been removed are those that handled the parsing of the inputted voting structures in order to provide the graphing point data providers with dynamic results:

import com.yahoo.astra.fl.charts.*;  			//astra library
import com.yahoo.astra.fl.charts.series.*;		//astra library

//create a new chart area
var chart:StackedBarChart = new StackedBarChart();
chart.setStyle("textFormat", new TextFormat("Arial", 12, 0x2c6076, true));
this.addChild(chart);

//create astra bar series for positive votes
var upBars:BarSeries = new BarSeries();
upBars.displayName = "Positive";
upBars.dataProvider = [5,6,3,2];
upBars.alpha = 0.7;

//create astra bar series for negative votes
var downBars:BarSeries = new BarSeries();
downBars.displayName = "Negative";
downBars.dataProvider = [-3,-2,-4,-4];
downBars.alpha = 0.7;

//create astra line series for total (positive - negative votes)
var totalLine:LineSeries = new LineSeries();
totalLine.displayName = "Total";
totalLine.dataProvider = [2,4,-1,-2];

//set chart data and styles
this.chart.dataProvider = [upBars, downBars, totalLine];
this.chart.categoryNames = choiceList;   //where choiceList is an array of choices
this.chart.setStyle("verticalAxisLabelDistance", 10);
this.chart.setStyle("horizontalAxisLabelDistance", 10);
this.chart.setStyle("seriesMarkerSkins", [,,bullet]);
this.chart.setStyle("seriesColors", [0x66e366,0xff6675,0x2c6076]);

All of the tools we used for this application may be downloaded for free:

Get: ASTRA Library
Description: A library of flash objects that may be used to build out dynamic components and applications. This was the backbone of our graph.

Get: JSON Serialization Library (corelib download)
Description: A parsing utility that will accept a JSON string and convert it to an ASON structure to allow parsing. Be careful with the data you input into this, all key value pairs must be wrapped in double quotes in order to parse correctly, single quotes or bare values will result in a parsing error.

– Jonathan LeBlanc

No Comments | In: Social Networking | tags: ActionScript, Flash, MySpace, Portability, Programming, Social Networking. | #

While working with the MySpace official and unofficial php api libraries I became frustrated with one slight bug that was causing some pains for my application. I want to note first off that both of these libraries have been great tools to save from having to use the front end javascript api library that OpenSocial defines.

For our needs, we only needed 3 things from the library…the owner profile data, viewer profile data and the owner friend data. The problem here was that no matter what arguments I supplied to the built in functions I could never get back more than 20 friends, even though the standard specifies that it allows for a return of ‘all’ friends and that 20 was just a default. So, I started hacking away at the API and OAuth.php file of the unofficial library to see if I could find a solution.

What was the problem and how was it fixed?
What it looked like is that the OAuth request for friend profile data is temperamental when it comes to the order of the parameters being passed in the query string. It appears that the ‘page_size’ parameter has to be the first parameter passed after the request URI in order for the parameters to have any effect (i.e. http://api.myspace.com/v1/users/{USERID}/friends?page_size=40…). This parameter controls how many user profiles to send back through the request and can be set to ‘all’ for all of your friends’ profiles. So, I went into the OAuth.php file and switched the order that the OAuth and function parameter arrays were being merged. There was a slight issue in the friend request function in the unofficial php api (the array values were not passing correctly to the request function) so I adjusted those features and set up that argument array so that page_size would be the first element passed in to the request.

Where is the fix?
File: http://www.nakedtechnologist.com/files/ms_unofficial_php_api_with_friend_fix.zip

All you need to do is download the zip file, unzip it and replace the unofficial library files. The zip contains all of the files that were in the original API. To do a quick setup to display friend data, you can use the following PHP code:

I saw many questions on the forums regarding what the xxxxx portion of the $key parameter is. This is the friend id of your application, which may be viewed on the add application page (e.g. http://www.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=396659585).

– Jonathan LeBlanc

2 Comments | In: Social Networking | tags: api, bugs, MySpace, Opensocial, PHP, Programming. | #

At this point everyone should have their applications built out and ready to publish on their respective container. I’m sure everyone now knows where the “publish app” or “publish to gallery” button are (or at least I would hope you would know by now ) so I’m not going to get into that on each platform. This final post is just to provide some fair estimates from a developer’s point of view on what you may encounter when publishing your application. For this post, we’ll cover two of the major containers, MySpace and Facebook.

Below is an overview of what we saw when we published applications on these two containers:

So, let’s go into some of these points in more detail:

Application Approval (timeframe / policy / process)
Let’s start with MySpace in the hot seat. During our publication phase, our application took about 5 business days to publish after the last of our reports bugs were repaired…all in all the process was about 1.5 weeks total from the first time we clicked the publish button. It should be noted that when bugs were reported back by MySpace, they were fixed and the application was re-published within about 8 hours.

So, what took so long to get this application to the gallery?

This has everything to do with the strict approval process that MySpace maintains when approving applications to the gallery. MySpace seems to have taken on the role of a full QA testing facility when you want to get your application out to the world. They will run your application through its paces, both through an automated testing environment and a human engineer looking over your app. Our first bug report from MySpace was from the automated testing script. You can expect to encounter reports such as “Excessive whitespace” if you set your canvas height too high (use gadgets.window.adjustHeight() to dynamically resize your application height) or “No external css/js references” in the canvas / home views (inline all of your javascript and css) during the automated testing round. For the first time through, this script took several hours to report these errors back to you, so check back after about 3-4 hours to see if anything has been reported. The next phase was the engineer testing. We received test case errors from these engineers saying things like “if a user doesn’t have the app installed, goes to a friend’s page with the app installed, they receive this javascript error” or other ones like “when you do this in the app, you get this error”. They thoroughly test your application to make sure it’s working well before allowing it in the gallery.

On the flip side we have Facebook with a more lax approval system. When we pushed out our application to Facebook we did not receive any bug reports back from them prior to pushing to the gallery. While our app got out quicker, most of the errors we missed in the program were found by users (sometimes phrased ever so nicely in a terms of service violation message ). There’s not much to say here besides the fact that Facebook seems to go to an engineer to look over but we did not see any evidence of an automated script process at the time we pushed this out.

Revision Policy
Now, what happens when your application makes it to the gallery and you want to change something? Again we have some platform differences. On MySpace, if you want to change anything that is controlled by the spec (generally the control flow or any inline code) you’ll need to re-publish your app. Don’t worry though, each time we did this the process only took about 20 minutes to do a quick automated test and then the changes were pushed. Facebook seems to allow you to change every aspect of an application after publishing without having to send it through the checks and balances from the container.

Communication
Here’s one area that both of the containers were the same in, that of the communication between the developers and the container & engineers. In both instances, with the exception of reported bugs, we did not see one notice of where our application was in the testing queue, when it might be approved, nothing… it was as if our application dropped into a black hole and was gone until it was pushed to the gallery. What we would have loved to see is some sort of queue counter where we could see how many apps needed to be tested before ours…and maybe when it was being tested, what it had passed and where it was in the testing.

Many application developers build their applications to reach the most people they can. While I would love to say that one platform is better than the other, I can only make note here that both have a large user following and if you can port your app to both of these platforms it’ll be better for it. This guide was developed more to present some of our experiences during the process so that no one is surprised along the way.

– Jonathan LeBlanc

No Comments | In: Social Networking - Building an Application | tags: Facebook, Guides, MySpace, Opensocial, Social Networking. | #

Before working on the construction of your first social networking applicaiton, you should have already set up all of the accounts you will need to work with the container of your choice.  If you have not yet done so, please refer to the previous post detailing account setup requirements.

So, you’ve created your accounts and want to begin building an application…how do you do that? First off, for all of the social containers you’re going to have to have some web hosting solution where you can host your application online. How this process will basically work is that you will host the application on your web server, point your social container application to your hosted files, and voila!

Here is a basic guide for each of the containers on what you’re need to do to construct you application:

• MySpace
  1. Go to your MySpace Application View and click the “Create New App” button.
  2. Fill out the application setup information. Note here that the e-mail address entered must be unique to MySpace. The method MySpace uses for creating an application is to build a profile for the application, hence the need for a unique e-mail address.
  3. There are a few methods for building out your application. You can reference the MySpace getting started pages for more details.
• Orkut
  1. Go to http://sandbox.orkut.com/Main#MyApps.aspx to view your application page.
  2. This page will allow you to access / edit your applications in a similar way as MySpace.
• Facebook
  1. Click on the developer application from your Facebook profile.
  2. Click on the “Set up New Application” button at the top right of the page.
  3. Add in your application information

Below is a container comparison on what’s available to you on each of the platforms:

Application Setup

There are some differences between some of the major containers and how they implement their setup process. MySpace and Orkut both required a specification XML file (basically just an interface for setting up how your application will run and be configured). The main difference between MySpace and Orkut in their process is that MySpace allows you to change what spec file you would like your application to use at any point (again – no using the same spec file for multiple applications – this is restricted by MySpace) but Orkut requires you to create a new application if you would like to use a new spec file. Facebook takes a more intuitive approach in that they just have a configuration panel which will allow you to set up your application details.

Sample Application Generator

The sample application generator is a great tool if you’re just starting with a platform. This will allow you to automatically create a “hello world” application without having any experience on the platform.
MySpace and Facebook both offer this utility and, if you’re just starting out, I would definitely take a look at this tool.

Supporting Docs / Development Forums

All of the major containers have documentation (be it official or unofficial) which support the platform. This ranges from API documentation, code samples, to fully user supported specification standards…so your choice in container might range around what level of documentation you prefer.

Test Harness / Developer Tools

The test harness (developer tools) is a utility available to developers to allow them to test out container compliant code or widgets and get back a visual representation of what that script or widget will render as on the platform. Why do you need this tool when you have your own development environment? Well, this tool is great for testing out new container widgets when you don’t want to have to deal with uploading to your server, invalidating cache, etc. I have not found much use out of these tools once my application became very integrated with a database or server side structure set.

The final post in this basic setup series will follow pushing your application to the container gallery and the approval process.

– Jonathan LeBlanc

No Comments | In: Social Networking - Building an Application | tags: Facebook, MySpace, Opensocial, Orkut, Social Networking. | #

In the first of a series of discussions on the topic of “building a social networking application”, I’m going to take you through a day in the life of a developer.  This post will cover setting up accounts on some of the major platforms and how to get started with your application building.  These are by no means absolute answers, but are some of the experiences we have gone through.

So, you’re building your first application and want to know what you’re going to need to do, what you’ll need to set up and how long it’s going to take. Here’s a comparison of some of the major social networking platforms and their offerings:

So what’s next for starting up? Documentation of course! Below are some great resources for getting started and learning about what’s available on the platforms.

Getting Started Guides

• MySpace: http://developer.myspace.com/community/
• Orkut: http://code.google.com/apis/orkut/
• Facebook: http://developers.facebook.com/get_started.php

Code Documentation Sources and Samples

• MySpace: http://developer.myspace.com/community/myspace/referenceIntro.aspx
• Orkut: http://code.google.com/apis/orkut/docs/index.html
• Facebook: http://wiki.developers.facebook.com/index.php/Main_Page

Stay tuned for the next post in this series which will cover the application development process.

– Jonathan LeBlanc

No Comments | In: Social Networking - Building an Application | tags: Facebook, MySpace, Opensocial, Orkut, Social Networking. | #