Data Access

Data access is one of the major design decisions involved in building a Force.com mobile Web application. There are a few different ways to use the Force.com REST API. This includes authenticating to Force.com and reading and writing its data.

There are two choices for authentication, described next:

OAuth—In OAuth, the developer creates a Connected Application in Force.com and uses it when creating the application. For the user who has not yet authenticated, he or she is directed to a special Salesforce login page. After login, the user is prompted to share his or her information with the application. If granted access, the user is redirected back to the mobile Web application, which now has an access token that grants it permission to access Force.com on the user’s behalf. Like a session with the Salesforce Web interface, the token eventually expires and must be refreshed by the application to obtain a valid one.

Session sharing—If the mobile Web application is hosted inside Force.com or an application already authenticated to Force.com, a session identifier can be embedded in the page. This can be used to make requests to Force.com without asking the user to log in again.

These two authentication methods can also be combined in a single application, granting more flexibility in how the application is hosted.

When it comes to accessing Force.com data, the decisions depend on how you build your application. For example, some data access methods are available only for a specific Web MVC framework. Others only work when hosted within Visualforce pages. A few of the most common methods follow:

SmartSync—SmartSync keeps your Web page’s data model in sync with the Force.com data. As you retrieve or make changes to a collection or model in your Web application, SmartSync makes the necessary calls to Force.com to mirror them persistently in the Force.com database. SmartSync is an extension of the Backbone framework, so your application must be using Backbone to leverage it.

JavaScript remoting—Available only to Visualforce pages, JavaScript remoting involves adding a RemoteAction annotation to a static controller method. This makes the method accessible to JavaScript without any of the overhead of the Visualforce view state. Keeping data access as lightweight as possible is critical for mobile applications, so JavaScript remoting is a best practice when building mobile applications in Visualforce.

actionFunction component—This method of data access is only available to Visualforce pages. Like JavaScript remoting, it makes a call from the browser’s JavaScript to the Visualforce controller. It requires less code than JavaScript remoting to call it, but performance is not as good due to its reliance on view state.

Force.com REST API—The forcetk.js library wraps the Force.com REST API so that it is easier to use from JavaScript. Because your Web page will be served from a server other than the REST API endpoint, accessing the endpoint violates same-origin security policy in modern Web browsers. This policy states that a script on a page cannot access a host other than the one serving the page itself. To address this, a proxy is provided by Salesforce, called the AJAX Proxy. For more information, refer to the online documentation at http://www.salesforce.com/us/developer/docs/ajax/Content/sforce_api_ajax_queryresultiterator.htm#ajax_proxy.