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:
McRest
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.
Recent Items
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.
JavaScript
1
2
3
4
// Get recent ‘Account’ object records.
let recentAccounts=RecentItemsService.getRecentItems('Account');
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.
With yet another fantastic panel of speakers, experts, and MVPs presenting at the event as always, recognised Salesforce consultant Phil Walton has released his 2017 list of 25 people to meet at London’s Calling. This year, MobileCaddy’s own Senior Mobile Technical Architect Todd Halfpenny has been named on that list, as he’s set to give a presentation which will provide the audience with tips and tricks for making the most of a browser’s developer tools. Continue reading…
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.
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
And since this is ‘post number one’ in the series, let us start with an introduction to desktop hybrid apps. As with mobile hybrid apps, those for the desktop can be initially understood as applications that are written with web technologies – HTML, CSS, and JavaScript – but they reside within a native container that exposes functionality and features of the host’s OS and hardware. This exposed layer includes support for aspects such as the following;
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.
As on mobile, desktop now has its own enablers for hybrid apps. These have their containers provided by projects including Electron and nw.js. These offerings utilise Node.js to build the bridge between the JavaScript world, and that of processes which have access to standard OS features, such as the file system. The hybrid apps can also be crunched up into natively installable (and upgradeable) forms, such as MSI for Windows and dmg for Mac OS.
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.
In actual fact, we’re very close indeed to having a single codebase. It’s possible to write a JavaScript application that can be served as a PWA, enclosed in a Phonegap wrapper, or included in an Electron project. This means we can cover this vast landscape without the need to change barely any of the code that makes up the business logic or styling of your app. The vast majority of differences are more aligned to build tasks rather than application code.
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.
For mobile we could use the IonicNative project (and let’s say our chosen plugin is supported by it), which means we’ll inject that single dependency, and use IonicNative to access the plugin, which in-turn bridges the JavaScript-to-Native divide and allows us to create and use our SQLite database. For desktop, it’s a little different. For our app to access the node package we could use Electron’s IPC to make a call from our renderer process (where our SPA is running) to the main process.
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;
JavaScript
1
2
3
4
5
6
7
8
9
ionic create MyIonicCode
ionic install ionic-native&&mySQLitePlugin
Write some code
ionic build--all-the-platforms
Feel smug
ionic deploy
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.
Summary
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.
Of course, it’s good for us, in terms of upskilling our employees and in general giving access to superb resources for all future staff. But, and I’m just going to come out and say it, I want more.
Imagine this, a Trailhead Builder for ISVs (in fact wouldn’t it be great to earn your Trailhead Builder for ISVs Trailhead badge).
That’s right, wouldn’t it be great if you were, say, employed at Ebsta and you had a tool to create a Getting Started with Ebsta trail and have trails such as Creating Your First Templates. How fantastic would it be if you could submit a config file that described a set of objects and properties to be evaluated, which could be used to do the brilliant automated marking that Trailhead does when it connects to your dev org?
I know for sure that our customers would appreciate some MobileCaddy badges, either for admins or devs. I can really see how valuable a badge for Defining Your First Fully Offline Mobile Table could be to our clients, be they part of an end user org or a MobileCaddy Partner. It’s all well and good having our own training resources, but if we could offer an interactive, online pool of information and tests, that aligned to those they are likely to be familiar with, then it can only be positive.
Such trails become even more important, I believe, when ISVs are faced with not just upgrading their apps to be Lightning-compliant, but also having to update their training materials, courses and documentation, too.
I can only imagine that such tools or processes exist internally, and hope that this post my tweak some interest and ignite some excitement over such feature set being available for ISVs.
Last month’s London Salesforce DUG meetup was an odd one. It was a viewing party for the keynote(s) of the TrailheaDX – the annual Salesforce Developer conference. As interesting, and enjoyable, as it was, I was pleased this month’s agenda was back to the “couple of talks and then chat”.
But before all that, Keir Bowden kicked off with a short community message… “we want more speakers”. So if you have a passion for something that you think the Salesforce Developer community might like, or a demo of something cool, then please, please get in touch with the group.
“We want more speakers, get in touch”
– London Salesforce DUG Organisers
The Welkin Suite IDE – Rustam Nurgudin
Starting off the talks was Rustam, CEO of The Welkin Suite, the company behind the IDE that is really impressing Salesforce devs. He told us how their IDE was born of frustration with the existing tools that were available. As with other great products, they saw a problem and – in my eyes at least – have made some incredible dents in it.
The amount of features and tools in the suite just seems boggling. The core editor has everything and more that you’d expect in an editor… and then some;
Code completion
Syntax highlighting (apex and Lightning, I believe)
Mini-map (with magnified preview and error highlighting)
Snippets
Unit test statuses and actions available in the margin
And probably others – Rustam was demoing faster than I can take notes!
Other parts of the IDE included Unit Test (code coverage, jump from logs to source, retrospective debugs and more), a Profiler, class libraries and project inspector. The latter includes the neat support of specifying your own folder hierarchy that can be shared with other members of your team. Oh, and I almost forgot their WAVE PREVIEW FEATURE!
For the time being it’s free and is available on Windows, with a Mac version coming soon. Rustam believes that in future there’ll be a monthly subscription for use… but to be honest talking to the other devs who were at the meet it seems the features of the IDE are well worth a small recurring fee.
I chatted to Rustam following the meet and he’s very keen to get developers outside of their business using it, and is openly requesting feedback… so what are you waiting for, download The Welkin Suite now and let him know what you think!
Road to Becoming a CTA – Sunny Matharu
Up next was Sunny Matharu, of Deloitte. He told us how they’ve recently been discussing the updates to the types of architects that will (or do, now) exist in the Salesforce ecosystem. The talk title seemed to be a bit link-bate-esq, but I’ll forgive him, as it was a really good open talk and discussion on the new state of certifications relating to Salesforce architects.
What we actually covered was the new certifications that are ( and will be, maybe) available, and how they all fit together and what they will (probably) mean for the dreaded final CTA review board exam.
“Sometimes I wonder if Salesforce make more money from licenses or certifications”
– Anonymous
So this is all a little confusing and still new – and/or not yet out finalised- so please take what follows with a pinch of Safe-Harbour-salt. Salesforce have introduced 3 new Domain Specialist certifications and are going to introduce 2 new Domain Architect certifications.
Looking into the study guide of the Mobile Solutions Architecture Designer certificate it seems to cover a lot of what we undertake every day at MobileCaddy. Be it designing solutions to support secure mobile Salesforce applications across multiple devices on multiple OSs. Or understanding and explaining the suitability, strengths and limitations of the different options an organisation might face when undertaking a mobile transformation project. The materials already available to support those wanting to gain this accreditation appears to be pretty thorough… I just hope that a mention of MobileCaddy in an exam would get the participant extra credit
As for the two Domain Architects certs it’s believed that they will be as below… but at time of writing the closest I could find online was a note on the Architect Academy to say they’re “Coming Soon”.
Application Architect
System Architect
Sunny went on to say that the idea behind these extra certifications was that it would hopefully reduce the failure rate of the CTA final review board, by breaking down areas of expertise into individual chunks and exams. I wanted to find out more about how he’d got all this info, but I missed him after the talks, but from what I gathered he, through Deloitte, had been chatting to EMEA CTA expert at Salesforce.
“The number of Salesforce certs on a project team can affect how they are won”
– Sunny Matharu
I really enjoyed the open discussion of this session, and Sunny came across as a very knowledgable and personable chap, and one I hope we hear more from at the DUG.
Wrap Up
As I mentioned earlier, I really enjoyed the make-up of this month’s DUG; both talks were full of knowledge and passion and I think everyone in the audience took at least a few items of interest from them.
As usual, the chats following the meet were entertaining and thought provoking, and definitely worth sticking around for. It’s was good catching up with folks I’d met before as well as new faces… including one chap I’d spoken to many times on conference calls but not actually met before.
Of course no write-up would be complete with a nod to all the sponsors (CapGemini, MobileCaddy) and organisers.
In June 2016, Gartner released their Magic Quadrant for Mobile App Development Platforms report. It looked at the major vendors within the MADP (Mobile Application Development Platform) space and evaluated them against multiple factors, including customer experience, pricing, marketing understanding, and innovation.
Image: Gartner
Within the report, Salesforce is favourably judged and comes a clear third, both in terms of Completeness of Vision, and also for the Ability to Execute. First and second place are closely contested between IBM and Kony.
Whilst third isn’t a bad position, with the addition of MobileCaddy to your tool-belt, it’s clear that it becomes a real contender to take the lead spot.
Mobile App Testing
In the report Gartner notes “In the Salesforce App Cloud platform, mobile app testing support and its integration with third-party testing services are not such a focus area as in other MADP offerings.” Whilst this is true for apps written to be consumed within the Salesforce1 container, it certainly isn’t for custom applications built upon the Salesforce Mobile SDK.
MobileCaddy applications have their client part written in JavaScript, and as such are well supported by existing testing frameworks, services, and continuous integration setups. As well as having the client code being pushed through CI processes – for example Travis CI, Jenkins or Pipelines – we’re also able to push automated testing through real devices using open tools such as appium, as well as third-party services.
Image: Atlassian
At our very core is the belief that app performance is paramount, and as developers, designers, and architects, we need not just our applications to be paranoid, but also our development and deployment workflows too.
Custom UI and UX
The report writes, “Customers must temper their expectations on RMAD (Rapid Mobile App Development) capabilities, because the Salesforce1 container approach to deploying apps created with App Builder poses UX limitations.” As accurate as this is for those applications that are built with and for Salesforce1, it’s certainly not the case that Salesforce customers are limited to this when it comes to application UI and UX.
With MobileCaddy you can have a fully custom UI and UX in your application, whilst retaining the incredible flexibility, scalability, and security of the Salesforce platform.
Image: MobileCaddy
At MobileCaddy we openly support and promote the use of the highly-rated Ionic Framework in providing the UI layer for Salesforce mobile apps. With the power of Ionic – it’s components, platform continuity, and performance focus – we’ve been able to deliver beautiful apps that offer 100% bespoke design. These are ideal for community applications where it’s key that the branding of the application is truly aligned with that of the task and organisation it was built for. The custom UI enabled by MobileCaddy extends right through to the App Store listings and app icons.
The Bottom Line
Salesforce is a strong player on the MADP space. With the use of MobileCaddy it can be even stronger and address the concerns that Gartner had during its evaluation. Since the report Salesforce has also strengthened and refined its own position on mobile application development with the introduction of App Cloud Mobile.
Request an evaluation today to see how MobileCaddy and a Gartner-backed MADP can give you a true mobile advantage.
With the recent push of Salesforce’s App Cloud Mobile, their Summer ‘16 release, and the update to Salesforce1 for iOS, you’d be forgiven if you thought that full offline was now available to all Salesforce mobile users through the stack mentioned above. But as always, the Devil is in the detail.
The number one thing of all time asked for, for Salesforce1… is offline.
– Marcus Torres, Senior Director, Salesforce
It’s no lie that some offline functionality is available, and as Marcus Torres, Senior Director Product Management mentions, offline was one of the most requested features in Salesforce1. What we need to be aware of, as CTOs, Solution Architects, and Developers, though, is just how much offline functionality we get.
Offline Data in Salesforce1
Included in what we do get in Salesforce1 with offline read/edit support is:
Records for Recent Objects recently accessed, limited for the first five objects (excluding Files) in the Recent section of the Salesforce1 navigation menu.
Records for Other Objects viewed in current session
Note: that recent means records that have been accessed within the last two weeks.
So what don’t you get?
Access to Recent Objects you’ve never viewed
Access to Recent Objects you’ve not viewed in the last two weeks
Access to Recent Objects that are not in the top 5 of the “Recent section of the Salesforce1 navigation menu”
Access to other objects that have not been accessed in the current session
Access to dashboards not seen during the current session
Access to Visualforce pages.
Why is this Important?
A few scenarios spring to mind that could cause some issues with the above limitations:
Imagine a user of your app is a salesperson of agricultural equipment, they’re out visiting a client in the poorly connected countryside. They’ve already cached the account data they’ll need (they’ve even remembered to do that) and that’s proved useful as they were able to create a lead offline. Their meeting finishes earlier so they pop to another client at another farm nearby. That meeting goes really well, and they want to capture new opportunities… but they can’t, since this account’s details weren’t in their cache.
Or how about your users trying to take an order for a product they’ve not accessed before whilst selling medical supplies in a hospital?
If you can’t fulfill these tasks then your process,
and your business, is broken.
When it comes to business critical processes, not only complex ones, you need to go beyond Salesforce1’s offline capability.
With MobileCaddy your device not only downloads and securely stores your recent items – using the same encrypted method used in Salesforce1 – it also pulls down and keeps in sync any records that you might need for your work, so you can perform all your tasks offline.
MobileCaddy and Offline-First
MobileCaddy is built with disconnected users at its heart. By designing and supporting apps with an Offline-First approach MobileCaddy not only has its data offline, but also its logic. This means complex business logic and constraints – including parent/child relationships, field level access control, etc – are all in place and functioning, allowing for 100% offline create/edit support.
We’ve incorporated unique features such as full offline data and logic,
customisable UI, performance monitoring and analytics
– Justin Halfpenny, CEO, MobileCaddy
And because MobileCaddy apps are Offline-First they’re also faster. The majority of database reads and writes are to the local store, meaning normal page and app tasks are completed instantaneously, rather than waiting for network transactions to take place. As our CEO recently stated, app performance is not to be underestimated in the enterprise space.
MobileCaddy takes app performance even further. Instead of having all fields for all records buzzing up and down over the wire, we’re able to define exactly which fields should be mobilised, and also which records users require. And during sync operations we also only pass deltas across, lightening the load even further.
Take Home
When contemplating your Salesforce mobile solution make sure you’re aware of the constraints in the offerings available, and that you pick the route that’s going to give your organisation or your clients the mobile advantage they deserve. And in the words of Adam Seligman (EVP, App Cloud, Salesforce), “Sometimes you want to build completely custom apps… take advantage of local device features… do offline sync… we’ve got that in the mobile SDK.”
Fill-in the form below to see how MobileCaddy can really take your apps offline and experience the value of true enterprise mobility
There were two talks on the night, both Lightning related, though they were quite different from each other. I suppose that’s what happens when you get a new, slightly ambiguous, branding phrase.
Migrating your Apps to Lightning – John Belo
John is an ISV Technical Enablement Director (EMEA) for Salesforce and I’d met him a couple of times before. He had offered his assistance to us at MobileCaddy if we ever needed help with anything Salesforce Mobile SDK related, a kind offer to which I replied that we found them very helpful already – MobileCaddy has actually been submitting code to the core Salesforce Mobile SDK project for a couple of years, providing improvements and bug fixes alike.
The team who work on the Salesforce Mobile SDK are key to anyone wanting to build mobile apps that offer true offline capabilities, and stretch the demands beyond those that are catered for by Salesforce1. We’re thankful for them doing such a great job, so that we can do ours.
John was here to talk about how ISVs can start migrating their apps to Lightning. This is something I’m sure Salesforce wants to really push, to generate some traction around the technology. It was interesting to see though, when asked, how many users were already using Lightning in their apps, which turned out to be only one amongst us all. Other notable stats mentioned were;
140+ Lightning-ready Apps
50+ Lightning-ready Components
These stats show that although Salesforce is mightily keen on pushing Lightning, it still has a long way to go to gain traction and take-up among ISVs and users alike.
The core of the talk was focused around how ISVs can start using Lightning today to prepare themselves for further takup by users. There are several routes to this, depending on how much work you want to undertake, and also the architecture of what you currently have (if anything). These approaches range from simply adopting the Lightning Design System for style, right through re-writing apps with Lightning components.
One handy route to slowly and controllably adopting Lightning is to migrate chunks of functionality to Lightning, piecemeal. This can be achieved by using Lightning components within Visualforce pages.
Pic courtesy Salesforce
Talks like this from the ISV team are really handy, though I think it will take more (at least more time) for partners to really start rolling Lightning into their current offerings, especially when there are still some elements that are’t available through Lightning yet (and no concrete ETAs, either).
From a mobile perspective, the drive to Lightning may smooth the road to getting apps to fit well with Salesforce1, though of course they will then be subject to the constraints that come with it. Applications that still require advanced features, such as a fully customised UI, or full offline support, need to be built outside of Salesforce1. If your app has the requirements then MobileCaddy is the answer for you.
Lightning Connect Int. with OData Services – Marc Paris
Marc is a Technical Architect at Cognizant and kicked off a passionate talk on Lightning Connect. He talked about how and when it can be used to pull external data into the Salesforce UI.
Lightning Connect was launched towards the end of 2014, but I hadn’t really seen it in action – or maybe I had, and I wasn’t aware of what was happening under the hood, but I suppose that’s its beauty, right?
Lightning Connect can be used to connect in these scenarios;
Lightning Connect ←→ Lightning Connect – for inter-org communication
Lightning Connect ← → oData Service
Lightning Connect ← → Custom Adapter
Marc took us through a demo of the second option, where he had a basic oData service running using the Apache olingo project. He showed us how, through config, the connection could be added, and how Salesforce would use the web service to discover the objects available. Lightning Connect can support the following features, as long as the backend service does likewise;
Create, Read, Update, Delete
Filters
Inter-object Relationships
Integration with Global Search.
His demo included querying the REST API in a basic manner, as well as using page layouts to filter the data that is requested from the source. He also showed us basic update and delete flows too… it all seems very powerful.
£33k per external source, wowee! – Todd Halfpenny 2014
The power though does come at a cost, currently £33,000 per external data source… a price tag though that may well put a big-ol-hole in a lot of business plans.
It’s interesting to think that through the use of Lightning Connect that no data is stored on SFDC itself, and that it is all pulled/pushed in real-time to and from the external data source. Whether this helps with any data residency restrictions is, of course, another topic altogether. In the questions that followed Marc’s talk the mention of PCI was also raised, but it seemed we all agreed that internal logs may also contain data, so this would need further investigation.
I will post a link to Marc’s slides once I have it.
Wrap Up
Initial thanks, as always, go to the organising crew, and especially to Anup as he was the only one able to make this outing. And thanks to must go to Cognizant who sourced the venue, beers, and pizza (and chocolate snacks too).
Lightning isn’t going to go away, but the path for ISVs is a long one, and one that is going to need investment. With regards to Lightning and fully offline, robust mobile apps, there are still several gaps to be filled. For these reasons it’s not currently our go-to framework; it does not, at the current time, lend itself to the control and extensibility needed to support mobile apps that fulfil parts of critical business processes. Performance issues are another reason that, at present, we are steering our partners and clients to alternative such as Ionic, though of course we hope that this will change in future.
And as for Lightning Connect, I have so many ideas on how it could be used, I just don’t have pockets deep enough.
Unless you’ve been living under some kind of Salesforce-repellent-rock you’ll be aware that the inaugural London’s Calling event took place on the 5th Feb. But if you were under that rock then I’ll quickly mention that it was Europe’s largest Salesforce Community event to date.
When I first heard of the event, at the monthly London Salesforce Developers meetup, I was very excited, and pitched to the MobileCaddy team that we should submit a talk idea… so to say I was honoured to have our MobileCaddy CFP response accepted was (is) of course an understatement. There were 70 CFPs received by the organising team (more on that motley crew later) and there ended up being 28, plus two keynotes.
Only the Paranoid Mobile Apps Survive
This was to be my first speaker slot at a Salesforce event… I’d done a couple at the Ionic UK Meetup group before but they’re not on quite the same scale. My talk was entitled Only the Paranoid Mobile Apps Survive and focused on some key stumbling-blocks and factors that needed to be taken into consideration when wanting to take a critical business app mobile. Although our MobileCaddy SDK greatly helps in supporting the app designer and developer in these areas I was keen for my talk to steer clear of becoming a sales pitch. Having spoken to Simon following the acceptance of the talk into the program he mentioned that this angle was one that led them to choosing it for inclusion. Simon and co have been extraordinarily efficient since the event too. And in speaking of them, the fabulous organisers were;
In the lead up to the event Simon made sure I had a clear timetable for submission of various steps of the talk, and I don’t know if this is the norm, but it certainly helped me avoid a “last minute rush job”.
Right, time to start work on the real slides for #LondonsCalling.
Better pour myself another moonshine then to grab me some animated gifs
On the day I arrived early since MobileCaddy were also gold sponsors of the event and we had a booth to set up. I’ve no idea what time Jodi and the gang had gotten there but things were already in full flow… and the first sight of the T-shirts was really exciting… it was all very real.
I had planned to get to as many talks as I could, but the flow of attendees coming over to our stand was really quite astounding, and I made it to far fewer than I had hoped. It was a genuine pleasure though to experience a real informal, community atmosphere and to have so many chats with folk who were really interested in Salesforce and intrigued to learn more about how we’ve enabled true offline mobile Salesforce apps; the entire sponsors area had a real buzz, and feedback from the other sponsors seemed to mirror mine.
Over lunch (which was top notch, by the way) I met a fellow speaker, David Biden who was also due give his talk in one of the afternoon slots. It was almost uncanny how similar his situation was to mine; a first time talker who had planned an anecdotal style talk who was eager to avoid pimping his own company. We shared thoughts on how tough 15-20 minute talks were to plan, trying to make sure there was enough depth without getting in so deep you run out of time. His presentation covered Salesforce in the Public Sector and is definitely worth 17 minutes of your time… so go watch the video once you’re done here.
Whilst setting up for my talk the event tech-chap in my room was baffled that my laptop hooked up to the projector without issue; well that’s Ubuntu for you 😉
The talk went well, I think. Though there were a few spare seats, but in all honesty I wasn’t surprised… the three other talks on at the same time were being run by seasoned pros, and talks that I definitely would have wanted to attend. Of course I’d love any feedback so please feel free to have a gander and let me know your thoughts.
There’s no way I can’t write an article on the event without mentioning Peter Coffee’s closing keynote… full of food for thought and delivered in the coolest of fashion. Again, check out the vid and enjoy.
“He has two problems.
1) He’s dead.
2) When he was alive he wasn’t scalable.”
– @petercoffee on Steve Jobs
And following that was fun and frocking at the after-party, again the community spirit was in full flow and another chance for myself and the rest of the MobileCaddy team to mingle and chat… and by the time I left I have to be honest I was a little tipsy and very tired.
In wrapping up I can only say that I’m already looking forward to next year’s London’s Calling, and of course any of the other European events that were much talked about during the day. The organisers did a grand job of supporting me, and the rest of the community made me feel very welcome.
