Like many independent software vendors, the CircleBack team was eagerly anticipating the launch of the Salesforce1 platform. As a mobile app developer, Salesforce’s massive investment behind a mobile platform was perfectly aligned with our products. However, we faced a unique challenge—at least compared with other partners who were selected to develop integrations prior to Dreamforce ’13—we had a feature-rich, native iOS app that could not be re-architected into HTML5, allowing it to run inside the Salesforce1 environment. This post details three of the technical challenges we faced and how they were addressed.
ScanBizCards is a mobile application for—you guessed it—scanning business cards with your mobile phone.We’ve had Salesforce integration for a while now, allowing a user to export a scanned card as a Contact or Lead into their Salesforce org directly from the app. They do this using the Salesforce API. When we heard about Salesforce1, the use case seemed obvious: A Salesforce1 user would import a new Contact or Lead into Salesforce1, and thus into their Salesforce org, by way of our mobile app.
We had already developed what we call the “side-by-side” integration model for our app. The model allowed it to be invoked by—and then return scanned card data to—other native apps or mobile websites. This was accomplished using iOS’s custom URL protocols.
In our case, an external app or website could invoke ScanBizCards using the scanbizcards:// protocol (with various parameters to control app behavior and tell the app where to send the contact data after the scan was complete). Our integration point within Salesforce1 was to create a Global Action which manifested as a tile called “Scan Business Card” in the actions menu. The tile opens when a user touches the big plus (+) button in the bottom right corner of the Salesforce1 home screen.
Challenge #1: Invoking ScanBizCards
Challenge #2: Detection of Native App
A related challenge that presented itself was how to deal with the scenario of the ScanBizCards app not being installed on the user’s device at the time when we attempt to redirect the user from Salesforce1. The ability to detect the presence of a native app on the user’s device from a mobile web page—which is the equivalent challenge of detecting it from Visualforce within Salesforce1—is a much lamented deficit in iOS throughout the developer community.
Challenge #3: Returning Control to Salesforce1 After the Scan
The last leg of the journey was for the ScanBizCards app to return the user to Salesforce1 after scanning the business card. Ordinarily in our “side-by-side” integrations, we pass the scanned contact data back to the calling app as a query string, appended to that app’s custom URL protocol. We expect the calling app to have expressly coded support for receiving contact data in this way. Salesforce1’s custom URL protocol (the vestigial chatter://) had no such support. To work around this, we perform the export of the scanned data within ScanBizCards using our usual Salesforce API calls. Then, we return the user to Salesforce1 by redirecting to chatter://. Since this brings the user back to the Salesforce1 home page (which shows their news feed), we also post an item to the user’s news feed with a link to the recently exported Lead or Contact. This shows the result of the user’s actions within ScanBizCards.
Despite a few sub-optimal bumps in the process—notably the inability to detect whether the user has the app installed or not—integrating Salesforce1 with a native mobile app is fairly easy. It can be a great way to align your native app with Salesforce1’s new, robust mobile platform.
Want to see how the ScanBizCards app turned out with SalesForce integration? You can download the iOS version in Apple’s iTunes Store. An updated Android version will be in the Google Play store soon!
Download ScanBizCards for iOS (Premium)