Introducing the MobileCaddy App Extensions

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:

Global Search

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.

global-search

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.

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.

Further Reading


Codeflow CORS Proxy Crashes

Just a quick post to let you know that we’ve seen an issue with the Codeflow CORS proxy crashing out when trying to refresh the access token used to make authenticated calls to the Salesforce platform.

This crash itself isn’t always easy to spot, but can be seen in your terminal window with this kind of output.

 

The issue here can be seen if running 0.12.X version of node, and is caused by a breaking change that was introduced. The latest versions of the request NPM package (that is used in Codeflow) fixes this issue, and can be installed into your setup with this one command.

This line installs the 2.64 version of request  and updates it’s dependencies and also updates your package.json file to represent this.

With this version of request in place the Salesforce token refreshing should now take place as expected. Of course if you see issues still then please message us on our support boards.

We are just in the process of updating our public seed and shell app repositories to include these dependency updates, they should be made public in the coming days following our test cycles.


Introducing the MobileCaddy CLI

It’s been hiding in the wings, but our MobileCaddy CLI v1.0.0 is here!

cli-1.0.0

 

The MobileCaddy CLI is the easiest way to use MobileCaddy to create offline first, robust and versionable mobile applications for Salesforce.com.

Using the MobileCaddy CLI you can quickly create a project structure based on one of our template applications that will allow you to have a deployable mobile application in a matter of minutes. Too good to be true? Just watch this video where we create a new mobile application using Salesforce.com as a backend.

As well as helping us create our new projects, the CLI tool gives us a few workflow benefits including;

  • Ongoing SCSS compilation and live-reload
  • JavaScript JS Hinting
  • Automatic package bundling

If you’re familiar with accessing SFDC from a localhost environment you’ll know that you have to have a CORS proxy set-up, but not to worry, the MobileCaddy CLI will manage the creation and running of that for you too.

What’s new in v1.0.0

The latest release was primarily focussed on stabilising the features we already have, but we also added the capability of defining your own project templates when starting a fresh project. This can be used, for example, if you re-use the same design patterns over-and-over and don’t want to keep re-implementing them on top of the standard MobileCaddy templates (see our Seed and Shell applications). To use a custom template the new command can now be run with a URL that links to a zip file of a project based upon one of the MobileCaddy templates.

We currently have two Ionic based templates available… have we mentioned the we LOVE Ionic?

Get it today

What? You’ve not installed it yet?

If you want to have a dig into the code the project is over on github.

We hope you enjoy it and would love to hear your feedback.

Looking for more info? Why not check out our tutorials and you’ll be mobile applications for Salesforce.com in no time at all.


Using ionic without ionic CLI

You may want to use the ionic JavaScript framework without having to use Cordova or the ionic CLI. This was just what we wanted to do in one of our seed applications to demonstrate how to build robust offline mobile applications that use Salesforce as their backend, so it make sense to share how we went about this.

Ionic without the CLI

Not only did we want the nice CSS framework that the (awesome) ionic guys have put together but we also wanted to use their angular directives. The approach we took is pretty simple, at least that’s what I think.

The solution

Our development setup was already using bower to install dependencies for our app… these included the handy Underscore JS JavaScript utility library and our own MobileCaddy SDK which enables full Salesforce offline capabilities. With this in mind we re-used bower to pull in the ionic assets too. Here is the line from our bower.json file that lives in the devDependency section

This line informs bower to download the 1.0.0-beta.13 release of ionic.

The next step is to enhance our existing Grunt tasks to copy the resources into our existing project structure. This is so that the SCSS is included in the Sass processing and the JS and other assets (fonts, etc) end up being included in our deployable code bundle. In our case our bundle is pushed to the Salesforce platform to be used within our mobile application. The below is a modified version of our Gruntfile.js which only includes the copy tasks needed to support this Ionic use.

And that’s it. Our offline mobile Salesforce application can now be built using the ionic Framework, without the use of Cordova or the ionic CLI.


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.