Orkut Application Platform

On-Site Application Developer Guide: Submitting your Application

This section will give you a complete overview of what you must do to submit and maintain your on-site application throughout its lifecycle. We will presume that you are done developing and testing your application, and that it is ready to be published.

Contents

Before you submit

Before you submit your application for review, please review the Common Causes for Review Failure very carefully to make sure your application is in full compliance. Also, please be aware that the following problem will cause your application to be rejected and you will not be notified.

Important note about URLs: Once you submit your application, you will not be able to change its URL. Therefore, we advise you to use a stable URL that you will be in control of for the entire lifetime of your application. If you must move your application to a different URL, it will be necessary to delete your old application and submit a new one, and users will have to install the new one manually.

A Word About Serious Violations

There are some problems with applications that are considered very serious violations of our Developer Guidelines, and which are dealt with specially. These restrictions are designed to protect Orkut from malicious applications, therefore the policy for this kind of problem must be harsh. You should be aware of these policies in order to make sure that your application does not accidentally violate them.

URL Redirection

One of the most common methods used by malicious applications is redirecting the user to another website. This is not allowed in Orkut and is interpreted as a clear sign that an application is malicious. Therefore, any application found to be redirecting the user to another site, or found to contain code that does so, whether that code be executed or not, whether that code be commented out or not, will be automatically rejected without any notification.

The analysis we perform is very thorough and analyses the code both static and dynamically. So even if your redirection code never executes or is commented out, it will still cause AppReviewer to catch it.

Therefore, do not, under any circumstances, introduce code that accesses or modifies (or seems to access or modify) any property of the top browser window. This will cause your application to fail review and it will be removed from Orkut.

Name Changes after Publication

Any application that changes its name after it's been published is subject to immediate removal without any notification, should that name be found to collide with, or seem to collide with, the name of another existing application. This measure is in place in order to prevent malicious applications from "assuming the name" of popular and successful applications in order to trick users into installing them.

Therefore, in order to make sure that your application will not be removed, please do not change its title after it has been published. Our name clash detection algorithm has a very broad definition of what names are considered to be "similar", so even if you search the directory for similar names, you will not likely cover all the cases of similarity that AppReviewer catches. Therefore, just because you cannot find a particular name in the directory, don't assume that it's guaranteed not to collide with other names.

Accessing Suspicious Resources

If your application accesses URLs or other resources that are reported as malicious, your application can be removed without notice as well. Therefore, please make sure that you only access your own resources, hosted on your own server. Do not access resources hosted on third-party services. Be especially careful about user-provided content, since they may contain malicious links or content.

A Word About Launches with Deadlines

The application submission process on Orkut is simple and it usually only takes a few days for your application to appear in the Orkut directory. However, please be aware that if your application contains errors, it will not be approved and must be submitted again after fixing the errors, and this delay might increase the total time required for your launch.

In a worst-case scenario, the submit-correct-review cycle might require several iterations. This is unusual if you've followed our best practices, but it could happen. Therefore always allow an ample amount of time for the application submission process to account for any corrections and resubmissions that might be necessary until your application is approved.

This is an especially important advice if you have scheduled a marketing or advertisement campaign for your application. Doing so before your application is approved is very risky, as it might not be approved in time for your campaign's launch.

Our advice is, therefore, only to promote or advertise your application after it has been approved and after it has been "live" and working correctly for at least 72 hours (to account for the time it takes for the databases to replicate across our servers).

Submitting your application

When you are finished editing your application and you are ready to publish it, you have to Submit it. To do that, look up your application in the Developer Page and click the corresponding "Submit" button. You will then be shown a Verification Token similar to the following:

<!-- AafoiwejfaowijwJFWijKEJie2323jLJ2355849872jLjfLdkj40420248gj  -->
You must now copy that token and paste into your application's XML. This is done to verify that you are indeed the owner of the application (we presume that if you can write an arbitrary string to it, then it must be because you own it). Please make sure to copy the whole token. It ends in "-->".

This verification token must go into the <Content> tag of your XML. You you put it anywhere else, the verification service won't find it. And please use <![CDATA[ ... ]]>, otherwise there might be escaping problems that will prevent your application from being verified. Also, do not split the token into multiple lines. Leave it entirely on the same line:

