Where Salesforce Devs go for Support

Salesforce recently undertook a branding exercise to pull together their mobile offerings, products and services, and the output was App Cloud Mobile. As well as this being the first time I’ve really seen a joined-up messages from Salesforce around the why and when one might deviate from Salesforce1, when undertaking a mobilisation of apps, it also triggered something in me that led me to seek an answer to a question that I’ve had for some time… where do Salesforce developers go for support, as their first port of a call?

Ports in a Storm


As a developer, and without causing much judgement upon me, it’s safe to say I frequent StackOverflow and other StackExchange communities a fair amount when looking to solve issues in my job. It’s an incredible source of information (and opinion), and its gigantic community there’s an excellent chance that at least one other person has run into the same scenario you’re hoping to resolve… that’s not to say you never go to find just one post on a problem, and find that you were the author, and posted it two years prior. There is a dedicated Salesforce community available (22k users, 47k questions – at the time of writing), and it’s generally pretty active.

Why do most posts here have zero replies?
– Joseph Nardone, Salesforce Dev Forum

The Salesforce Developer Forums  are not new, though to be honest I don’t think I’ve ever really used them. It was a mention of these forums on the developer page for the new App Cloud Mobile that got me thinking about why do Salesforce not point folk to Stackoverflow instead, and in fact reminded me of one of the posts I’d spotted some time ago.


Now this one might surprise some of you… but there’s a Google+ Community for the Salesforce Mobile SDK, that appears to the most “formal” place to go if you’ve got questions about building custom mobile apps for Salesforce. This is where the internal team post interesting info (release notes, etc). The community (including some of us at MobileCaddy) do reply to posts here, though in all honesty I don’t check it nearly as often as some of the other channels, and I believe this is the same for other users too.

And the Results are in

I posted up a twitter poll and asked folk to vote on their #1 place to go for support, when it comes to Salesforce development, and used the hashtag #askforce to help get responses – how on Earth I didn’t include #askforce as one of the options is a mystery even to me. I was humbled by the response rate and retweets, and for this I’m truly grateful to the community.


As well as the results captured in the poll I also received 11 tweets backing the hashtag #askforce and 7 for “Google”. Having “Google” as an answer is, in my view, an odd one… I tend to think that if I’m to include it then I should also include “The Internet” and “Laptop” as entries. During the write up of this post I was wondering about whether to run another poll, to include “#askforce” and how many more votes the inclusion would likely prompt. Along with this I would think that, with the open source projects Salesforce now manages, that “github” too would be a viable choice.

During a recent Salesforce webinar I asked the chair why Salesforce had multiple channels for support, and whether or not there should be a “preferred” one. I was told that they’d be happy to hear what us developers thought, and would be happy to take that into account. And so this is my next step, to pass on these results. I shall also include a personal plea that the G+ community for the Mobile SDK project is closed, and set on fire, and then the ashes are sent to space… or perhaps just posted on the Salesforce Developer Forums.

Salesforce1 – How Offline is Offline?

Offline and Online chart

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

MobileCaddy Dev Tips – Using the console

The developer tools available in modern browsers are just mind blowing, and we love them here at MobileCaddy. In this post I’m going to cover a couple of tips on how I use the JavaScript console to help me build and debug my MobileCaddy apps.

Calling Angular Services from the Console

Did you know you can call an Angular service from JS console? I didn’t.



I honestly love the fact that you can do this, but I can’t remember where I first heard about it, so sorry for not crediting a source.

Let’s say you have a service called MyService with a function myFunction(), but it’s not behaving as you thought. You can call this function with these commands in the console;

How cool is that?

Calling MobileCaddy Utils from the Console

In the same light as the above you can call the MobileCaddy API from the console too.



Let’s say you are having trouble with a smartSql call not returning what you want, or you want to make sure that you’re table contains the data you thought it did.

In the 2nd line I’m calling the MobileCaddy readRecords function passing in the “MC_Time_Expenses__ap” table name and, if the promise resolves I will log the output to the console, and if the call fails I will get a console error.

I have actually added the above two examples into the Sources –> Snippets in my Chrome dev tools so they’re easily accessible, and I can just copy, paste and modify them as I need to.

These two small tips have helped me no end, I hope they do the same for you too.

West London Salesforce1 Meetup – Jan 2015

Yesterday Creation Technology hosted the inaugural West London Salesforce1 Users and Developers MeetupPaulJustin and I, on behalf of MobileCaddy, are delighted to have been invited to present alongside the wonderful Peter Chittum.

The meetup was entitled Create Mobile Solutions in a Flash and followed nicely on from the last Salesforce meetup we attended which was focused on Salesforce Lightning (see our blog here).

Image by Creation Technology

Peter Chittum – Salesforce Lightning

Peter was up first; his talk was based on two of the Lightning products, Lightning Components and the Lightning App Builder. As per usual with a Salesforce talk the Safe Harbour slide was then presented and with this in mind informed that the Lightning App builder should be in GA in the Summer ’15 release. It’s currently in pilot so is available to use if you ask your account contact.

Lightning Components

Peter covered a few of the basic points, how SF1 was built using Lightning, how Aura is the open source basis of lightning, etc. We’ve written about these before, so I won’t go into details again. One thing that was mentioned over again though, and I think was the big take-away from this part of the session, was the Event Driven approach of Lightning and how this enables different components to interact with each other, through subscription and firing. Components could be one of three types, and interaction between them all is available and this is the grounding for a component based framework like Lightning. The component types are;

  • Standard – Out of the box from Salesforce
  • Custom – Written by you and your teams
  • AppExchange – Written by third parties and available through the (coming soon) ComponentExchange

