A lot of developers use the Javascript container to do all the application programming but you may have code existing in some other language that can be turned into a mySpace application. The following explains building an application this way from start to finish.
This article assumes you have a server outside of myspace that can run some web programming language such as PHP, ASP, iHTML, Cold Fusion, Python etc…. It would also be helpful to have a database server running on that machine (or at least accessible) such as mySQL, Postgres or MS SQL server.
The first thing to do is to create a table in your database server that has at least the following information and call it USERS. I am going to use MS SQL server datatypes for simplicity, change appropriately for your db server of choice
Networkid (big integer) – this is the users id on the social network system
Networktypeid (int) – this is the identifier for the network (we use 1- facebook, 2 – bebo, 4 – friendster, 8 – myspace, 16 – orkut, 32 – hi5, they are spaced numerically this way for bit operations at some point in the future)
Dateaddded (datetime) – the date the user installed
Session_key (varchar 32) – not used on all networks
Browser (varchar 256) – handy for knowing what browsers are being used and can be helpful for seeing trends if people are having problems and removing
Active (int) – we use an int since we generally do more than 1 and 0 for active and not active
Friends (varchar 8000) – we sometimes want to store the string of friends for doing things more efficiently than going back to the social network site for the data. Some TOS’s might not allow this so check on those first
Username (varchar 256) – the name of the user
Create a new application on mySpace to experiment with this. On the upload application XML you can load up an xml file but its not strictly needed so skip this step. Most of the data on the next page is just info about your application. The four fields that matter are
Install Callback URL, this is a url on your server that is hit by the myspace system when a user wants to install your application. What you would do on this url is generally the following
create a user account (check if it exists or not first, if it exists set active=1 since it might have been an account created already and been removed previously)
set a cookie perhaps (although not sure this will work on the install page actually)
on some networks you could set the default profile data here
do your first call back to the myspace servers to get the users name
The query string sent to your server looks like this and the networkid value to store in the users table is the opensocial_owner_id (and opensocial_viewer_id should be the same in this case)
country=US&lang=en&newinstall=1&oauth_consumer_key=http%3A%2F%2Fwww.myspace.com%2F364547168&oauth_nonce=633439974091302607&oauth_signature=cO26z1kgt0STq%2Bk8hc5e1nb2ybY%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1208400609&oauth_token=&oauth_version=1.0&opensocial_owner_id=250077925&opensocial_viewer_id=250077925&pto=COMMENTS%2CBLOG%2CBULLETINS%2CPROFILE%2CSEND_MESSAGE
Uninstall Callback URL, this is the url on your server that is hit by the myspace system when a user wants to unfortunately uninstall your application. Generally this simply does marks the record in your users table as inactive. The output from this page is just thrown away and no user ever sees it so it doesn’t need to have any real output.
Oauth Consumer Key and Oauth Consumer Secret. These are needed later on to sign requests you make back to the myspace servers.
After saving this page go to the Edit App Source link. You have 3 tabs which I’ll discuss below
Canvas Surface
For the App type select External iframe. Set the display height to what the main page of the application is going to need. You can always change this later if needed and there are ways programmatically to reset it (adjustheight). The external iframe URL is the home page of your application on your server. So enter the specific URL that users will go to when they go to your application.
Profile Surface
The profile surface is what is shown to other users when they view the user, who has the application installed, profile.
Home Surface
The home surface is what the user sees on their own private home page when they have the application installed.
In most cases the javascript for the profile and home surfaces is going to be the same or very close. The following is an example of a basic script to put in here.
<style type="text/css">
/* global */
body { font-family: verdana, arial, sans-serif; font-size: 11px; margin: 0; padding: 0; text-align: left; }
h1, h2, h3, h4, h5{ font-size: 13px; color: #333; margin: 0px; padding:0px; }
a { color:#3b5998; text-decoration: none; }
a:hover { text-decoration: underline; }
.clear { clear:both; }
a img { border: 0px; }</style>
<div id="target" style="font-weight:bold;padding:10px;"></div>
<div id="loader" style="color: #ccc;padding-left:20px;">Loading application data...</div>
<script type="text/javascript">
var app_host = "http://www.yourserverurl.com";
var app_id = "100000";
</script>
<script type="text/javascript">
function getProfile() {
var req_params = new Object();
req_params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
req_params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT;
var req = gadgets.io.makeRequest(app_host + "/myprofile.ihtml", signRequestCompleted, req_params);
}
function canvasURL(url) {
var cview = gadgets.views.getSupportedViews()["canvas"];
gadgets.views.requestNavigateTo(cview, url);
}
function signRequestCompleted(data) {
document.getElementById('target').innerHTML = data.text;
document.getElementById('loader').style.display = 'none';
}
getProfile();
</script>
The only things you really need to worry about are the appid value (change from 100000 to your app id (to find your app id, you can rollover the profile tab and it will have appid= in the URL string), change the myprofile.ihtml to the page on your server that will generate the HTML for the profile page and app_host which is your servers URL.
So now you are pretty much setup on the myspace end of things. The rest of the code goes on your server using your language of choice. Your code can do whatever it wants on your server and can make specific requests back to the myspace server using the RESTful API. There are various resources you can call such as to get the user information or the friends for a user etc…. All requests have to be signed with oAuth authentication on myspace. Other networks use different schemes.
Making Requests to mySpace
To do a request to myspace you need to use the oAUTH signature method. Requests are simple http GET’s or POST’s to the myspace servers to get information about a user or other data. There are PHP libraries for this but since we don’t use PHP we had to figure this out on our own. This is what needs to be done in a generic way that should be translatable to any language. This example gets the friends of a user. You have to generate a signature string first.
The string to generate the signature on is made like this all concatenated togetherGET& plus the request URL urlencoded (ie: http://api.myspace.com/v1/users/#####/friends) (where the ##### are the userid of the person you are getting the friends for) append an & string together the actual request which has oauth_consumer_key=yourkey&oauth_nonce=noncevalue&oauth_signature_method=HMAC-SHA1&oauth_timestamp=atimestamp&oauth_token=&oauth_version=1.0(note the oauth_token has no value but must be there, The order of the parameters matters, they need to be in alphabetical order. ) Then you URL encode the above and append it to your string you are building up. So your base string might look something like this (note what is and isn't url encoded ie its, GET&urlencodedhostrequest&urlencodedrequeststring) GET&http%3A%2F%2Fapi.myspace.com%2Fv1%2Fusers%2F6549232%2Ffriends&oauth_consumer_key%3Dhttp%253A%252F%252Fwww.myspace.com%252F354364031%26oauth_nonce%3D1206638068.1040%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1206638068%26oauth_token%3D%26oauth_version%3D1.0 Then you need to hash it with HMAC-SHA1 and base64 encode it so the text value would be your string and the key (and this is important) is your consumer secret with an & appended to the end of it. (we couldn't find a command line tool that would do an HMAC-SHA1 and base64 encode so we wrote one in C. Contact me if you would like it)Then you urlencode the result of that and that is your signature. Then you have to form your query string which has all the same stuff you built up in your request plus the signature so like this oauth_consumer_key=yourkey&oauth_nonce=noncevalue&oauth_signature_method=HMAC-SHA1&oauth_signature=yourgensighere&oauth_timestamp=atimestamp&oauth_token=&oauth_version=1.0 So your whole get request might look something like thishttp://api.myspace.com/v1/users/#####/friends?oauth_consumer_key=http%3A%2F%2Fwww.myspace.com%2F354364031&oauth_nonce=633421365057774247&oauth_signature=GASxMIk34F62SsLY4j6N8oMNrLA%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1206539705&oauth_token=&oauth_version=1.0
That request is then made by your server code and the result back is an XML structure that you can then parse to get the information you need.
Cookie and P3P considerations
If you want to set a cookie on the users browser it may or may not work depending on the browser security settings and the network. Since this is in an iframe it’s a 3rd party cookie so you need to set a P3P policy and add the following headers to responses sent back by your server.
P3P: CP="ADM DEV PSA OUR IND ONL UNI PUR NAV CNT STA INT"
In general though we have found it better to pass variables in query strings or hidden form post variables when navigating within your application.
Profile and Home Pages
These pages on your server (myprofile.ihtml in the above examples) are requested by the myspace server on every view by a user. The opensocial_viewer_id variable in the query string identifies the user viewing the profile and opensocial_owner_id identifies the profile being viewed. This page on your server would output whatever HTML (or JS) that you want to display to the user. You can use logic to show different things based on who is viewing or what profile they are using. For example you can show their score in a game or a quote or news or weather for their location or whatever your app is going to do.
It is also possible to build an application that is cross platform across all the different social networking sites as we have done with our iDRINK and Treasure Hunt applications. Those each have a single code base that works on all the networks. This has obvious advantages to keeping code standardized and easier to maintain. So while opensocial’s goal is to make cross platform applications it isn’t strictly necessary to make that happen. I’ll leave it to another article to explain all the in’s and out’s of accomplishing this.
Feel free to offer suggestion on areas on the above that need expanding or clarifying and I will update as needed. I hope you find the above useful.
To find out more about what my companies do visit http://www.inline.net or for more information on the iHTML programming language, visit http://www.ihtml.com
Looking for an application promotion tool, visit http://www.snapsavvy.com