Building a Social Networking Application – Publishing


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:

 
MySpace
Facebook
Approval Timeframe
About 1 week
About 2-4 days
Approval Policy
Strict
Lax
Approval Process
Automated QA script
Human Tester
Human Tester
Revision Policy
External includes changeable
Spec file required re-submission
Fully changeable
Communication
No communication unless approved or bugs found
No communication unless approved or bugs found
 

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

  • Share/Bookmark

No Comments, Comment or Ping

Reply to “Building a Social Networking Application – Publishing”

You must be logged in to post a comment.