Peter then showed us a quick demo based upon the Lightning Quick Start tutorial, but he also added an external component in. He used a FileUpload component (written by Peter Knolle and available on github) and demonstrated how the component could be plugged into his app. There’s further info on the component on Peter Knolles blog.

Further info on on what’s available in Spring ’15 and how to use it can be found in the Spring ’15 Lightning Component Dev Guide.

One final note on components is that within a component, developers can include fully fledged documentation, including code examples, specs etc. This, if pushed correctly, could be a big winner for devs everywhere.

Lightning App Builder

Peter then showed us a quick demo of the Lightning App builder. If you’re not familiar with the App Builder then you could do worse than watch this demo vid.

Peter’s demo showed us that with some boiler plate code Peter Knolles’ FileUpload component could be made available in the App Builder palette. It was a brief demo, but I suppose if something has been made quite simple then it lends itself to being quicker than you might expect.

I’m still not personally sure how much the App Builder will take off among the more hardcore devs, but who knows, I might be pleasantly surprised (I’ve not yet used it myself).

Justin Halfpenny – Delivering Enterprise Mobility

Our CEO Justin was up next discussing Enterprise mobility. The WhoWhy and How of delivering what has become standard for consumer mobile applications.

Justin told us how, inside our organisations, more people are mobile than we think. Just because they’re onsite it does not mean that they’re sitting at their desk. As for Why? there are many answers. Not just increased productivity, but also improved customer service and decreased cost of business. All this lends itself to better business… for yourselves and for your customers. We also need to be aware of the rate of change in technology; A lot of people are now walking around with devices that have many sensors and capabilities. Who knows what will be available on them next year, and the year after.

The How? of course is where MobileCaddy comes in.


With MobileCaddy we remove all the boring stuff, the functionality that has to be there, the things that as devs we hope will just work so we can get on with building the functionality that are going to make our apps the best they can be. As an app dev you shouldn’t need to worry about monitoring, upgrade rollouts, authentication, etc.

Justin then demoed a Child Healthcare Tracker application that we had built. Showing how each platform interaction can be logged and monitored, and how this can give organisations peace of mind. He also demoed the MobileCaddy Platform Emulator and Codeflow environments that allow for rapid development and testing of mobile apps built for Salesforce.

Justin’s slides can be found over here on SlideShare.

Closing Notes

Huge thanks to the Creation Technology team for putting on an excellent event. For a “first” meetup it was very organised and well attended and I very much look forward to the future ones. A special note should be made on the supplied food and drink, never before have I been offered Rioja and Olives at a techy meetup… and I think Paul was pleased with this situation.


Preparing to code with MobileCaddy Codeflow

Preparing to code with MobileCaddy Codeflow is the next step after being introduced to it’s components.

In this screencast I take you through using the Codeflow tools to set up a development environment, install one of the MobileCaddy seed apps and set it running in the Codeflow Emulator. This last step includes authentication against Salesforce and querying of live data on the platform. This means our application is initiated with live configurations and real platform data.

There are a couple of dependencies that need to be installed before using Codeflow, these are listed here along with links to installation instructions and/or their project homepage. These dependencies only need to be installed once and perhaps you even have one or some already installed.

In this example we’re using the MobileCaddy Time & Expenses demo application written using Ionic and AngularJS. The MobileCaddy SDK and our APIs though are framework agnostic and we’ll be releasing further shell apps using other frameworks such as BackboneJS.

In the next screencast from me we’ll see how we can mobilise some new fields and modify our shell app to support these. We’ll see how our grunt tasks can make our lives easier. Of course feel free to leave us some feedback or get in touch to let us know what else you might be interested in seeing us cover.

Introducing MobileCaddy Codeflow

At MobileCaddy we’re always trying to make things simpler and easier, with the aim that our time and energy can go into delivering value to our business and to our customers. This is what we want for our customers too, and so we have been working on MobileCaddy Codeflow. 

MobileCaddy Codeflow is a set of tools and application skeletons to allow for swift project initialisation and ongoing development and maintenance. It gives us an extensible file structure and supports us through the development process, right through from initial coding, to test, debug and deployment.

Codeflow Components

Each component of Codeflow has been developed and included to reduce the amount of time spent on mundane tasks.

Project Initialisation

Starting a new project to create a robust offline Salesforce application, optimised for mobile, can be achieved by downloading one of our shell or seed applications from our git repos. Once downloaded there are just a handful of commands to run to install the third-party tools and dependencies and get the project structure all setup.

Codeflow grunt task to optimise project iniitialisation


Codeflow Emulator

The emulator is made up from a set of JavaScript libraries and HTML files that allow the behaviour of the MobileCaddy applications to be closely emulated within your desktop browser. This includes;

  • Salesforce authentication
  • Application database creation
  • Salesforce platform querying so our application can use real configuration and data.
  • An offline local data mode to support broad failure case testing
  • SmartStore emulation – the soups/tables can be interrogated and modified via browser developer tools.
Using the Codeflow Emulator to view Soups


Codeflow currently uses the ForceJS library by Christophe Coenraets to perform the local environment interaction with Salesforce. This is a startlingly simple library that can be used to consume the Salesforce REST APIs, but unlike ForceTK it does not have a dependency on jQuery. We hope to continue contributing to this project as we’ve had nothing but joy when using it.

Task Automation

We have initially used Grunt as our task-runner. This is used during the project initialisation phase to pull the dependencies into our application  structure. It is also used for common web-app-dev tasks such as running our Sass processing, Javascript hinting and general file minification.

We also have some Grunt tasks defined, as part of Codeflow, to create a single archive (zip) file that is pushed to Salesforce as a static resource to deploy our application code.

As we carry on building out the tools we’d also like to implement a Gulp version for Codeflow too, this is on our to-do list.

We’d love to hear what you think of Codeflow and how it can be improved to further release time for developers to do what they do best.