Exploring Salesforce Mobile SDK 3.1 release

My journey with “Salesforce Mobile SDK” started in 2013 with native part of SDK i.e. iOS app called WorkInbox.

My Javascript love started bubbling up in 2014, I was doing lot of stuff AngularJS etc. Later half of 2014 was committed to Salesforce 1 app called MeYouThere (thanks to SummerOfHacks), which is a S1 first mobile app, thus not using Salesforce Mobile SDK.

Near end of year 2014 luckily stumbled on a complex hybrid app again using Angular, Ionic etc powered by hybrid tooling of SDK. This app is for field persons servicing machines, and logging reports with rich text fields, signatures and pictures using tablets.

I was very excited to see 3.0 update few weeks back, and now 3.1 update is out as well, its very pleasing to see frequent and mature updates coming to Mobile SDK.

In this post I will try to cover what I learned in this journey, and what latest Mobile SDK 3.1 has to offer.

CocoaPods

Those who are not from Cocoa(Objective-C) background must be wondering its a cool gadget etc, which is added to Salesforce SDK 🙂 Its actually cool like gadget, but a niche way to manage dependencies in Cocoa based projects. If you are still wondering why its so complicated and important, you should need to spend sometime configuring and building a project without pods in Xcode.

I still remember my 2013 days, and the struggle to setup Salesforce Mobile SDK correctly with all dependencies in XCode. I missed these pods a lot during that time.

Learn more about CocoaPods from:

• This post in Salesforce blog.

• SDK Docs 

New Code Samples and Canonical Apps

If you are like me, you like to learn more by reading code quickly and trying it out.  Since v3.0 of SDK, a few  app is called SmartSyncExplorer, which lets you explore Smart Sync features, and its available for native Android and iOS implementations. 

Apart from that Visualforce, Hosted App and Hybrid App developers can also benefit from newly introduced “Mobile UI Elements (Beta)“. They are based on Google’s Polymer framework, and surely an interesting take to mobile development at component level. Following screenshot gives a quick glimpse of some of the components, for more details please refer – mobile developer guide and explore source code on github repo, plus this post in salesforce blog is a good read.

A list of few polymer based components
in Mobile SDK

Bower.json indicating dependencies which is mainly Polymer and other popular libs like jQuery, underscore and Backbone.

Sample Mobile UI Elements Code.

Unified Cross Platform App Architecture 

Since v3.0 SDK is maturing towards a unified app architecture.  Here is how Salesforce team explains it:

we’ve unified the app architecture so that apps built with the latest SDK – hybrid or native – now have access to the same core set of functionality regardless of their target platform. All the libraries, all the APIs, and all the major mobile building blocks have consistent implementations, while at the same time, provide full access to the host operating system.

Following image makes it more clear and based on above reading you can relate to it as well. 

Unified SmartSync API for native and hybrid apps

Based on same Unified Architecture concept discussed about SmartSync is moving towards a consistent implementation across various supported native and hybrid platforms. 

SmartSync existed for a quite a while, so no point in discussing it a lot in this post. What’s new in recent update is “bulk sync” via “SmartSync plugin” for both native and hybrid apps as well, its available since v3.0 of SDK. Its good not only for native, but very important for hybrid apps, as sync is using native threads for heavy syncing operations, so keeps WebView’s performant. Here are key extracts for those who are working hybrid apps, and want to use 

Adding SmartSync plugin to Hybrid Apps.

Smart Sync plugin is not same as “smartsync.js” which existed in hybrid apps for quite a while, so its important to check following section in docs for using it correctly:

SmartSync Plugin Methods and Setup with Soups

Other SDK updates

Not much related to what I am working on right now, but these are other updates in SDK for your reference:

• Gradle for Native Android Apps: Android Studio and the Gradle build system are now fully supported for native apps.  Gradle support for hybrid apps will arrive after the next Cordova update.

• Certificate Based Authentication Pilot: Leverage certificates as part of an enhanced authentication flow without asking your users to enter a username and password.

• Minimum versions raised on iOS to 7 and Android to v4.2.2 (API 17), supporting libraries upgraded to the latest versions.

Upgrading your existing hybrid apps to 3.1

Mobile Developer guide offers a clean section to make this easier, please check it here. In my case migration from 3.0 > 3.1 didn’t worked out, as instructed here in the mobile guide. Following are steps I followed to migrate successfully. 

$ cd [your_cordova_app_folder]
$ cordova plugin rm com.salesforce
$ cordova plugin add https://github.com/forcedotcom/SalesforceMobileSDK-CordovaPlugin
$ node plugins/com.salesforce/tools/postinstall-android.js 19 false
$ cordova prepare

Following additional command made the app build and run again on device:

node plugins/com.salesforce/tools/postinstall-android.js 19 false

Troubleshooting Salesforce Mobile Development

Apart from Salesforce Stackexchange, if you are not already part of this Google Plus Community, please join it. This G+ community is backed by key developers in Salesforce Mobile SDK team, so getting quick and correct resolution is easier.

Expectations from Salesforce Mobile SDK 

Its always very easy for others to expect, and very tough to deliver 😉

So I understand, its tough to match the pace of innovation and deliver something which pleases all. But here are few asks, which could improve productivity and experience of Salesforce Mobile Developers:

1. Stale information: Unfortunately Google is still developer’s best friend to start looking for information, they try to find based on keywords like “Salesforce Mobile Hybrid Windows” etc. Problem is SDK evolved a lot, and many processes and configuration steps are changed. I saw a few times, developers picking a old blog post or wiki page, and using it as a reference. Suggestions:

   • Salesforce Team: Please pull down or update old blogs on DeveloperForce and wiki pages with stale information. 

   • Developers: Please never download a PDF or use a Google search to research about Salesforce Mobile SDK, your best friend is HTML Mobile SDK Guide, which could be find online here. You can always check its pointing to latest release and API version, as indicated in screenshot below.

2. More smoother installation, upgrade and CLI: I know you guys are working on it, and CocoaPods is good example of the same. I still feel that setting up Mobile SDK hybrid on both Mac / Window’s machine was a time consuming affair. Why it can’t be as simple as installing just the NPM based forcedroid/forceios, as of now its a long process and its easy to go wrong and end up in a black hole. Same applies for upgrades between previous and newer SDK versions. I pretty much like the way IONIC CLI works, its pretty simple to get any updates via NPM only, and  updating IONIC in existing project is one line command i.e. “ionic lib update“

3. Multi org/user support: In 2013 when I was using iOS SDK, we had a requirement to support multiple Salesforce logins/users/orgs in same mobile app, and it required us changing quite many classes in iOS codebase. I think multi user/org support should be default behaviour. I am not sure if its already done now, if anyone is aware please comment back on the post.