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.
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.
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;
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.
A very hectic few months has meant that I hadn’t been to an AngularJS meetup in quite some time, so I was looking forward to getting along again. And with the topic being AngularJS Performance – Tuning the Engine I was doubly set on making time for it.
The meetup was again held at the Bloomberg office at Moorgate, and as with the previous meetup there their food did not fail to impress – “Chicken Caesar on flatbread with a quail’s egg” canapés. As for the rest of the venue it’s perfectly suited to a large meetup. Huge thanks to them for hosting.
Tuning the Engine – Todd Motto
I’d heard of Todd before, though I wasn’t even following him on Twitter (I have rectified that now) so I wasn’t sure what to expect. Todd is a developer advocate at Telerik, who provide developer tools for desktop and mobile apps.
His talk was originally going to be called AngularJS: The Performance Parts but he’d updated it to suit the story of his presentation. At MobileCaddy performance is key, and potentially any tweak that can be made to improve a desktop JavaScript application has an even greater impact on performance when run on a mobile device.
Todd’s talk was split into two main parts, the first being some educational coverage of the Angular event loop and its $digest cycle, and the second covering some things you could do to help your app’s performance, as informed by the first part.
First up, Todd talked us briefly through the Angular event loop (or should that be AngularJS event loop?). He showed us that it looks like the below (thanks to Todd for the image), with events from the DOM (change, click, blur etc) prompting a chain of events that results in a run (or two) of the Angular $digest cycle that generally ends up in the DOM being re-rendered with updates.
He went further into the $digest cycle next, covering $rootsScope, $scopes and $$watchers. This slowly built up a picture of how these, especially the $$watchers can impact AngularJS performance of an app. This idea, on a general scale, was one I was already familiar with, but he then mentioned something that I wasn’t aware of. When you assign a value to $scope it does not create a watcher for it, a watcher is created when interpolating a value in the view;
someController.js
JavaScript
1
2
3
4
5
6
functionsomeController($scope){
// a watcher is NOT created with this line
$scope.name='Todd';
}
someTemplate.html
XHTML
1
2
3
4
<!-- a watcher IS created with this line -->
<p>Hi, my name is {{ name }}.</p>
During the running through of the above, Todd showed us a very basic demo, and Angular uses the same techniques internally.
Tweaking
The second part of the talk covered a few techniques that can be used to make the most of the way Angular works, and one or two that, for me at least, seemed to appear from left field.
I don’t want to re-produce his talk here as I’d rather you use his material for that (useful links below). But I was previously unaware of a particularly interesting one, so I thought I’d cover it briefly as well as bullet-pointing some of the areas covered;
Reducing the $digest frequency
Optimising the use of ng-repeat
Speeding up filtering (using controller filters)
$digest batching
Production Settings
Disable Debug Info – You can remove unwanted (for production) bindings and class names by disabling the Angular Debug Info config. It’s a one liner in your config block;
JavaScript
1
2
3
4
5
config(function($compileProvider){
$compileProvider.debugInfoEnabled(false);
});
I have yet to try this out myself, but I’ll update here once I have to see what impact this has. I have high hopes as the official AngularJS docs state a “significant performance boost.” Note though that doing this at build time might not be ideal as protractor and batarang (among others?) need it enabled to work.
It was another really useful and interesting meetup, and as well as the talk itself being great I also got the chance to chat to a couple of folk I’d met at previous events: one of whom had actually seen me talk about how MobileCaddy and Ionic can be used to create offline mobile Salesforce apps – what a small world.
Big thanks should go to the event sponsors and also to Ed and Josh for organising another really good meetup, I really hope that time allows me to make the next one.
Following the (very exciting) release of Ionic’s Release Candidate 0 (v1.0.0-rc0) you may have found that the animated icons you had for your loading dialogues are no longer there. This is due to the version of Ionicons included by default being moved to 2.0.1, and this release has dropped the icons such as ion-loading-b, etc.
The reason for this is explained in this forum post and is deliberate. There is a new ion-spinner directive available that makes use of SVGs and can be used as a replacement.
We’ve put together a quick Codepen that can be used as an example. Note the extra SCSS to treat the ion-spinners in a similar manner to the icons, this is pretty but it means minimal work to get it working as a replacement. Also note the SVG targetted SCSS that shows how these can be styled.
I’m sure they’ll be some further enhancements to the built-in Ionic SCSS to better manage this, but for the time being this seems to be a very workable solution with our controller code looking like this;
Our first MobileCaddy webinar is a great starting point for Salesforce developers who want to get building offline mobile applications using the latest and greatest JavaScript frameworks.
As per our preview post, some of the MobileCaddy crew headed to the very first Ionic UK meetup… and boy what a fab evening it was. The event was organised by Sani Yusuf and Ryan Hanna and to say their efforts were clear to see would be an understatement.
The meetup took place at the excellent SkillsMatter, and they had everything that could have been asked for from a venue.
Sani Yusuf – Kick Off
An introduction to Ionic, it’s past, present and future was the starter dish for the evening. Sani took to the front in his famous Google Glass and took us through what life was like before tools like Ionic arrived on the scene. This was a time when to develop apps for mobiles meant using different languages for the different platforms. A time when these restrictions meant porting apps and having multiple, non-interchangeable teams of developers. He told us how the first wave of Hybrid apps promised to free us from these constraints and how these promises never really delivered… and then came Ionic.
Ionic, for those that don’t know, is a framework/SDK enabling folk to quickly build hybrid mobile apps using HTML5 technologies. Ionic uses the amazing Apache Cordova tools to take advantage of device features (GPS, camera, etc) as well as enabling the apps to be built into suitable formats for submission onto the different app stores (iTunes, Google Play, etc).
With Ionic came a toolset that removed some of the pains that developers were used to when initially building Cordova apps. A focus on performance meant that apps could now be built that had native like experiences… users shouldn’t/wouldn’t need to know if apps were native or hybrid. And this is what we really like about using Ionic ourselves at MobileCaddy. With every release (and keep in mind it’s still in Beta) the performance across all platforms just keeps getting better. Have I mentioned yet that we big fans of Ionic at MobileCaddy?
A quick demo was then rolled out to demonstrate just how quick it is to get started with Ionic… and if you want to see for yourself head over here. Sani joked at how you could have a $1bn app in minutes, in a way there are real serious opportunities available.
And just then not only did the beer and Pizza arrive, but we were also privileged to have Max Lynch (one of Ionic’s founders) join us on a Hangout.
Max Lynch – A Hangout
Max mainly focused on chatting about the new and upcoming features and tools that he and the Ionic folk were working on. Most of the focus was on the upcoming Ionic.IO. He discussed how that even though Ionic was currently enabling devs to build amazing hybrid apps that there were still pain-points and a lot more that could be done. Ionic.IO essentially delivers a platform to sit alongside the actual apps. This would deliver the following types of features;
Push Notifications
Dynamic Versioning – Being able to update your app without having to go through the app submission rigmarole.
Analytics
A/B Testing
At MobileCaddy we have already started addressing some of these issues using the Salesforce platform, for example we can already do Dynamic Versioning and have taken the idea even further with a greater level of control.
Max also talked about the recent work they have done with the Crosswalk project, and how this is further pushing increased performance on Android devices. Essentially this allows you to bundle a specific version of webkit with your APK (the binary application file that is installed on people’s devices). This has the effect of meaning, as a developer, you have a known landscape when dealing with your HTML/JS/CSS, as well as of course meaning you can take advantage of newer builds and their feature sets sooner that might otherwise have been possible.
One question came up for Max about Angular 2. His reaction was positive, saying he was excited and that Ionic for Angular 2 would be on the cards. He also mentioned that Angular 2 is pushing towards a component based framework. I’ve not really looked into Angular 2 in any great detail, but this component based framework might play very nicely with Salesforce’s Lightning components. We heard about these from Doug and Skip from Salesforce at the last London Salesforce Developer’s meetup, so see our review for more information.
Ryan Hanna – Showcase
Co-organiser Ryan was next up, with the task of showing off a few apps built with Ionic, but before I get to that I should cover some of Ryan’s background. He’s a self taught developer (using Code Academy) and has only been in the game for three or so years. What’s amazing then is the fact that he’s the sole developer on his own app Sworkit, and the success that this has had… but more about that later.
Zourist
Zourist is “an audio travel Guide to World Famous Monuments, a free mobile app which provides you authentic and reliable information so that you can visit the monument at your own pace”. It is developer by Nancy Goyal using Ionic and at the time of writing has a 5 star rating on Google Play.
Sworkit
Ryan then discussed his own app, a 4.5 star app available on both iTunes and Google Play. This is a real flagship app for Ionic, with over 3m downloads covering both OSs and is available in a Lite and Pro guise. The app is available in 13 languages, and this has been achieved using the Angular Translate module. Modules like this mean that tasks like making your app available for the international market reachable without too much effort, something that will be music to multinational organisations I’m sure.
With such a large user base I was keen to find out what Ryan’s experience had been with the accessibility of hybrid apps built with Ionic. He told me that the feedback he’d gotten so far had been very positive. My understanding is that basic HTML5 good practice pays off in the same way for apps as it does for websites.
Ryan had also mentioned something called localForage, this is a library that gives you a nice API for asynchronous storage (IndexedDB, WebSQL), resulting in an interface more akin to localStorage. We could certainly introduce something like this into our CodeFlow environment.
Todd Halfpenny – MobileCaddy
I was up next, and took the meetup attendees on a speedy tour of how MobileCaddy can enable JavaScript developers to build enterprise grade, robust mobile applications for Salesforce. I’ll hopefully post the slides up shortly, but the key takeaways were that MobileCaddy enables;
JavaScript developers to build enterprise grade apps for Salesforce
(Secure) Offline, Data Synchronisation out the box
Salesforce authentication with no coding
A controlled application development/deployment lifecycyle, including OTA app updates.
We also demonstrated our Deploy to Salesforce feature for the first time.
This allows developers to deploy new versions of their mobile applications to the Salesforce platform from within the very app they are building. I have to be honest and say that I am very excited about this, and even more so about where we see this heading. Just another tool that we hope will ease enterprise mobile application development.
Richard Sands – Angular Fullstack Ionic
A late entry to the lineup, Richard give us a whirlwind tour of his new Angular Fullstack Ionic project. I think he can explain it better than I can, so this is lifted from the Readme;
The motivation behind Angular Fullstack Ionic is to streamline the development of projects that include an API, Angular webapp and Ionic app. It’s core design principles include sharing code and assets wherever possible, creating an efficient workflow and making it super easy to start off a project with handy components available out of the box (e.g. user signup/login).
It is based on the brilliant Yeoman angular-fullstack project
His enthusiasm and passion shone through, and despite the project be very young I can see that it shows potential.
Closing Notes
The event was a great success, and I look forward to seeing more from this exciting community. And I’m sure that MobileCaddy will continue to be a part of it.
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.
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 Who, Why 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.
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 HealthcareTracker 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.
We’ve heard of several folk having issues getting their Ionic powered mobile applications working offline correctly when using the Ionicons. We’ll show you 2 quick ways that should help you out if you’re having the same issue. Offline ionicons are possible, and not difficult to implement.
The Issue
When using the HTML application cache you define a list of assets to be cached locally, allowing for local serving of them. This gives you performance increases and also offline capabilities. These assets are listed under the CACHE MANIFEST header. This is the section where, if using Ionicons in your Ionic application, you could be tempted to list the following;
1
2
3
4
5
6
7
CACHE MANIFEST
/fonts/ionicons.eot
/fonts/ionicons.svg
/fonts/ionicons.ttf
/fonts/ionicons.woff
You’d then potentially use Sass to process the SCSS files supplied with Ionic and you’d soon see that your icons weren’t displaying offline.
This occurs due to the Ionic SCSS supplying a version number into a query param for the Ionicon font files.
What has happened here is that the the URLs now have ?v=1.5.2 appended to them… and this means that our CACHE MANIFEST entries will not match and our app cache will not cache them, and so our offline ionicons won’t be there. Sadly this quirk of app cache isn’t mentioned in either the pages over at w3schools.com or HTML5 Rocks, and is therefore quite commonly missed.
Solution 1 : Correct your CACHE MANIFEST
Update your CACHE MANIFEST to include the query parameters that are associated with the version of Ionicons that is being used.
1
2
3
4
5
6
7
CACHE MANIFEST
/fonts/ionicons.eot?v=1.5.2
/fonts/ionicons.svg?v=1.5.2
/fonts/ionicons.ttf?v=1.5.2
/fonts/ionicons.woff?v=1.5.2
Solution 2 : Modify the Ionicons SCSS
An alternative is to modify the ionicons-font.scss file to remove the code that inserts the query parameter. There can be several reasons to take this approach and for one of the Salesforce projects here at MobileCaddy this was just what we decided to do.
If you want to take this approach then your SCSS should be modified to look like this;
Due to us using bower to bring in Ionic as part of our development setup we also decided that instead of manually having to modify the SCSS (which wasn’t stored in out git repositories) we created a simple Grunt task to do this for us. Then we added this Grunt task into our standard workflow which meant our developers didn’t need to think about this at all. Our Grunt task looks something like this;
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
replace:{
ioniconsVsnRm:{
src:['scss/ionic/ionicons/_ionicons-font.scss'],
dest:'scss/ionic/ionicons/_ionicons-font.scss',
replacements:[{
from:'?v=#{$ionicons-version}',
to:''
}]
}
}
Using either of these approaches should help you to get offline ionicons working and hopefully assist you with creating more robust mobile applications.
We are delighted to announce this webinar for salesforce developers who want to get building offline mobile applications using the latest and greatest javascript frameworks.
We will show you how by using the MobileCaddy suite of developer tools you can quickly create a new fully ‘offline enabled’ salesforce custom mobile application and get this running on a phone or tablet in just 4 easy steps.
At the end of the webinar we will have a custom mobile app interacting with data on the platform that is fully functioning in terms of logic and data, with or without connection, that is also robust when handling dropped connections during these sync processes.
We will see how the backend package allows you to mobilise data with a few simple point and clicks. At the same time set the query parameters of the data for each ‘Mobile Table’, as well as setting the synchronisation type and failure & conflict behaviours. This will take us around 10 minutes.
Once this is complete we can then get our dev environment ready using the MobileCaddy CodeFlow setup process, again needing about 10 minutes.
Then to our application logic and get coding out the javascript needed to create a simple time and expense application complete with a custom user interface. Here we will use the bundled MobileCaddy SDK and the simple API calls to work with our locally stored application data. We will be able to test and debug this with our local CodeFlow Emulator. 15 minutes and we will be ready for the next step.
Finally we will push our pre-built application bundle to the platform and run up with our Platform Emulator and then grab a phone and run up showing the sync engine in action both online and offline.
The webinar is being held on the 10th November 2014 at the following times:
PST 10:00-11:00
MST 11:00-12:00
CST 12:00-13:00
EST 13:00-14:00
GMT 18:00-19:00
Please follow this link to sign up. If you have any particular frameworks you would like feedback on please let us know on one of our channels or pop up us an email (see the links at the bottom of this page).
