Review: Salesforce has the right stuff for mobile development

Salesforce.com started as a cloud service for sales force automation. The company added a cloud-based development platform, Force.com, with a Java-like language (APEX), and went on to acquire the Heroku PaaS and a number of other services.

Today, Salesforce.com is the acknowledged 800-pound gorilla of SaaS for a number of business application areas: not only sales force automation, but also marketing, customer service, community building, business intelligence, B2B prospecting, and collaboration. Over the last few years, Salesforce has been building out its mobile strategy.

[ Also reviewed on InfoWorld: Alpha Anywhere aces offline mobile apps | MBaaS shoot-out: 5 clouds for building mobile apps | Keep up with hot topics in app dev with InfoWorld's Application Development newsletter ]

As we’ll see, the Salesforce1 toolkit includes a Web-based drag-and-drop designer that even a Neanderthal – make that a business analyst – can use. (I’m now in trouble with both Neanderthals and business analysts.) At the next level of complexity, a Web developer who knows some HTML5, CSS3, and JavaScript can build pages for Salesforce1 in Visual Force with Mobile Packs or using Lightning components. At the highest level of complexity, a mobile developer can build native or hybrid applications against Salesforce data for iOS and Android with the Salesforce Mobile SDKs. Meanwhile, any of these can utilize the MBaaSes provided by the Salesforce1 Platform.

Salesforce1 mobile apps

Salesforce1, the newest option for development of Salesforce mobile apps, seems to be aimed at business analysts and others who aren’t comfortable writing JavaScript, HTML5, and CSS3, much less Java or Objective-C. Without any work, Salesforce1 can create a mobile view of your Salesforce site; with some effort, a relatively low-skilled developer can turn that into a usable mobile Web app.

Salesforce currently provides free Salesforce1 native mobile shell apps for iOS and Android, which users can download from the appropriate store and use for viewing Salesforce1 Web content. These hybrid apps provide advantages over Web apps, such as retaining state after a context switch and supporting secure offline read access once the data has been loaded. A Salesforce1 Windows Phone app has been announced, albeit without a scheduled release date.

Salesforce1 has a simple Web-based drag-and-drop designer that lets the developer customize the app, control security and access, and streamline working with records from mobile. Figure 1 shows the setup screen, which exposes a quick-start wizard; customization of the navigation menu and branding; custom coding of Visualforce (aka Salesforce's Web server) pages, flexible pages, and canvas apps; setup of mobile browser and notification options and offline sync; and configuration of compact layouts, mobile cards, actions, and page layouts. These same options can be found in the designer menus.

Figure 2 shows the result of configuring a global action to create a new detailed account record with a predefined field value, which simplifies filling the form for the mobile user. The action can be added to the icon bar layout for mobile users. You can create record-specific actions and global actions.

Figure 3 is a mobile device preview of a customer record with a customized compact layout. The compact layout appears at the top of the screen, above the action icons, allowing the user to see the most commonly accessed fields without scrolling down.

While using the Salesforce1 designer seems simple, it provides a lot of value. When you use it, you provision a custom schema in a cloud database as a service, with strong security, role-based permissions, and automatically exposed REST API endpoints. You get a mobile app that can access anything in it. Should you need to connect to Salesforce via XML Web services, Salesforce can generate the appropriate WSDL for your custom schema.

Stepping it up a notch

At the same time, anything you do declaratively with the Salesforce1 designer can be used from Visualforce, which allows you to write JavaScript, HTML5, and CSS3 pages to be served by Salesforce with the JavaScript and CSS frameworks of your choice: AngularJS, Backbone.js, Polymer, Bootstrap, and so on. Some of these frameworks are supported by the 11 Salesforce Mobile Packs, which are helpful, but not essential.

The Salesforce1 app itself was built using the new (beta) Lightning components, not Visualforce pages. Like Polymer, Lightning supports Web Components. By comparison, Visualforce pages use the legacy Salesforce MVC model. For added confusion, Salesforce supports Visualforce components, which allow you to encapsulate and reuse common design patterns in Visualforce pages.

Many otherwise competent developers couldn’t create an attractive-looking Web or mobile page by themselves even if their lives depended on it. Salesforce Mobile Design Templates (Figure 4) enable developers without design skills to create decent-looking mobile app pages.

Some companies need the ultimate in mobile app customization, and some developers are capable of doing that kind of work. Salesforce has Mobile SDKs for iOS and Android, both native and hybrid (PhoneGap). The SDKs use OAuth 2.0 to communicate with the Salesforce back end and support secure encrypted offline local storage.

Unfortunately, building apps from scratch, even with SDKs, often involves reinventing the wheel, the axle, the differential gear, and the motor. To reduce the necessity for reinvention of mobile layouts, Salesforce publishes a Mobile Gallery that currently includes 24 samples with as many as five target implementations for each. Should you happen to need an iOS or Android mapping app for Salesforce data or an activity-logging app for iOS, Android, or Hybrid, you’ll find the source code for a good starting point in the gallery.

Business logic and back-end services

As Salesforce has mobile development methods for all levels of developer, it also has back-end development methods for all levels of developer. For novices and business analysts, the obvious choice is point-and-click declarative Force.com logic. For developers familiar with Java, Apex code will be relatively easy to learn. For those who know the SQL SELECT statement, SOQL (Salesforce Object Query Language) will prove to be an easy way to query Salesforce objects. For full-text searches (think Lucene and Solr), SOSL (Salesforce Object Search Language) allows you to search Salesforce text, email, and phone fields for multiple objects simultaneously.

For even more flexibility, you can connect Salesforce to Heroku and do server programming in languages such as Ruby, Java, JavaScript/Node.js, and PHP, or use a Postgres database. Alas, the Heroku connector for Salesforce is custom-quoted. Operators are standing by to sell you software at 800-NO-SOFTWARE.

Much of the work involved in creating a Salesforce application for a company, whether Web, mobile, or both, involves data modeling. You use standard and custom Salesforce objects to map to the objects used in the business. The modeling is a drag-and-drop exercise, like almost everything in Salesforce. Once the objects exist, they are automatically exposed as API end points, and you can generate layouts and reports for them, as well as program against them.

There is a workbench that Salesforce developers use for testing APIs and obtaining the URIs of REST endpoints. I have seen it demonstrated briefly, but haven’t worked with it myself.

Salesforce Identity provides access management, single sign-on, and Active Directory support for Web and mobile applications. Salesforce Chatter supports business group instant messaging within the Salesforce platform and Salesforce1 app. The Salesforce1 Platform supports push notifications for native and hybrid apps, and provides a notification center for Web and mobile Web apps.

Geolocation and customer data

One back-end area that has grown in importance with the rise of mobile is geolocation. It’s easy to get the current location from a smartphone or tablet using HTML5. The Salesforce database has a geolocation field type (latitude and longitude) and obviously creates the proper geographic indexes for you. My understanding is that the Salesforce database is Oracle, with quite a few layers on top to make it scale better, more error-tolerant through redundancy, and easier to administer through services like automatic index tuning and automatic sharding. The SOQL query language can make geospatial queries, so it’s fairly easy to set up a Salesforce1 action for the likes of “show me a map of all the customers within five miles of my current location.”

While Salesforce has a good way of creating Web reports and dashboards, as well as provides an iPad app for viewing mobile dashboards, its promised Analytics API, which will “deliver real-time visual reports using any leading JavaScript libraries including High Charts and D3.js based on business reports created on the Salesforce Platform” is still not available. It sounds like it should be nice when it ships.

Salesforce has a way to keep enterprise data secure online and offline on mobile devices with its Mobile SDK SmartStore plug-in, which stores encrypted JSON documents on the device. This plug-in lets you perform local data operations for offline access and sync with the cloud when online. Salesforce recommends having your hybrid and native mobile apps use local data preferentially, pulling it down from the cloud when connected, and updating the cloud database from the local CRUD queue when connected.

External data access and sources

Since Salesforce conforms to OAuth2, you can use many other mobile systems to access Salesforce data, and you may want to do that if Salesforce is only one of the data sources needed in your mobile apps. However, it is possible to access alternative data sources, such as Microsoft SharePoint, SAP, Microsoft Dynamics, IBM WebSphere, or others that support OData 2.0 from Salesforce. For even more flexibility, you can connect from Salesforce to Heroku, as well as from Heroku to other data sources via the Postgres database or the Ruby, Python, Node.js, or PHP languages.

If you’re using a Mobile SDK or a Visualforce page, you can code your own REST calls to other services. As far as I can tell, however, Salesforce offers no special help in wrapping enterprise databases and applications with REST services.

Using the online drag-and-drop Salesforce IDE is simple, but can be tedious for an experienced developer. Fortunately, Salesforce offers many other options for people who would rather code. I rate the IDE 9 out of 10.

Salesforce supports pretty much all the mobile capabilities and mobile clients you’d want, so I’d rate those a 9 as well. Then again, using external databases and applications that don’t support OData 2.0 from Salesforce will likely require a Heroku connector license and some code. That’s going to require a higher level of expertise, as well as a more expensive license. I rate Integrations an 8.

If you already use Salesforce in your company, using Salesforce1 or one of the other mobile Salesforce options for no additional cost to expose your data to users on their devices is a no-brainer. On the other hand, if you don’t have Salesforce, the per-user pricing model is likely to make little financial sense compared to the alternative mobile app builders and MBaaS platforms we have discussed in other articles.