Note: This post is from Keir Bowden (aka Bob Buzzard), a Force.com MVP, Salesforce Certified Technical Architect and CTO of BrightGen, a Platinum Cloud Alliance partner in the United Kingdom. He has been solving business problems with the Force.com platform since 2008 and building hybrid and HTML5 mobile applications since late 2010. He is a regular blogger on Apex, Visualforce and Salesforce1 solutions at The Bob Buzzard Blog.
Accessing Salesforce Data Using Integration APIs
When building desktop Visualforce applications, data is created, updated and retrieved via the page controller. In the case of a standard controller, this works without writing a single line of code. As mentioned in the first post in this series, the application state is maintained by the Visualforce view state, which is not particularly well suited to mobile applications for the following reasons:
- View state is a large resource for the device to manage, especially as mobile devices have less memory than their desktop counterparts.
- The view state makes a full round trip to the server with each request, increasing the request size and consuming additional bandwidth which may lead to increased page load times.
Web Services API
Due to the additional overhead, I try to avoid using this mechanism for an HTML5 mobile application unless the functionality that I require is only available through the Web Services API.
Salesforce provides a standard REST API, but this is built around accessing a single type of sObject per API call. For mobile applications that operate against a hierarchy or complex graph of sObjects, this requires multiple API calls to retrieve and save data, which is something that should be avoided, as explained in the first post in this series. For this reason, custom REST APIs should be created using Apex REST, which can work against the entire set of sObjects managed by the application in a single call.
A downside to accessing Salesforce via the REST API is that there is a limit on the number of API calls that may be made per 24 hours. Using custom REST APIs reduces the amount of API calls considerably, but this may still prove to be a problem, especially if there are existing integrations implemented on the Salesforce instance which may already mean API calls are at a premium. The benefit to using this mechanism is that it loosens the coupling between the mobile application and Salesforce.
Due to the consumption of API calls, I rarely use this mechanism for a Visualforce HTML5 mobile application – even if API calls are not currently at a premium in the Salesforce organization, there is no guarantee that they won’t be at some point in time in the future, and as I am tied in to Visualforce as the application delivery mechanism, the loose coupling isn’t a great benefit.
Rendering Images for Mobile Applications
Images have long been a thorny problem when developing mobile applications, especially for applications that are intended to run on devices with different sized screens. In this situation the images need to be responsive and sized (or resized) appropriately for the device.
Long term, the solution is highly likely to be the proposed <picture> element. This allows a page author to specify multiple sources for an image based on media queries, and the browser will choose the most appropriate source based on the device capabilities. For example:
Note that there is a regular <img> element nested in the picture element, providing a fallback for legacy browsers that don’t support the new element.
Unfortunately, the element is currently a W3C working draft and at the time of writing (May 2014) no browsers provide support for this. This leaves us to choose between currently supported solutions. I’ve used each of the three solutions listed below, and have settled on Picturefill for truly mobile applications.
Download and Hide
In this solution, multiple versions of each image are maintained, each version suitable for display on a device with a particular screen size. Markup in the page is provided for the complete images, and CSS media queries are used to hide all but the images specific to the device.
This is probably the worst approach for a truly mobile application, as even though the majority of the images are hidden, they have still been downloaded from the server, increasing request size and duration, consuming mobile data and increasing the size of the resources that the device browser has to manage.
In the code snippet above, the large logo will be displayed when the screen size is greater than 1024 pixels, otherwise the medium size logo will be displayed. However, both images will be retrieved from the server regardless of the screen size.
Download and Shrink
This solution utilizes images that look good on the largest screen and resizes these for smaller devices via CSS media queries.
While this approach is more efficient than Download and Hide in terms of request size and data usage, it still has the potential to be extremely wasteful – reducing an image height and width by 50%, for example, means that 75% of the image is discarded. It also has the downside that simply resizing the image may make it illegible or lose the idea the image is trying to convey. For these reasons I only use this technique when building an HTML5 mobile application that will primarily be used with a high speed connection.
In the code snippet above, the logo will be rendered at its natural size of 300 x 68 pixels when the screen size is greater than 1024 pixels, otherwise it will be rendered at 150 x 34 pixels. However, in both cases the full sized image is downloaded.
For more information on CSS media queries and how these can be used to alter styling, see: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries
Scott Jehl’s Picturefill is a polyfill for the proposed <picture> element.
In spite of this, Picturefill is my preferred solution. Retrieving only images that are suitable to the device and that are already at the correct size reduces both the size of the server responses and the amount of processing that the device has to carry out on the response.
For a more detailed discussion on responsive images in general (as opposed to mobile specific considerations) visit:
Keep Functions Small
Content Delivery Networks
A Content Delivery Network (CDN) is a distributed network of servers in multiple locations, serving content to end users with high performance and high availability. When a user makes a request to a CDN hostname, DNS resolves to an optimized server based on location and availability, which handles the request.
When building Visualforce applications, there are two types of CDN to be considered:
External “Library” CDN
The key benefit to using one of these CDNs is the caching of regularly used content. Using JQuery as an example, most users will have many versions of JQuery stored in their browser cache, used by applications from different sites. As these have each been served from different sites the browser will disregard these when JQuery is referenced from a new site, as it cannot reliably determine that any of the cached versions matches that on the site. When JQuery is served from a CDN, the browser can detect that it already has a cached version of the file (as the site and filename matches the cached version) and serve it from cache rather than downloading it anew.
Another benefit, although less important with modern browsers, is parallel loading. Browsers limit the number of requests that can be made in parallel to a single hostname — as little as two requests for some older browsers. By splitting resources between one or more external CDNs and Salesforce, the number of parallel requests the page can support is increased.
Examples of this type of CDN are Google Hosted Libraries and Microsoft AJAX libraries. My experience of these CDNs is that Microsoft usually has the latest versions of libraries available first, so if you need the most up to date functionality you should start there.
If your application is served from an unauthenticated Force.com site, or an authenticated Force.com site but not over SSL, it can take advantage of the CDN provided by Salesforce. This caches entire pages, by default for 10 minutes, on a network of over 40,000 servers around the world.
For more information on Content Delivery Networks, visit:
About the Author
Keir Bowden (aka Bob Buzzard), is a Force.com MVP, Salesforce Certified Technical Architect and CTO of BrightGen, a Platinum Cloud Alliance partner in the United Kingdom. He has been solving business problems with the Force.com platform since 2008 and building hybrid and HTML5 mobile applications since late 2010. He is a regular blogger on Apex, Visualforce and Salesforce1 solutions at The Bob Buzzard Blog.
This post was published in conjunction with the Technical Enablement team of the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Salesforce Developers.