<Content>
<![CDATA[
<!--ALm6fM2hd...........-->
...your content here...
]]>
</Content>

After you have added this string to your XML, you should verify that it is being served with that string. You can do that by opening a different browser and pointing it to your XML's URL, for example, and checking that it's showing the XML with the verification token, or you can do it using command-line tools such as wget or curl. If you see the plain XML without the verification token, please take action to correct your server's configuration, as there might be a caching issue that is preventing it from serving the updated file.

After checking that the new XML with the verification token is indeed being served, you will be ready to click the "Verify" button on the Developer Page, which appears right under the Verification Token.

After that, the page will display a Consumer Key and a Consumer Secret. These values are not currently useful (*), and they must not be confused with the consumer key and secret used for the 3-legged OAuth API that off-site applications use. However, please write down those values or copy them and paste them to a place of your choice, as these values will never be shown again and cannot be recovered, and might become useful at some point in the future.

(*) in reality, these credentials were at one point used for the gadgets OpenSocial REST API, which is no longer maintained.

Wait for Approval

If the previous step ended successfully, then your application must now be showing as 'pending', in orange, on the page. This means that your application was submitted and is awaiting review. Now you must wait until our team reviews your application (the piece of software on our side that does this is called AppReviewer). Normally, the review process should take 48 hours or so.

Important: The Developer Page may be showing a state that's not current. This means that after you submit your application and it shows as 'pending', it may seem to revert to its previous unsubmitted state, but that's because the page is reading from a cache. So recent status changes (from "testing" to "verified" and from "verified" to "pending", for example) may not appear on the page for several minutes, even though it did seem to change at first. When in doubt, wait a few minutes and reload the page.

After your application is reviewed, you will receive an e-mail indicating whether your application was approved or not, and, if not, AppReviewer will tell you the reason.

If you don't receive an email from AppReviewer within a few days, please check your spam box, and check that the email you wrote on the application XML as the author_email field is indeed correct. If you find that you did not receive any email from AppReviewer, please complain to us on the forum, and provide your appID so we can look into it and provide assistance.

Dealing with AppReviewer Errors

If you receive an email indicating that your application has errors, you must fix your application and submit it again. The message will tell you the nature of the issue and will often suggest ways to fix it. For example, if the error is in a URL that your application uses, it is probably because our servers are having trouble fetching the asset from that URL. Please check that it is spelled right. If it is spelled right and you can access the asset yourself, then perhaps your content provider is not reliable: it may work for you now, but when we try to pull it, the server might be overloaded and giving us a temporary error. Also, please take a look at "Common causes for AppReviewer failures" below.

If the URL error is on an internal orkut cache URL (or on the "gmodules proxy") or on a URL that is under the control of a Google service, this is probably a bug on our side. In the (unlikely) case that happens to you, please complain on the developer forum.

Common Causes for Failed Reviews

