How sforce.one Handles API Versions
By default, sforce.one uses the same version as the API version of the requested Visualforce page. For example, if a Visualforce page has an API version of 30.0, JavaScript on that page that uses sforce.one by default uses the API version 30.0 of sforce.one.
This means that when a Visualforce page is updated to a new API version, the page automatically uses the updated version of sforce.one. In the preceding example, if that Visualforce page is updated to API version 31.0, app functionality that uses sforce.one uses the API version 31.0 of sforce.one.
- Revert the Visualforce page’s API version to the prior version. This action requires no code changes.
- Update the code for the page’s features to fix the problem. This solution is best, but it might require some debugging, and it will definitely require code changes.
- Use a specific version of sforce.one. This solution often requires minimal code changes.
Using a Specific Version of sforce.one
To use a specific version of sforce.one, use the sforce.one.getVersion() function and provide it with the API version and a callback function that needs to use a specific version of sforce.one. The appropriate versions of sforce.one are automatically loaded by this call.
versionString is the API version that your application requires. It’s always two digits, a period, and one digit, such as “30.0”. Calls with invalid version strings fail silently.
callbackFunction is a JavaScript function that uses a specific version of sforce.one. sforce.one.getVersion() operates asynchronously, and your callback function is called when it finishes loading the requested version of sforce.one. Your callback function receives a single parameter, an sforce.one object for the specified API version. Use the object passed in instead of the global sforce.one to make calls to sforce.one that conform to the API version that your app requires.
Examples of Using a Specific Version of sforce.one
Defaulting to the Visualforce Page’s API Version
App functionality is created in a MyApp object, and then an event handling function calls the app function when that event, a button click, occurs. Separating application functionality from application event handling is a best practice, and it sets you up for using version-specific versions of sforce.one.
Using a Specific sforce.one API Version (Simple)
In the preceding example, the event-handling function is expanded from the first example to include the creation of a version-specific instance of sforce.one. If your app needs to mix multiple versions, you can create multiple MyApp instances with appropriate versions and names. More than one or two, though, are cumbersome to manage. We recommend the next approach instead.
Using a Specific sforce.one API Version (Best)
In this sample the app initialization is separated only by white space and comments, but you can separate it into functions for better encapsulation.
Using a Specific sforce.one API Version (Synchronous)
Although some situations require synchronous mode, the asynchronous version is preferred. If you forget to manually include the correct versions of the sforce.one library, your code will contain bugs that are difficult to diagnose.