Every project has time constraints, which sometimes means that nice features have to be dropped. This is why we’ve decided to make public our first set of App Extensions. These packages can be included in projects with a single command, freeing up your development time and enhancing your apps without limiting scope.
During our last couple of product updates I (excitedly) rabbited on about the development and GA release of our first three MobileCaddy App Extensions. The thinking behind releasing a suite of growing extension packages for our partners stemmed from some internal work that Diana, our latest developer intern, had undertaken.
Diana – a recent MSc graduate from the University of Kent – was tasked with updating one of our internal Salesforce mobile apps. During the scoping phase, we realised a lot of the new features would have also been an amazing fit in many of the apps our partners have built for their customers. Thus, the MobileCaddy App Extensions were born!
The first three extensions to go GA are:
An Angular service that acts as a wrapper to standard and custom Salesforce REST endpoints. The extension takes care of the authentication to Salesforce and includes calls for basic queries, SOQL calls, and file functionality.
Here’s an example to access a Salesforce Chatter feed:
This package contains an Angular service and controller, and an Ionic template that can be used to add a global search function to your app. It can be configured to handle queries across multiple mobilised tables and defined fields, and supports fuzzy search.
The extension also supports maintaining a configurable number of recent search items that were viewed.
An Angular service giving a lightweight implementation of calls to add, remove, and retrieve Salesforce objects from a local recent items listing.
Recent items are can be retrieved for a particular object, or for all entries.
// Get recent ‘Account’ object records.
Tell me More
Our App Extensions are served as stand-alone packages and can be installed directly through npm. Each App Extension contains its own unit tests and is hooked up to TravisCI. When installed, they’ll copy their relevant code, and tests, into your project structure and will be included in your git repo by default. Being npm packages, they too can be easily upgraded when updates are made available.
Our library of extensions will expand as we identify more common feature sets, and we’ll be sure to open source them all. With that in mind, please feel free to raise PRs or issue tickets against them. And please let us know us on Twitter, or your private partner Slack channel (available to all our partners), if you have an idea for a new extension.
The aim of our extensions is a pure continuation of our belief that developers shouldn’t be re-inventing the wheel and having to re-write code that’s already proven. They’re also there to make sure rich features can be added to applications in scenarios where they’d normally be descoped due to project constraints.
The MobileCaddy App Extensions enable you to pull in common application functions and features with a single command. And with MobileCaddy actively maintaining the extensions, and the single-command update process, your apps stay up-to-date with limited effort. Check out our currently released Extensions at the links below, and start enriching your apps today.
You know that thing, when inspiration hits, and you just want to build something cool? Well that happened to me whilst attending a recent London Salesforce developer group. And the output… Clicks not Passwords; a truly cross-platform App Tray utility for logging on to Salesforce organisations.
But let’s rewind. Before the DUG agenda was even set, I was already excited about the possibilities and potential of Salesforce DX. I’d seen online talks and read blog posts about Salesforce’s new set of tools and principles, shifting to a more modern, standard approach to development practices. These include aligning to a Source Code is the Truth mentality, as well as the release of supporting tools to aid this. Additionally, following the GA of desktop support for MobileCaddy, it’ll be no surprise that I’m also a big fan of Electron (and web tech in general).
Lightning struck (see what I did there? ) during the meetup, whilst Wade Wegner was giving his excellent demo and talk on Salesforce DX, and in particular how it’s CLI includes the capability to create aliases for your orgs (dev, sandbox, scratch, and production). Included in this alias-management is the secure storage of authentication information, that is then available to the CLI, enabling simple commands to launch browser tabs to specific orgs without the need to enter usernames or passwords. Brilliant, right? But what if you’re not comfortable with the command line? The answer… Clicks not Passwords. Whilst potentially not an issue for some folk within the Salesforce ecosystem, there will certainly be some admins and devs that will certainly benefit from this; I have personally seen at least a couple of our partners, who were building tablet apps for Salesforce, having to juggle and manage many dev orgs and multiple scratch orgs for single projects.
Anywhoo… that night, after returning from the DUG, I poured myself a dram of Tincup whisky and coded away for less than hour. That’s not a long time at all, but building on top of Open Source projects like NodeJS and Electron, and the SFDX CLI, I was able to run up an app on my developer machine that enabled me to list my current SFDX aliased orgs, and then click on each to open them… all without needing to remember usernames or passwords. And the beauty of using web technologies and the SFDX CLI meant that not only could I run this on my Ubuntu Linux laptop, but I could also run it on my Windows desktop, and my Mac… all from a single code base. This stack is similar to that used in creating our offline-supporting desktop Salesforce apps, so I had some experience with it already.
The project can be found at this open repo, and PRs are most certainly welcome (thanks to Mick Wheeler and Frank Hart who have already contributed).
The roadmap for the project includes linking to pre-built distributables for leading OSs, along with further org management (addition, hiding, ordering, etc), and I’m sure this will grow as the SFDX CLI and other tools advance.
Work is continuing on the updates of the MobileCaddy starter apps. Additional work has also been undertaken on the CLI during this period to allow for validation of the behaviour of the starter apps.
The timeline is unchanged.
Update 22nd March 2018
Timeline is unchanged. Focus has switched to rewriting the MobileCaddy starter apps with the emphasis on adopting the best practices from the official Angular docs.
At present bare-bones apps are running up and being built with an early alpha of the updated MobileCaddy CLI with work currently focused on porting and updating the AngularJS SyncService.
Update 9th March 2018
The timeline remains unchanged and progress continues with the refactoring of the MobileCaddy libraries. Technical milestones that have been passed include;
Ionic 3 app running up and including the refactored libraries
When running in CodeFlow the app will initiate the DB and create the database tables.
Access to the MobileCaddy libraries from the developer console
Ionic 3 app running up on device using the refactored libraries and unchanged container apps and platform package.
When running on device the app will initiate the DB and create the database tables based upon metadata retrieval from SFDC
Caching and Offline access is working as expected.
The current design should mean that there is reduced friction when wanting to include other 3rd party libs in projects, we hope this continues to fruition.
Update 12th November 2017
Ionic have released Ionic v3.9.2 that supports Angular 5. This release appears to have only a relatively small impact on the MobileCaddy Ionic 2+ roadmap in the guise of breaking changes (e.g. template → ng-template).
Update 3rd November 2017
New major release of Angular released. Angular 5.0. There don’t appear to be many breaking changes (or architectural ones) in this major release from a MobileCaddy standpoint. I’m sure we’ll find out more when Ionic officially release support.
Update 12th April 2017
Ionic 3.0 made its way live on 7th April. This major release has a few notable changes – primarily support for Angular 4, TypeScript 2.2, and the IonicPage page decorators. There appears to be still a few known issue to iron out, according to their blog post.
In terms of MobileCaddy impact it appears that TypeScript considered best practice and will be adopted by Ionic as the way forward. We are continuing to asses the least-impactful way to bring the MobileCaddy libraries into the TypeScript build process, but no doubt this will impact our original dates. The rate of change from the Ionic v2 release, points us to believe that this is not yet enterprise ready and as such are extending our stability window (see updated timeline below).
Update 24th March 2017
On the 23rd of March Google released Angular v4 (note they skipped version 3). Key updates should make the app bundles smaller, which is of primary concern of ours when thinking of mobile devices in poor-connectivity areas. There has been no word in Ionic support yet, we believe.
The Move Beyond Ionic v1 & AngularJS v1 – The MobileCaddy Approach and Timelines
Ionic v2 Final Release is finally here, and aren’t we glad to see it. We’ve been watching the progress on Angular v2 and Ionics v2 beta release with some excitement – and were even present when Ben Sperry – Ionic – announced their first release candidate back in Sept 2016.
And yes, this means that Ionic v2 support is on the roadmap for MobileCaddy too. With the promised performance benefits coming from Angular and the component based architecture it brings we certainly want to be able to give our partners, clients, and their users these benefits too.
As with the move from AngularJS to Angular (v2), and Ionic v1 to Ionic v2 this will very likely have some impacts to our apps, our libraries and also our CodeFlow build environment and tooling, so let’s have a look at what this might mean.
Our Current Concerns
With all the goodness that comes from moving to Ionic v2, we need to be wary of a number of factors.
Current Ionic v2 / Angular v2 bundles sizes are just too big. This is really just a concern for Angular – and when fixed will be fine for Ionic too – but at the moment packaged app bundles are many times larger than we can accept. Work is ongoing, and these are being dramatically reduced, but we’re not there yet.
Code / Tooling Stability – Even since the last Ionic UK meetup, where we were told that Ionic RC.0 would be accepting only bug-fixes, we’ve seen not only changes to core components but also the build tools.Changes in this area are sure highlight that we’re not at a level of maturity yet that is fit for enterprise.
Lack of “real-world” feedback – It’s very early doors, and we’re yet to see any real feedback from heavily used consumer apps using Angular v2
With the above in mind, we’ve created a rough impact assessment on what a move to Ionic v1 would mean for us (at the time of writing);
MobileCaddy Core Libraries – These are the libraries that manage the local encrypted database, handle the synchronisation process, and expose the developer APIs. These libraries cannot be ported straight into an Ionic v2 app. It’s believed that at least some refactoring be undertaken to make them ready for use.
Shell, Seed, and Starter Apps – As these are the base of every MobileCaddy application, we’d need to ensure that these are re-written with the most up-to-date best practices and efficient code as possible. It is believed that these would need to be written in TypeScript to align to Ionic starter apps and tutorials.
Build Process (MC CLI) – MobileCaddy apps are not currently built with the use of the Ionic CLI. It’s thought that the move to webpack along with the optimisations features of both the Ionic and Angular CLIs (such as AOT compilation and tree-shaking) that we would try to align with these, instead of having to re-invent the wheel. This move would have knock on effects and would require some re-architecting, but is thought to be the best long-term solution.
MobileCaddy App Add-Ons – (note – added Nov 2017) As per our shell, seed, and starter applications we would need to re-write these in TypeScript and for Ionic v3.
CodeFlow Control Panel – Currently thought that there will be no impact to the CodeFlow Control Panel code, though some process around exposing it in the Ionic/Angular CLI may be required.
Documentation – Existing API documentation should remain untouched.
Tutorial – Our tutorials and cookbook examples will be required to be updated to show the current approach and syntax (e.g. in TypeScript)
Internal Test Rigs/Scripts – The move from Ionic/AngularJS v1 moves from the controllers/services structure. This has direct impact on the unit testing setup with our shell, seed apps. The changes to the MobileCaddy Core Libraries is also likely to require changes to the automated test suites.
Code Deployment Tooling – It is believed that the deployment process can remain mostly unchanged, with only minor adjustments needed to cater for the updated production-deployment commands, and packaged-app structure and contents.
CodeFlow Emulator – With the initial belief that we’ll be moving to aligning with the Ionic CLI there’ll likely be some impact around maintaining the features of the CodeFlow emulator.
Timeline last updated 12/11/2017 – please note this is an internal proposed timeline and is subject to change based on external factors and/or internal test results/architecture decision. Please contact MobileCaddy prior to any purchasing decisions.
What are MobileCaddy doing
Our core priority at the moment is to construct a flexible, future-proof, and backwards-compatible architecture to support the changes in Ionic v2 and Angular v2. The changes relating to TypeScript and build processes impact our current model somewhat, and we’re trying out a few models to see what works, and also what means least impact for the developers and administrators of MobileCaddy powered apps.
Speaking of the devs we’ve already moved to advocating the controller as syntax, and updated our seed and shell apps to utilise this. Although admittedly a smallish step, it should lessen any migration work.
Along with the above we’ve been re-visiting our build tools, and have agreed on an initial move (correct at time of writing) to make more use of the Ionic CLI and it’s own well tested functions.
What about v1?
V1 apps, and support for them, isn’t going anywhere, not for some time anyway. There’s currently nothing wrong with using Ionic v1 – it’s performs excellently and is currently at a level of stability and maturity that is well suited to applications for Salesforce customers.
Ionic have also pledged their support for v1 well into the future.
To even get to a point of Ionic v2 Final Release we’ve seen several changes in direction and reverses in expected behaviour, so we’ll be posting updates to this article as we get them, so keep your eyes peeled.
The Speaker Diversity Programme – brainchild of the DUG organisers Jodi Wagner and Keir Bowden – was set up to act as a step up for new speakers into the Salesforce user group circuit (and hopefully further afield).
The group met in Salesforce Tower, on one of the new floors recently occupied by Salesforce… the view just gets better every time I visit.
And onto the talks… well actually a little preface; I’m going to try to not going into too much detail here, as videos of all talks are available on the DUG YouTube channel, thanks to MobileCaddy.
Process Builder Tricks – Claire Jones
Kicking off the evening was Claire, she talked us through one of her favourite admin tricks; using process builder and filtered lists to show just relevant information to users. She showed us the steps needed to enable this, and also how you’d need to use a slightly different approach if you’re using Lightning Experience.
How to Create Lightning Bolt Templates – Stas Dunayev
Lightning Bolt Community Theming was the next topic, covered by Stas. He walked us through the pre-Lightning Bolt options of cookie-cutter looking community sites. He showed us the composition of Bolt themes, and how each piece, and the theme as a whole are all Lightning Components.
Stas covered the ability to create custom page layouts, and packaging of themes for distribution and use. I’ve personally not had any experience with community themes, but I can see a real market for premium, well executed themes in the AppExchange.
Break The Rules – Julia Doctoroff
What a great title for a talk, and Julia did a great job of delivering on its promise. She walked us through the a mechanism of disabling validation rules via custom settings. The talk takes us through a real life case of needing to perform such a task, the implementation, and the human case of realising something’s not right and then fixing it.
Salesforce life balance – Sankaran Napoleon
I’ve met San at several previous meets, and if someone had asked me to guess what he might be talking about then I think I’d have been pretty close. Sankaran always appears happy, never stressed in the least. So maybe he’s onto something (even if at points it does seem like Benioff himself had commissioned the slide deck).
Developer’s Intro to Lightning – Chris Bacon
I’m not sure how many devs are really using Lightning in the wild, but Chris is certainly among that (quite possibly small) number. His talk guided us through an (all too brief) intro to Lightning Components from a developer’s stance. His overview covered a basic example and demo, and for some in the room it was a real delight to see some code.
If you’re interested in getting into Lightning development then I highly recommend watching this one as well as taking the excellent Trailhead Module.
The Path from Dev to Consultant – Alejandra Sivori
As someone who’s taken the jump (leap?) from Salesforce Developer to Consultant Alejandra gave us a talk on a set of soft skills that she developed during the transition and how they affected her and her team’s results. Alejandra mentioned some advice on how to improve in these areas, and also some of the pitfalls to be aware of.
And the Winner is…
As I mentioned, one of the wonderful graduates was going to get a speaker slot, alongside myself, at London’s Calling 2017. The audience were asked to blind vote for their favourite talk, and the lucky winner is Chris Bacon. Within Chris’ talk there is mention of using browser developers tools to aid your Lightning Development process, so if you’re lucky enough to be attending London’s Calling (tickets have now sold out), then be sure to catch me talking about browser dev tools at 3:15 in the Ctrl room.
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.
The London AUG has turned two, and what a meetup it is, and what a great community it has built up around itself.
As for this particular meet, it was hosted by TES Global, and they did a sterling job with a full complement of refreshments and a buffet that could have fed a thousand. Amanda Beard-Neilson welcomed us all and set the agenda for the evening… swag was on offer for those willing to share their Salesforce stories. The audience participation at the Admin meets is something I struggle with, coming from the relative safe-haven of the DUGs.
The structure of the evening was refreshing and led to some wonderful anecdotes that had strong leanings towards how folk initially got into Salesforce. As well as a repeating theme of “Salesforce transformed my work life, for the better” it was wonderful to see that “community” was high on the mentions-list too.
Along with the great stories, came wonderful opportunities to catch-up with old friends and make new acquaintances… so as odd as this write-up is, I hope you take away the notion that these community groups and meetups are good fun and well worth attending (they’re actually also educational, on the odd occasion).
And on that note, huge thanks to TES for hosting and to all the organisers for fuelling such a vibrant and supportive community.
And with that out the way, let’s crack on. This month’s London Salesforce DUG had a new venue – the WeWork offices, provided by Xactly. On arrival I was asked if I liked beer, as there was lots on offer… as if drones weren’t enough to make me pleased to have ventured out, then that question sealed the deal.
I wasn’t the only one tempted by the meet.
DRONES! – Bash & Cam
Solution Architect, Bashir Qaasim, and Director of Innovation and Thought Leadership at Accenture, Cameron Cronin, stepped up to deliver one of the most anticipated talks to be held at the DUG (since my talk on Building Offline Salesforce Mobile Apps?). There we were, all waiting to find out how – and see – a drone being flown from Salesforce.
To some amusement they rolled out the standard Salesforce Safe Harbour slide. Whether there was a serious reason for it I still can’t work out.
We were given an introduction to drones: how they’re now fairly accessible, some hardware choices, and some of the more common (and uncommon) uses that are being handled by drones. These include uses in areas such as logistics, agriculture, and security. We even heard that there’s a shepherd in the UK that does their morning round using a drone.
Bash told us that for their experiment they choose the Parrot, for a couple of reasons – it wasn’t too heavy on the price tag, and there was a non-mobile SDK available.
For support libraries, there seems to be a lot around. Bash named a few (and I noted down even fewer), including Dronecode, Ceylon.js, ros.org, nodebebop.
Cam then took the reigns to talk us through the possible and chosen architectures.
And then with a whir of tiny plastic blades, the demo was upon us… and it was lovely. Bash talked us through the control screen whilst the the drone whizzed along the front of the audience. He mentioned that, even though their implementation was quite basic, and that actually the reliance and usage of Salesforce.com was very light, that there were many use cases where the platform could really be used to good affect. Such examples are;
Uploading of photos to records from the flight at set waypoints
We also heard from Cam about how the Salesforce app was built. It was interesting to note that the app wasn’t built with Lightning, instead they applied some Lightning styling using the Lightning Design System. We were told that to build this in Lightning would have taken a lot of effort, but whether this was to do with familiarity or technical limitations wasn’t expanded upon.
To conclude, the chaps mentioned a few things that they had picked up during their investigations and build… but the one that stuck in my mind was ‘build in a kill switch,’ I think we can all imagine that this was learnt the hard way.
Intro to Clayton, the Code Review Bot – Lorenzo Frattini
I know I’ve rattled on about Drones, but the truth is that this talk was just as exciting to me… and Lorenzo, a Certified Technical Architect at makepositive, did not disappoint.
He first talked about good code, and what makes it good. We were shown some code that passed basic good code tests – adhering to governor limits, applying standards, etc. – but actually was full of errors, and hard to read and understand. We were shown some quotes by a few well respected folk about what they thought that made code good. It became clear that code needs to be good not just for the original author, and the system it runs in, but also for any poor-old-dev that has to pick it up in years time.
“Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.”
– Martin Fowler
We were asked for a show of hands as to who frequently took part in code reviews, and it was encouraging to see so many people raise up (nice one Salesforce devs!). Lorenzo also showed us his code review checklist (this can be seen in the slides – link below), and he told us that as comprehensive as it is, he wondered about the potential of automating it… enter Clayton.
Clayton is a code review bot for Salesforce. It was initially a side project in early 2016 and is now available (free for open source projects) at clayton.io. It’s a static code analysis bot that runs on Heroku and can be triggered to run off each commit/PR made to github and bitbucket repos. Once a review is complete the bot will leave a comment on the PR, and also keeps stats on the defect density over time.
“Leave the codebase cleaner than how you found it.”
– Frank Hart, MobileCaddy
We were told how Clayton was in use at makepositive, and in the brief time it’s been running they’ve seen drastic reductions in defect density for existing codebases (e.g. 21 down to 3), and how new projects had nice low linear metrics too. This drop in defects is something that I like, and actually is something that our Frank Hart mentions in his post on targeting 100% code coverage as starting hotel… I definitely recommend reading it once you’re finished here.
What was interesting to hear was that even though Clayton was reporting the same issues that might have come from a colleague during a code review, that actually the author of the code was likely to receive the information better coming from Clayton, since it was viewed as hard facts rather than personal opinion… we humans are so funny sometimes.
The pricing for Clayton is still being worked on, so I suggest pinging Lorenzo to find out more.
Lorenzo’s slides shall be posted to soon.
This was an excellent and well attended meet; the talks were good and I personally enjoyed them… and to make sure I’m not just being biased I also like to measure a talk by how much conversation it sparks and how many questions the speakers have to field. And in the case of both these talks there was much interest and many good questions from the audience. Huge thanks to Lorenzo, Bash, and Cam for spending their time on putting together talks that they obviously felt passionate about.
Thanks, as usual, go to the wonderful organisers of the London SF DUG – Anup, Jodi, Richard, Keir, Justin – and special thanks to Xactly for sponsorship. Thanks too to MobileCaddy as there should be videos of both talks up on the DUG YouTube channel within the coming days.
It had been a long, long time since the last Ionic Meetup, and much had changed in the Ionic landscape – not to mention Angular 2 – so I personally felt it was really good to see some of the community members again in person. The timing of this particular meet was also handy in terms of it following directly on from Angular Connect, as it offered us the chance to hear, in person, from some of the key folk (aren’t they all key?) from the Ionic team.
Once again it was Ryan and Sani who organised the event, and arranged it to be held at the newly-opened Shoreditch Platform. The venue wasn’t a bad space at all, and it’s bar was funded by Ionic, so that was a bonus (for me at least) too.
There was one pre-planned talk, and this was sandwiched betwixt an introductory Q&A session with the Ionic team, and a more impromptu showcase session. The latter had be run at the previous meet, and is a really good way to show-off, and hear about, what folk are up to.
Ionic Chat and Q&A – The Ionic Team
As I’d mentioned, we were joined by a few folk from Ionic – in alphabetical order, Adam Bradley, Brandy Carney, Alex Muramoto and Ben Sperry (co-founder) . They had been talking, presenting and sponsoring at the recent Angular Connect conference in London, so for them to attend our meetup was a great opportunity.
Ben kicked us off with a few notifications – apologies if I missed any, but these two are hopefully big enough for you.
Ioinc2 RC is out. We were also told by Adam that they should only be working on bug-fixes from now until go-live.
Ionic Cloud is now out of beta.
The discussion then began between the panel and those in the audience. This was an excellent session that I personally enjoyed, and I believe I wasn’t the only one. There was a lot of topics covered, and I have to admit to forgetting to make notes on each subject as I was so absorbed. I hope, though, that this is a pretty comprehensive list;
Windows support, within Ionic Cloud, is being looked at (note, I don’t think being worked on)
PWA and Desktop Support
PWA support within Ionic Cloud (Push Notifications, etc) is also being looked at.
The subject of Desktop Apps was also raised, and the prospect of bringing in Electron as another target for the Ionic CLI seemed to be well entertained. This is very exciting and continues to push toward the dream of a single codebase for all targets.
Why Upgrade from Ionic1 to Ionic2?
Even with the continuing improvements to scrolling performance in Ionic1 (especially on Android), Ionic2 scrolling is even better. In fact performance is a real plus with Ionic2. The team said they’ve learnt a lot during the birth and evolution of Ionic1, and these lessons have been taken into the very core of Ionic2. Along with these Ionic specific improvements Ionic2, of course, also benefits from all the great optimisations that come with Angular2.
Performance is also improved through several other optimisations, such as tree-shaking – that includes the removal of un-used code – and Ahead of Time compilation. There was even a comment made that the ng2 Hello World is down to 24kb.
Ionic Native – Aaron Czichon
This talk was given by Aaron who heads up the Ionic Germany meetup, and he was here to talk to us about Ionic Native. Ionic Native is, according to their site, “a curated set of ES5/ES6/TypeScript wrappers for Cordova/PhoneGap plugins that make adding any native functionality you need to your Ionic, Cordova, or Web View mobile app easy.”. To me this looks like an ngCordova for Ionic2, with the bonus that it takes care of the TypeScript jump for you.
At the time of writing there are 105 cordova plugins supported, and Aaron was sure to mention that the team is very active and keen to add support for new plugins… so if there’s one that’s missing, please raise a ticket.
Aaron showed us some code for how easy it is to access any of the supported plugins through Ionic Native, and to be honest it seems to set the barrier to usage very low indeed. His example used Ionic Native with a plugin called Brightness, and it all looked incredibly simple.
One of the things that was really useful in Ionic1 was ng-Cordova, and its mocks. These allowed browser based testing of logic that used Cordova Plugins. I mentioned this point during the talk’s Q&As and Ben Sperry noted that mocks for Ionic Native are on their way (and should include Creator and View). Whilst on this topic it was also pointed out that Microsoft Code has an extension called Cordova Tools Extension that adds support for some plugins built in, this might be well worth investigating.
The showcase session is an informal “show and tell” and it’s a great chance to see how other developers and businesses are using Ionic.
Sportmate – Tom Haleminh
Up first was Tom Haleminh who showed off Sportmate. Sportmate is a fantastic looking app that aims to help players of sport to find others to play with and book up facilities like football pitches. Tom said that they’d had some external investment and had seen some amazing growth. I noted down a figure of 40%, but I can’t remember what this was precisely in relation to.
We’d seen Jambuster at previous meetups’ showcases and it was displayed again. It’s a really smart looking service for folk wanting to keep on top of their travel across London. In their own words “Jambuster is a new, innovative app to help you drive around London. When traffic problems occur, our systems automatically track the problem, analyse it and where appropriate, predict how long it could take to clear and can send you ongoing personalised notifications bringing you up to date. We do the hard hard work so you don’t have to”.
There was a third really interesting demo that showed off some hardcore camera integration, but sadly none of my notes on this make any sense… I can only assume I was too engrossed to be able to write clearly. If anyone has any details on this then please let me know, thanks!
I thoroughly enjoyed the sessions and thank Ryan, Sani, and Ionic for organising and sponsoring the meetup.
As with other meetups that include them, the informal chats afterwards proved to be just as interesting… I do hope that other groups make these a more standard part of the event. During the after-chats Justin and I talked at some length with Ben about how MobileCaddy and our partners are leveraging Ionic to deliver true robust, enterprise grade applications and how many of our joint clients are astonished to hear that the apps aren’t native and are in fact hybrid apps.
Here’s hoping that it won’t be so long until the next Ionic UK meetup, and perhaps it’ll even be in a city other than London.
It was back to the splendid Salesforce Tower, Liverpool Street, for September’s London Salesforce DUG. The standard fayre of beer and pizza (and Coconut milk, for those that fancied it) was available, so let’s thank Salesforce for the venue and Westbrook for the sustenance.
Tom’s talk focused around a Job Scheduler component that he has written, and he used this as a reference throughout. The approach made it very easy to relate the concepts he spoke about to real life implementations and challenges. The code for the scheduler can be found in Tom’s git repo.
Tom covered a variety of aspects including;
Composition using Facets – Including the aura:set and Event Bubbling (including a Winter ‘17 improvement called includeFacets
Dynamic Creation of Components
Object Orientation – Encapsulation + inheritance, and some of the current limitations and workarounds.
It is clear that Lightning is still evolving with every release of Salesforce, and it seems that, despite some good fixes coming in with the Winter ‘17 release, some of the missing/broken parts are still a barrier-too-far for many ISVs and consultancies alike. With this in mind though, it was also good to see John Belo – Director of ISV Technical Enablement, EMEA – ask Tom (and the audience) how Salesforce can improve Lightning for developers and what could be done to increase its adoption.
Winter 17 Lightning Release, Highlights for Developers – Laura Kulikauskaite
As the newest Associate ISV Technical Evangelist, Laura was at the DUG to talk us through some of the changes to Lightning in Winter ‘17, and how these changes affect and can be used by developers.
The first thing that she mentioned was a new Winter ‘17 Lightning Trailhead module, so if you’re dabbling with Lightning (or using it in production) then it would be good to check out.
As well as the fixes and improvements that Tom mentioned in his earlier talk, Laura covered some nice new enhancements to Lightning. These include;
Custom Lightning App, with custom Lightning navigation bar
App Launcher available in the access menu
Utility Bar – Currently only available to ISV partners. Should be available for all users in the Spring ‘17 release
Laura also covered the release of many more base Lightning components (icons, badges, inputs, etc) as well the support for Quick Actions.
Another new feature, that apparently has been highly demanded by users, is Inline Editing in Listviews. I remember a breakfast-meet back in January ‘16 at Salesforce Tower (before it was kinda-called Salesforce Tower) where this idea was originally spoken about. Diego Ferriro Val – Software Engineer/Architect Lighting – spoke about how Inline editing can quickly lead to a huge increase in transactions to the platform, as each edit could kick off a save event. In the actual approach demonstrated at the DUG the list remains in an at-risk state, with edits highlighted. A Save button actually needs to be clicked for the edit to be sent to Salesforce. Whilst this approach does get over the risk of adding unnecessary load to the platform, it does potentially mean that these at-risk edits could be lost, if for example, the user’s laptop ran out of battery, or crashed. Perhaps Salesforce are using a more persistent local store for these edits to combat this, though this was not covered in the demo. Within the MobileCaddy apps we take an offline-first view on these types of actions, and we would be using the persistent encrypted local store for all edits, so as to reduce any real at-risk records.
A demo of the Lightning App Builder was also on the menu, and I have to say I still noted Lightning to be pretty slow. I’m sure work on improving this is ongoing, but personally I think the current performance is going to irk users who are using LEX. And I might be wrong but doesn’t the screenshot below look like a classic list view (yes this is my Summer ‘16 dev org, but still looks the same in Winter ‘17)?
During the questions, the point of unit tests within Lightning was raised. We were told that these are planned for Spring ‘17. I’m sure this will make many developers much happier.
It was another truly interesting DUG, and I really must thank Anup Jadhav and Jodi Wagner for organising and Westbrook and Salesforce for sponsoring and hosting.
It’s good to see the evolution of Lightning, though it is very clear from chatting to other attendees that adoption is still slow.