As Sandeep just recently noted, the Mobile SDK has been updated just in time for Cloudstock with great new features like offline support for hybrid applications.  Mr. Bhanot goes into great detail on the offline component, but that’s not all that has been included in the 1.1 version of the SDK for mobile developers.

Flexible OAuth

By popular demand, the SDK also now gives the ability for hybrid applications to have more direct control over the authentication flow.  Previously, the OAuth process would be initiated whenever the application was first loaded, but now you can update specific variables in bootconfig.js to decide whether or not that should be automatic.  You can configure the behavior of how your application starts with either the RemoteAppStartData object (for applications leveraging remote assets like Visualforce) or LocalAppStartData (for applications leveraging local HTML5 applications).

The two configuration methods work like this:

So, for instance:

This would define startData as a remote application which should go to “/apex/BasicVFPage” after login, and it knows that’s not an absolute URL (it will go to the domain/pod based on the user’s login). However, the application also knows not to initiate that flow right away — it will let the developer fire the login JavaScript to accomplish that.  Check out the “onDeviceReady” function in index.html to see how to best control the events surrounding user login.

Native iOS Blocks

Blocks are a code pattern, introduced a while back with iOS4, that allows you to create native iOS applications  with better control over how asynchronous events are handled.  The standard REST API code handles responses by leveraging specific methods defined by the SDK’s interface.  Blocks allow the developer to define how to respond to the REST callout when they define the callout itself. So while calling a request like this:

Would call the standard method of:

If you switch to the SFRest+Blocks version of the code, you could specify this when I create the request:

But instead of “didLoadResponse”, you could refer to a method specific to handling my describe callout.  Without blocks, if you do multiple types of callouts (like a SOQL call and a describe call), ytou would need to loop handling both kinds of logic within one method, instead of allowing different methods specialize in handling the data being returned.

To use blocks with the Mobile SDK within your project, make sure the SFRestAPI+Blocks header and main file are included in your project and import the SFRestAPI+Blocks header instead of the default SFRestAPI header.

See It at Cloudstock

The Mobile SDK continues to evolve, as 1.1 and these great features indicate.  If you want to get your hands on it with Force.com developers on hand, come on down to the DevZone at Cloudstock and see it for yourself.  As usual, if you’ve got other questions you can catch me on twitter @joshbirk or add them to the comment section below.