The following are commonly seen causes for an application to fail review:

  1. XML syntax errors. Your syntax is incorrect, or you are missing one of the required parameters (author name, author e-mail, screenshot, thumbnail, etc). Refer to our XML example below.
  2. HTTP errors. Your resources cannot be fetched. They may work when you try them manually, but perhaps they are only available some of the time, and were offline when we tried to fetch them. Please switch to a reliable hosting service.
  3. Trademarks. You are using a registered trademark in your application. You may not use "Google", "orkut", or any other trademark you don't own. So if your application is using any unauthorized trademarks, you will not get approval.
  4. Your application has, or links to, objectionable content.
  5. Your application redirects the user to another application or page, or does any other suspicious trick with the browser. You are not allowed to do that.
  6. Your application shows popups. You may not do that.
  7. Your application has a security breach which allows it to be exploited maliciously.
  8. You are violating one or more of our Developer Guidelines. We have manual/automated tests that verify compliance to them.
  9. Here is an example of an application XML with all the required attributes:

    <?xml version="1.0" encoding="UTF-8"?>
    <Module>
       <ModulePrefs title="Your App Title Here"
          author="Your name here (or your company's name)"
          author_email="yourem...@domainhere.com"
          description="A description of your app here"
          screenshot="http://url/of/your/screenshot.jpg"
          thumbnail="http://url/of/your/thumbnail.jpg">
    
          <Require feature="opensocial-0.8" />
       </ModulePrefs>
    <Content type="html">
    <![CDATA[
    
    <!--ALm6fM2Ja1z....-->
    
    ...your content goes here...
    
    ]]>
    </Content>
    </Module>
    

    Receiving Approval

    If you fix all the problems in your application (if there were any), and submit your application again, you'll eventually get a message from AppReviewer saying your application was successfully reviewed and published. Congratulations!

    Warning about DB Propagation: It may take up to 72 hours for our database to fully replicate to the production environment, so you may have to wait up to 72 hours after approval to see your application go live. In the first 72 hours after approval, it might appear in the directory but we recommend that you wait a few days before starting any promotion, as it may take the full 72 hours to replicate to all the servers we have. Before that happens, it might be available on some servers but not on others.

    Updating your Application

    You do not need to resubmit your application in order to update it. Once you change your XML, the changes are automatically live. However, due to caching, some assets (notably graphics) may take a while to go stale and refresh (a few hours, typically). So, if it all possible (and this is a general recommendation for any Web development), use a different resource name if your resource's content has changed. That may help solve the caching issues. In any event, our internal asset cache should normally refresh its version of your assets in at most 24 hours.

    Important: our review process runs continually, so if you introduce a change in your application that causes it to fail review (say, for instance, you broke the XML's syntax or changed the screenshot to something that's causing an HTTP error), it may be taken down and rejected. If it is taken down and rejected, you will have to fix the problem and, in this case, submit it again, as it will not be automatically reviewed again after a rejection. If the error is not serious enough to grant a rejection, you may receive an email telling you a deadline to fix the problems. If your application continues to fail review past that deadline, it will be taken down.

    Tip: Using Version-specific Assets

    One of the recommeded ways to do application updates is to always use version-specific assets. For example, on version 1 of your application, your screenshot would be hosted at http://.../myapp/v1/screenshot.jpg. Likewise, any other assets would all be located at the "v1" directory... for example, your theme song that your application plays could go into http://.../myapp/v1/theme.mp3. Your XML would be http://.../myapp/v1/app.xml. But that's NOT the one you submit to orkut -- instead, make a link (or copy) in http://.../myapp/latest.xml. THAT's the one you submit (notice that this one is not tied to any version -- it's by definition the LATEST launched version).

    Now, when developing an update, all you have to do is create a new directory on your server, "v2", starting out with a copy from "v1". You can update your screenshot, theme song and any other assets there (careful to update the URL's to say v2 instead of v1), including the XML, which now lives at http://.../myapp/v2/app.xml.

    When you want to launch version 2, all you have to do is replace the link (or copy) so that http://.../myapp/latest.xml now points to (or contains a copy of) http://.../myapp/v2/app.xml.

    Since the asset URL's are all different, caching at any point in the pipeline won't be an issue (the new never-seen v2 assets will be fetched), and your new version will launch as a whole, without having to wait for assets to individually refresh on the cache.

    Also, if you ever want to test a specific past version of your application, all you have to do is go into the sandbox and load the path to the specific version's XML and play it. It will come with that version's specific assets, so doing that, you obtain the effect of "going back in time" and seeing a specific version of your application. Twenty years from now when you're in version 1492, you might even be able to offer your users the ability to play the "vintage" version 1 of your application!

    Tip: Same-Developer Policy for Name Clashes

    While our algorithm is very strict with name clashes to prevent applications from having similar names, there is one legitimate use case that we allow: two applications can have similar (or even identical) names if they are owned by the same developer account. This allows developers to publish games with similar names.

    Therefore, if you have two applications with similar names (such as, for example, Example App and Example App 2 or Super Example App: The Remake), you must submit them from the same developer account in order to avoid a name clash.

    Tip: Managing More Than 25 Applications

    Orkut imposes a limit to 25 simultaneous applications per account. So, if you are a developer with several applications published, you might have to create different developer accounts. However, this may cause you name clash problems, therefore you might want to organize your applications by theme and distribute them accordingly among your developer accounts.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.