Coming back to work after the Christmas break is rarely easy, but thanks to a late December announcement from the Salesforce Mobile SDK team, there’s already been cause for excitement as we look ahead to the rest of 2017! That’s right, the Salesforce Mobile SDK 5 has now been released for iOS, Android, and Cordova.
The Salesforce Mobile SDK allows developers to create both native and hybrid apps, for iOS and Android, to mobilise their Salesforce organisation. At MobileCaddy, we enhance and leverage the Salesforce Mobile SDK to help you rapidly build business critical mobile applications, and also provide you with an environment to support and manage your apps and users with ease. For more insight into how this works, read our case study on how we helped Diesel achieve mobile app success.
What are the Major Changes?
iOS 10 and Xcode 8 support – Released back in September 2016, iOS 10 is Apple’s latest iOS version. With a reported adoption rate of 64% in November, keeping up with support of the latest OS version is very important
Android Nougat support – Android N (API level 25), was released back in August 2016 and is the latest version of the Android OS, bringing improved security and features
WKWebView replaces UIWebView –WKWebView was released in iOS 8 as a replacement for UIWebView, and brings with it more capable memory handling, reduced CPU load, and a whole lot more, all of which should add up to an improved user experience when using hybrid apps
New APIs that allow hybrid developers to create their own named databases
Cordova 4.3.0 and 6.1.0 support
Full App Transport Support (ATS) server compatibility – Apple requires that all network calls happen over HTTPS, a welcome boost to communication security
Dropped support for iOS 8 – As with many upgrades come dropped support for older versions. SDK 5 now supports iOS 9 at a minimum.
For the full set of release notes, and to download the Mobile SDK, take a look at the Salesforce Mobile SDK repo on Github for iOS, Android, or Cordova.
What do MobileCaddy Customers Need to Know?
Current MobileCaddy customers and users don’t need to do anything for the time being, your apps will still continue to work and function as you expect. But it’s a good idea if you’re a Salesforce mobile developer who utilises the Mobile SDK to check for any issues or broken functionality, by replacing your current SDK version with the new SDK 5, and also look at how you can leverage the new features and improvements that SDK 5 brings.
Keep an eye out on our main MobileCaddy Blog for our next post on the new Mobile SDK 5, or visit our developer documentation to get started with the MobileCaddy platform to build smarter and better Salesforce mobile applications.
Last night I attended the Ionic UK meetup at Makers Academy in Aldgate. Some of the lovely folk from Adobe were there too, to talk to us about some of the things that are going on with them and Cordova. They were on a European tour that encapsulates dotjs, DevRelCon (which I’m sad to have missed), and a couple of local meetups in various countries.
I showed my true pro-meetup colours by pulling out my own bottle opener, following a frantic few moments stood around the beer bucket. I might even make my next t-shirt carry the slogan “I brought my own bottle opener”.
What’s new in PhoneGap & Cordova – Simon MacDonald
As a member of the Cordova Committee at Apache, Simon kicked us off with a brief history of PhoneGap and Cordova, and included this iconic (not Ionic) quote from Brian LeRoux;
He went on to the core of his talk, which was on Adobe’s Creative SDK plugins. These are plugins that are able to hook into a users Adobe Creative Cloud account, using their SSO. Simon demoed their Image Editor plugin through the use of an Instagram style app where, following the capturing of a photo, the image was then edited and posted to his Creative Cloud account.
He also talked about Send to Desktop and the Asset Browser plugins, these too interact with a user’s Creative Cloud account, and will be becoming GA shortly.
As well as commenting on the incredibly popular Push plugin (latest version has iOS 10 and Android N support) and PhoneGap Dev, he also spoke on updates that are coming to Cordova itself. I’ve a feeling that a lot of these changes are really going to be received well by seasoned hybrid devs. There is a lot of alignment to the one of the de-facto methods of package management, npm (Node Package Manager). The changes include dropping the config.xml, in place of package.json, and also using the standard npm cache.
“PhoneGap is a Polyfill, and the ultimate purpose of PhoneGap is to cease to exist
– Brian LeRoux, 2012
As of this wasn’t enough, on the horizon with cordova 7 is the promise of better documentation. And this linked in nicely to a request from Simon for contributions. As with most of OSS maintainers/core contributors, the request came in the form of something like “contribute code, but not just code, also documentation…. and definitely good issue tickets”.
More links and info can be found in Simon’s slides, and here’s a vid of a very similar talk he’s previously given.
Embedding PhoneGap in native Android apps – Anis Kadri
Up next was Anis to show off how you can easily add hybrid tech into a native Android app. To start though, he talked us through some of the benefits of hybrid development itself, though in front of a room full of Ionic devs his job was pretty easy. He did, however, mention a stat that blew my mind… there are nearly 1800 cordova plugins available.
He then kicked off his demo, firing up Android Studio and creating a brand new native Android app project. The new PhoneGap plugin was then installed and initialised, which gave him all the Cordova assets that we’re familiar with (config.xml, www dir, etc). He then made use of these by modifying his main.js class to extend cordovaActivity. When he then ran this project up, it loaded what looked like a normal Cordova app – you know, the old “Device is ready” screen. Mind = blown.
There are almost 1800 public cordova plugins available
As cool as this was, Anis then showed us how plugins could be installed from Android Studio, and then also how a webview could be added to an existing native app, giving a result where single views in the app utilised hybrid tech, whilst others relied on native code.
It can easily be seen that with this functionality in your toolbelt you can start to move chunks of your native apps to hybrid, thus removing platform-specific code. It allows devs to think of hybrid as not being a compromise (not that we do), but as a weapon in their armoury, truly meaning the right tool can be used for each job.
There weren’t any takers for the usual Showcase section of the night (perhaps this could be included on the agenda so folk know to prepare?), so I took this opportunity to quiz Simon and Anis (and the other Apacherians that were in attendance) about their views on the future of hybrid apps when it comes to the desktop environment. Sani kindly allowed me to pull an architecture diagram up on the projector, to help clarify my thinking.
It was great news to hear that they had been talking about this internally within the Cordova team, and that they’d actually had chats with Electron folk at github. Simon did add that there were no promises on anything, but it was indeed his view that it would be great for devs to write code once and it be run on Android, iOS, Electron, and as PWAs. He was in general agreement with the architecture I’d shown, and the split of responsibilities between Cordova plugins and (something like) Ionic Native. He also said it was their view to continue to align Cordova plugins’ APIs to those having a relative web API.
Ionic Round up
To close off Sani gave us a run down of his talk at the recent Angular Up conf, and that involved a pretty cool looking demo app called Telavivo. The app supports offline working via Service Workers, though sadly the demo-Gods were not on his side… he must have been a bad Dev that day.
His talk, and specifically the offline working through the use of Service Workers, gave rise to healthy debate, and questions about what to do for offline working with iOS (as they don’t currently support Service Workers). It’s a tricky situation, but one that we’ve overcome for enterprise through the adoption of MORE(s) Design, which has enabled us to truly transform the mobile experience for Salesforce.com users.
The Makers Academy, Aldgate, is a venue that well suits a meetup of the size of Ionic UK, and thanks must go to the sponsor(s) for the food and drinks (though I’m not sure who they were – I’ll update as I find out).
Thanks of course also go to Sani and Ryan for organising once again.
As for the talks, it was really great to hear from Simon and Anis; their experience and drive shone through and it makes me very happy to have folk like them in the community.
This is the first in a series of posts on just one tranche of the future for hybrid apps; the one that sees them continue to expand their reach on to PCs and Macs as ‘Desktop Hybrid’ apps.
Desktop Hybrid Apps
Installability – As with mobile hybrid, apps can be installed on to the host OS, just like any other app
OS UI Integration – Desktop app icons, tray icons, native menus, etc.
Hardware APIs – Filesystem access, Bluetooth, cameras, etc.
On mobile devices, this container layer is supplied through technologies such as Adobe Phonegap. With the ever-increasing oomph of mobile hardware, and the rise in adoption of frameworks like Ionic, mobile hybrid apps are no longer seen as the poor cousins of native apps – with many having millions of users¹, and winning both consumer² and enterprise³ awards, including Most Innovative Mobile Solution, Salesforce Partner Awards 2016, won by the TOPS app built using MobileCaddy.
Despite its young age, there are already many popular apps written using Electron. Companies using Electron include Microsoft, GitHub (who developed Electron), Slack, and Automattic (WordPress.com).
Our own MobileCaddy desktop offering, for full offline-enabled, custom desktop apps for Salesforce, is currently in beta and is looking amazing. It appears the appetite for installable, offline-enabled desktop clients for Salesforce is strong; if you want to find out more, request an activation code using the form below.
Hybrid vs PWAs
Before sitting down to write this article, I was already debating with myself when one should choose to build a hybrid app, rather than build a Progressive Web App (PWA). As with the overall hybrid architecture, the similarities between mobile and desktop again come into play, but this time in reference to the pros and cons that arise when questioning which route to take.
With mobile, hybrid apps have access to a whole raft of native features through Cordova plugins, whereas PWAs are limited to those provided by WEB APIs. The functionality and features you get with PWAs are increasing though – you can have “add to home screen” support, push notifications, and plenty else aside.
The situation on the desktop is very similar. PWAs have the same kind of access, but hybrid apps still (for the time being at least) have greater reach into the native layer, and are treated more like first class citizens. Hybrid apps are able to, for example, make use of native menus, tray icons, and store data outside of web storage.
I’m positive, and excited, to believe that the list of restrictions upon Web Apps will only continue to shrink, but in the meantime, let’s crack on.
One Codebase to Rule Them All
It is now only right to start thinking that, as app developers, it should be possible to have more or less a single codebase that supplies hybrid apps across the mobile and desktop landscape. This is something that the folks at Ionic have written about before, along with their intent to embrace PWAs.
So we’re there right? Well nearly, but not quite. Let’s say that you’re writing an app using Ionic – and so it’s an Angular SPA – and the app wants to create and access a private, persistent SQLite database… well you can do this on mobile using plugins such as Cordova SQLite Storage, and on desktop using the Node SQLite3 node package. To achieve the same functionality on mobile and desktop, we’ll be installing multiple plugins (though both eventually installed through npm, under the covers), and we’ll need to inject/reference them differently; we’re now left having to split our project into two.
It can be seen that this difference in inclusion and access means that our codebase can’t be the same, or can it?
IonicNative to the Rescue
Here is where you’ll need to indulge me… what if IonicNative rocked up and said, “Hey, yeah we already love making life easier for devs, so ima gonna step up to the plate”. This is what I’m thinking;
Not only does IonicNative provide a wrapper to Cordova plugins for mobile, but it also has an awareness of the device it’s running on. And if it knows that it’s running inside an Electron environment, it makes an Electron IPC call instead of calling through to the Cordova plugin. And what if the Cordova plugin developers, as well as having branches of code for Android and iOS, also had a branch for Electron? This branch could support the IPC messages and interface to the native layer to fulfill the request from IonicNative.
With this architecture in place – or something similar – the application developer wouldn’t need to concern themselves with platform nuances, or managing multiple codebases. Their process could be something like;
ionic create MyIonicCode
ionic install ionic-native&&mySQLitePlugin
Write some code
Bask inthe glory…anddothisalot asyou’ve loads of spare time.
I recently managed to kidnap Alex Muramoto – Dev Advocate for Ionic – and chatted with him through some of the above in relation to bringing MobileCaddy apps to the desktop. I’m hugely grateful for the time he spared me (he was busy writing slides for the Ionic UK Meetup) and our conversation definitely helped me to flush through some of my thoughts.
I’d love to find some spare time to put together a proof-of-concept of this, perhaps using the SQLite example above. Perhaps I’d initially start with just implementing intelligence into IonicNative to make the Electron IPC if needed, and have my project package explicitly pull in either the Cordova plugin or Node package, depending on the build target.
I hope this post triggers some thoughts and discussion and perhaps leads to a more unified future for hybrid app, right across the device landscape.
For our part, at MobileCaddy, we know that the demand is there for driving towards a single codebase for Salesforce clients on both mobile and desktop, and we know that hybrid is the answer. As part of this we’ll be keen to share our ideas, and contribute to the great projects that help enable this.
Future posts in this ‘Desktop Hybrid’ series shall look further into the topics of Salesforce, Ionic, and further analysis into the differences between hybrid and PWAs.
One of our current projects covers creating a bespoke Salesforce mobile application for a large company in the tourism sector. One of their requirements was to have printing functionality from the app. Seeing as our MobileCaddy SDK provides a toolkit for building hybrid mobile applications for Salesforce we turned to the existing Cordova plugin ecosystem and came across the cordova-plugin-printer plugin. It is common place for the Salesforce consultancies that use our SDK to consume the Cordova plugins via the mightily handy ngCordova project, and luckily this printer plugin was already supported by the project.
Although this plugin, and the ngCordova interface, suited our needs (and worked well) part of the beauty of building hybrid apps is the ability to use common web development workflows, which include building and (doing a certain amount of) testing in the browser. To do this many of the plugins on ngCordova also include mock instances that either interact with standard browsers capabilities or simply stub the calls. In the case of the cordova-plugin-printer though, this mock did not exist.
This post covers the steps we used to create a mock for the plugin and then create a PR for ngCordova, with the hope our code can be included in a future release. Giving back (even if in a small way) to open source source communities is one of the things we really enjoy. Through this post I hope that others may feel inspired and able to do the same. Creating fixes, patches and features are just small parts of developing software; interacting with an OS project can sometimes feel a bit daunting, but hopefully this post will help.
Once we have our own clone of the project we need to create a branch to work on. In the case for the above (adding a mock for the printer plugin) I created a branch called feat/printerMock.
I also want to confirm that all unit tests for the project currently pass. If I did this after I started making my code changes it would be a bad idea as I wouldn’t know if I’d accidentally altered something. The ngCordova project comes with support for running karma unit tests via gulp. All tests can be run with the following command;
Running this initially gave me the following errors, it seems my project’s development environment isn’t quite ready yet
Uncaught ReferenceError:angular isnotdefined
Looking at the project’s directory I can see that we have a package.json and a bower.json, and so it seems I need to install some packages and dependencies. These can be installed with the following two commands.
From the output of these commands I can see that a whole host of things, including angular, has been installed into my project’s directory… so I run the gulp karma command again. This time all looks good; at the time of writing there were 269 unit tests, and all passed so I was happy to continue.
Adding the Printer Mock
The plugins’ code can be found in the src/plugins directory. And looking at the printer.js file I see a simple interface with just two functions exposed, isAvailable and print. These are the functions I want to create a mock for. First up I create a new file in the src/mocks directory called printer.js (to match the real one). My first skeleton file looks like this;
Next up I create a test spec for this new mock, this is a file called printer.spec.js that I put in the test/mocks directory. This test spec will contain a couple of basic tests to check my mock implementation.
The skeleton file for the test spec looks like this; it’s very basic, and at present doesn’t do anything much other than describe a test block and ready it for use in testing the ngCordovaMocks module.
Following the beforeEach block I now add another describe block that will contain my specific printer plugin tests. This itself contains another beforeEach that injects the cordovaPrinter factory seen in our skeleton mock above. Our spec now looks like this;
If we run gulp karma again now we can see that we still have the same number of tests running and passing… and we’re now ready to add to that.
But this failure is good right… we haven’t written our code yet.
Add our mock code
For our isAvailable call we know we need to return boolean and in our mock’s case this will always be true. To implement this we add the following into our mock’s return block, so that it looks like this;
// using $q to give us promise support
// always resolve true in our mock
// return our promise
If we run our gulp karma again to kick off the tests we should see that our new test is now passing. Grab yourself a glass of your favourite beverage to celebrate.
Using the same TDD(ish) approach we can then add the extra test and code for the print function. In fact a slightly better workflow here is to run gulp karma-watch. This will set a watch running on both our source and test specs and will re-run the unit tests when it spots a change to either.
The finished code for the mock and mock test spec are here
Creating the PR
Now that we’re happy with the mock and test code we are ready to create a PR. The ngCordova project actually requires that the project is built prior to submission. The following step performs the build steps that outputs the concatenated and minified versions of the distributable ngCordova modules, and we need to include these in our PR.
Once this is run we should see that we have, as well as our 2 new files, updated files within the dist directory exist. This can be seen by running a git status command.
Now commit the changes and push to your fork of the project on github. If you now view your new branch on github you should see a “compare and create pull request” button. Click this and (at present) select the dev-next branch as the target.
And that’s it, PR created. And in the ngCordova project’s case a travis job will automatically be kicked off causing the unit tests to be run, and we should see these all pass (including our 2 new ones).