I've worked with mobile projects off and on over the years, and now that we've got the REST API generally available, it's a great time to be building mobile applications with the Force.com platform.  Here's a few tips to avoid common gotchya's that you may not run into when building more traditional web applications.

Test on hardware early and often

It's like voting in Chicago, people.  I know that small and large shops alike may not subscribe to a free iPad Monday policy (we certainly don't) – but one lesson I have learned repeatedly doing mobile Development is that emulators simply don't give you the whole story.  It's great for prototyping, demos and proof of concept work but the device is going to be ruuning with different drivers, the real software frameworks and actual hardware.  Case in point, I did a very early iPhone integration with the SOAP API that worked great … until I realized the XML library I used wasn't actually supported on the device.

 

Forcing the response to be JSON (or XML)

Technically, if you want JSON as your reponse format you should be fine right out of the box as its our default response format for the REST API as it is our default.  However since some mobile platforms often have you roll your own HTTP requests from scratch and hence you might run into some situations where you need to be specific.  In my case, I was getting a different response format from the device than I was from the emulator (see above).

To get the specific response you want, use the Accept HTTP header in your request.  Depending on your language, this may vary obviously, but one example:

    headers["Accept"] = "application/jsonrequest";

 

Specifiy format of your POST body

The converse of the above may occur when you get into the create and update REST operations.  While different frameworks have different methods of defining the cotents for a POST request,you may need to specifythe Content Type of your request.  Specifically for JSON requests, use: 

    http.contentType = "application/json; charset=UTF-8";

And for XML or SOAP requests:

    http.contentType = "text/xml; charset=UTF-8";

 

Wait, where's my PATCH?

The update method for our REST API uses the PATCH HTTP method.  However, some mobile and RIA platforms rely on browsers or related technlogies which may only for suppprt, say GET and POST. Thankfully, we've got your back. We've added the ability to use POST as you normally would, and then tell our API that you really mean a PATCH request.  Simply form the URL as you normally would, and then add:

    ?_HttpMethod=PATCH

So a full update might look like:

    https://na8.salesforce.com/services/data/v21.0/sobjects/Account/ACCOUNTID?_HttpMethod=PATCH

And then you could send your updated fields in the POST body as JSON.

 

Clearing cache from authentication requests

This is probably not a common problem, however when working with Flex Mobile I noticed that my authentication POST requests would occasionally be met with internal server errors.  While the root cause is somewhat elusive, I found that everything became stable again if I made sure that my requests would enforce no caching via HTTP headers.  It's fairly simple to do – just include the Cache-Control header in your request:

    headers["Cache-Control"] = "no-cache, no-store, must-revalidate";

 

Hope that helps, mobile people.  I'll be showing Flex Mobile using Force.com and Chatter at the upcoming 360|Flex Conference, specifically the "Mobile Enterprise Social Networking" session on Wednesday.  Hope to see you there!

 

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS