Design patterns have long been critical to developer productivity, rapid onboarding of new staff, and the creation of scalable, maintainable solutions. The Salesforce App Cloud and the mobile patterns described in this document have been assembled based on conversations with hundreds of developers and customer building successful mobile apps. Any developer, or organization building mobile apps on the Salesforce App Cloud will find this collection of patterns invaluable to delivering engaging apps connected to customer data.
A core feature to the Salesforce App Cloud is the ability for mobile services to leverage Connected Apps. Connected Apps are any application that connects to Salesforce Services using OAuth Authentication; most typically, but not limited to, mobile apps.
Developers, or administrators, can rapidly create a connected app endpoint, define API permissions, including whether pin-code protection must be enforced on the mobile device for the app. Connected Apps enable adminstrators to define organizational policies for mobile apps.
The patterns decided in this paper, rely on the Connected App configuration. Connected Apps can be created using the following steps. For more detailed discussions on Connected Apps please refer to the online guide.
Design patterns provide a repeatable, proven implementation practice. The following collaboration diagram provides a high level view of the key enterprise mobile patterns, and how they relate to each other, and the Salesforce App Cloud.
To facilitate learning, a complete reference application, Cloud Cable has been created. Cloud Cable includes an implementation of each of the patterns described below and can be downloaded from github.
Every database object within the Salesforce App Cloud is instantly enabled with REST services for CRUD (Create Read Update Delete) operations. This eliminates the need for developers to hand code, and maintain, mobile endpoints. However, there are times when developers need more coarse grained service calls such as those that batch requests into a single call to handle low bandwidth, require transactional support across multiple updates, or service calls that are required to work across multiple related database objects.
The Mobile Facade Pattern provides a facade wrapper atop database object level REST services, and exposes a single coarse grained REST endpoint for developers. Mobile app consumers are typically pre-authenticated to the the Salesforce Platform backend services, or the Mobile Facade is implemented in conjunction with the Anonymous Reader Pattern.
The following diagram depicts a typical implementation that uses the Mobile Facade Pattern to support transactions across a single business process.
The Mobile Facade Pattern is implemented as an Apex class using custom Apex REST endpoints. It is considered best practice to group related coarse grained custom endpoints into a single Apex class. This approach encapsulates common functions and promotes re-use across endpoints by leveraging helper methods. The following article, provides a detailed description on how to implement a mobile facade:
Mobile Facades are an extremely efficient way of working with backend customer data and leveraging the Salesforce App Cloud's ability to dynamically generate JSON responses based on database objects. By default, REST endpoints require OAuth authentication for consumer to access customer data. The Mobile Facade pattern can leverage the consumer key generated via the Connected App services to retrieve the required OAuth token.
The are many times, in particular for consumer mobile apps, where data is required for anonymous users. The most typical example may be a storefront, or non-confidential information. Developers can expose REST endpoints for anonymous (public) access via the Anonymous API Pattern whilst still controlling data visibility based the roles and profile features of the Salesforce App Cloud.
The Anonymous API Pattern relies on Force.com Sites, and an Apex class, or database object, to expose as an anonymous REST endpoint. For our example, we will create a simple TODO database object and expose that.
This is an example where the mobile services leverage existing features of the Salesforce App Cloud to enforce database object level access.
The Anonymous API pattern exposes a RESTful endpoint using the following format that can be used by mobile developers to anonymously access information based on either a custom object, is using the Mobile Facade pattern, multiple objects (note: if using the Mobile Facade pattern, developers must enable database object permissions for each object used within the facade). The use of how many API calls can be made via this pattern is governed by the number of Force.com Site calls the user has licensed.
The specific URL is unique using the following values, and based on the mobile service annotations in your custom apex class (step #5), may be accessed using HTTP methods (GET, POST, PATCH, DELETE) with tools including Apigee or Hurl.
MysiteName = the name of the Force.com site you created in step #6 PodName = the managed platform ‘cluster’ your mobile services are available on. You can get this number by looking at the URL of your browser whenever you are logged into the Salesforce App Cloud backend. urlMapping = the URL mapping you specified when creating your custom Apex class in step #5
The Salesforce Platform provides the ability to create a customer facing portal. Mobile app developers can leverage this capability to enable services including Social Sign On and self-registration. Many of the typical portal features such as branding are not required for the Customer Portal Facade Pattern, and can be skipped or left with default value. The key for mobile developers is the portalid and orgid that is generated when creating a customer portal.
Then, associate the API Portal User profile to the Portal. Note: The API portal user is the profile we assign to new users that get created via our registration handler
The Customer Portal Facade is a foundational pattern of the Salesforce Platform Mobile Services. By creating a Portal facade, developers now have access to a portal id which they can use to authenticate, and provide self-registration to users via mobile APIs using the Auth Handler Pattern.
Secure authentication to enterprise mobile apps is a critical aspect to user adoption, and the ultimate success of mobile apps. Developers can leverage the Auth Provider capability of the Salesforce App Cloud to provide authentication via Facebook, Salesforce Identity, or Janrain for other social networks. Creating an Auth Provider gives the developer the option to include a custom Registration Handler.
The Registration Handler Pattern is implemented as an Apex class. Developers can add custom logic to be performed as part of the authentication process. In particular, Registration Handlers are most frequently used for the creation of a User record, assigning appropriate roles and permissions, and creating related records for reporting mobile app usage.
The following implementation of the Registration Handler Pattern creates an Registration Handler with custom logic to create an Account (the mobile app) and Contact record for reporting on mobile app usage, as well as creating a User record with API Portal User access (typical for most mobile implementations).
This pattern demonstrates a typical archetype of successful enterprise mobile apps - leveraging the native features of the Salesforce platform in conjunction with App Cloud mobile services - Specifically, using the Account object to identify a mobile app for reporting and workflow purposes.
The Registration Handler Pattern, upon successful implementation (successful save of the Auth Provider, and implementation of a Registration Handler), developers will be provided a single sign on URL. This URL, along with the connected app model of the Salesforce App Cloud enable the foundation for building secure mobile applications connecting to customer data.
Organizations who implement the registration handler pattern can then engage internal or external development resources to build mobile apps with the ability to leverage a standards-based approach to authentication for all mobile apps.
Many organizations become focused on whether they should be web, hybrid, or native mobile applications. There are certainly pros and cons to each approach which must be considered, however, too often, businesses become focused on a verses approach to mobile app development rather than a broader organizational approach. The mobile platform pattern shifts the development of a mobile strategy from end-devices and apps to one that leverages a cloud-first approach to promote re-use across the entire company.
Unlike the other patterns presented here, the Mobile Platform pattern is best described as a series of strategies for each type of mobile app: web, hybrid, and native, and how they can be developed using an enterprise mobile platform such as the Salesforce Platform.
Organizations looking at 100% web applications should consider building single process applications - apps that perform one business process well, eg: work with tasks, create/view/edit appointments etc. This process avoids some of the potential downsides, such as memory management of large data sets within the browser cache, of pure web applications, but allows the rapid creation of mobile apps that support any platform/device without the need for highly specialized mobile app developers.
Hybrid applications, in particular those that leverage the Salesforce App Cloud's mobile SDK for secure authentication and access to local device functionality to achieve core business requirements like secure offline storage and pin-code protection, are a highly effective strategy to bridge existing developer skills with the needs of native device support.
Organizations looking at hybrid applications should consider building line of business focused portals that aggregate many 100% web applications into a complete business solution. This hybrid portal approach allows an ‘economy of scale’ for development by centralizing core functions such as authentication, and app distribution. Developers and and IT departments can build common services on the platform to work with corporate data and make these services available to any app (see mobile facade), without the risk of slowing the agility of lines of business building 100% web apps. Further, with access to local device functionality, organizations can deliver additional benefits by integrating cloud-based services into local device services. eg: integration with local contacts, and calendar, and make these available via the mobile platform and other apps.
Native applications provide a rich, optimized experience for mobile applications. The mobile SDK for iOS and Android empower developers to build native apps to leverage the Salesforce platform, but do require specialized skills, and separate code bases to support multiple devices.
Organizations looking at native applications should consider delegating the majority of business logic to the mobile platform. This approach greatly reduces the complexity on the native device, and mitigates the need to the duplication logic on different devices. eg: a company supporting both Android and iOS may need to support bank account transfer functions. Developing this functionality in Objective-C (for iOS) and in Java (for Android) is not a scalable solution for even the largest organizations. Delegating this logic to the mobile platform leverages existing skills, and makes the development of common services a core aspect of the organization’s mobile strategy.
Many organizations get focused on whether to build web, hybrid, or native mobile apps. The Mobile Platform pattern takes a cloud-first approach to mobile app development that allows organizations to focus on business agility, and existing skills, resources, and experience. Organizations looking to implement the mobile platform pattern can start small with a line of business 100% web mobile app, and grow this over time to meet the broader mobile demands of the business.
The Salesforce App Cloud provides the most complete set of services for building enterprise mobile applications connected directly to customer data. The enterprise mobile patterns detailed within this paper provide the fundamental implementation patterns used by hundreds of successful customers. Developers looking to master the Salesforce App Cloud mobile services must become familiar with these patterns, and how they can leverage the rest of the Salesforce App Cloud to deliver game changing mobile apps for their customers, employees, and partners.
|Quinton Wall is a Director of Tech Marketing at Salesforce.com , and aspiring fantasy author. He is a regular speaker at cloud and developer events around world, active contributor to open source projects, and the developer.force.com site. When he is not working with the Force.com platform, building mobile apps, or writing books, he can be found on twitter @quintonwall sharing his thoughts 140 characters at a time.|