In a world where developer and admin workforces are commonly remote and often working on many features that are to be bundled into larger releases the idea and practice of continuous integration is one that can deliver real results for quite minimal investment.
There were two speakers due to talk on the matter, so rather than I spout on about the topic myself I’ll cover their presentations as best I can.
Klea Kolaric – Using Bamboo to enable CI
Klea is a technical consultant at a Salesforce implementation partner and talked about how they are using Bamboo within their CI workflow at the company. Bamboo is a CI and Build Server tool from Atlassian (who also make the Confluence and Jira tools).
Klea started off by talking about the options for deploying to Salesforce; Using Changesets, an IDE or CI tools. She listed the pitfalls of the first two options and how the CI route removes a lot of risk from human error as well as giving huge speed improvements.
Using tools such as Bamboo you also get a nice controlled process for rolling back deployments, useful if something goes wrong (as it sometimes does). Another big benefit, in my eyes at least, is the auditing ability that tools such as Bamboo can give you. Klea told us how you get the important Who, When, Why, What and How information through Bamboo’s great integration with the other tools in their toolset. Essentially commit messages from Bitbucket and issues from Jira are all linkable if provided.
One handy tip, that might just save you from a major head-ache might be to not set deploy to production variables by default. Klea has her setup such that if she accidentally runs her deploy process, then the automatic parts will only run a validation build; for her to run an actual deploy to production she has manual steps that need to be fulfilled.
Sebastian Wagner – Multi Orgs and using Git for CI
Sebastian, a freelance Salesforce Certified Technical Architect was the next and last speaker for the evening. His talk covered how and why Git and CI techniques and tools can be used in Salesforce development. His talk covered some of the same ground as Klea’s but was less Bamboo-centric; again he covered some of the issues that can be resolved (or at least reduced) by using CI, but he also mentioned non-Atlassian tools such as Github and Jenkins. Here, at MobileCaddy we’re using both Atlassian and non-Atlassian tools for our CI. The tools are similar but certainly some are more suited (and free) than others.
There was a lot of content in Sebastian’s slides, and for those that want to dig in he has kindly published them here. One of the key points that was mentioned but I think is worth picking up on is the use of a good git branching model. Sebastian mentioned the GitFlow model which Atlassian have brilliantly written up. I first came across this kind of model through the excellent post by Vincent Driessen called A successful Git Branching Model. Even though this was posted by him over 5 years ago it’s worth a read for sure.
On Continuous Integration: if you’re not doing it, start… today.
On the event: This was the most attended meetup to date I believe and shows how the community is going from strength to strength. I did note though that there were at least 70+ blokes in the room, and less than 5 ladies. I tweeted this and got a reply from April Kyle Nassi (Developer Community Manager at Salesforce) and as you can see in this conversation it looks like there are steps at least to improve this. It also turns out that there was a Women Who Code event on in London on the same night, and this could certainly have played a part.
As usual there was a full supply of beer and pizza, so thanks again to the sponsors.
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;
Dynamic Versioning – Being able to update your app without having to go through the app submission rigmarole.
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.
(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.
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).
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.
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.
The meetup was hosted for the first time at the dotmailer offices near London Bridge, they provided excellent facilities which were matched only by the quality (and quantity) of pizza and beer supplied generously by the kind folk at MakePositive. So big thanks to both companies.
Doug and Skip (though mainly Doug, as Skip had laryngitis!) talked and demo’d us through the history of Lightning, the architecture of Lightning Component, some examples and a look into the future to see what’s on the roadmap. There was a lot of information passed on, and I have to be honest and say I don’t want to (or maybe can’t) regurgitate it all here… but I will cover what I seem to believe are the main nuggets that got me thinking.
Lightning and Aura
Before Lightning became available to developers Salesforce had been using it internally for sometime.
In fact SF1 is built using Lightning.
Lightning is also known as Aura. Salesforce’s marketeers didn’t want to call it Visualforce2
Aura is Salesforce open source UI framework, and can be found on github here.
Anyone out there can contribute to Aura through Pull Requests, and with that their work will end up inside Salesforce and powering Lightning.
Aura/Lightning is built by the same team that built Visualforce
Doug also covered (many times) the fact that trust and security were high priorities… obviously that was great to hear. This eye on security has meant a couple of things. 1) lightning components (on the platform) live on a lightning domain. 2) Communication to/from the client/server parts of Lightning components is locked down. This point was one of the very few “guidances” that is put on how components are used.
Here are a few other points on Lightning;
There will be a Component Exchange, a-la AppExchange
The client/server comms are called Action Services. There are options to box car calls as well as other behaviours (display-last-known-good, auto-refresh, etc).
Offline capabilities are limited to read at present. Create and Update are on the roadmap (no dates given).
BIG SAFE HARBOUR – Summer ’15 should see the ability to put Lightning Components inside Visualforce pages.
As well as Lightning Components being available for use in Visualforce pages, Lightning Out will also enable Lightning components to be used within other containers (websites, etc).
All-in, the session was excellent. Both guys showed passion for the platform and certainly for Lightning. If you get a chance to see them talk then I’d definitely recommend it.
Big thanks to Anup and Co. for another brilliant meetup.
Want More Salesforce?
If you have a thirst for more Salesforce goodness then come along to the Create Mobile Solutions in a Flashsession of the West London Salesforce1 Users and Developers group, where our good selves will be among the presenters.
Following the v1.0.0-Beta.14 upgrade you might have noticed that, when running on an Android device, your applications tabs are now aligned to the top of the screen rather than the bottom. If you’d like to have it so that you still have bottom aligned tabs then you need to specify an extra line of config. We’ll detail here what you need to do, and give you some background (and links) as to why this change has occurred.
Ionic Tabs : Android / Ionic 1.0.0-Beta.13
Here you can see the tabs are at the bottom, just as with iOS.
Ionic Tabs : Android / Ionic 1.0.0-Beta.14
And here you can see the tabs are at the top. This is how tabs will look on an Android device by default.
We have put together a quick CodePen of this in action. It was forked from Ionic’s CodePen for tabs, based on their nightly version so should be up-to-date. To see it in action, as if you were on an Android Device then you can use Google Chrome’s Device Mode to emulate it. To see how the tabs look before the extra config, then do the same with Ionic’s vanilla codepen.
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.
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;
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.
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;
Using either of these approaches should help you to get offline ionicons working and hopefully assist you with creating more robust mobile applications.
The event kicked off with a small pitch from dotmailer, something which I’ve come to expect from meetups and events like this. I can’t begrudge them too much, floor space in the city certainly doesn’t come for free.
Peter Ransom : The Officers’ Association
Up next was Peter Ransom from The Officers’ Association. The OA promote the welfare of those who have held a commission, in HM Armed Services, and their families. Peter gave an enjoyable and informative walk-through of their Salesforce implementation project It included info on why they chose Salesforce in the first instance, some of their results and some lessons that they had picked on their journey. Before starting their integration project they ran a very paper-based business, with desks piled high with folders and stacks of paper… not the most efficient setup in this day and age. Peter highlighted the following results of their implementation;
70% reduction in printing/photocopying costs
30% reduction in administration costs
As well as talking through some of the architectural decisions Peter also ran through a set of ‘lessons learned;
Ensure good communication with end users. Assumptions from management aren’t always true and if end users are involved at an early stage then they tend to feel they also ‘own’ part of the project, and this can greatly help in removing friction and increase acceptance of change.
Set aside enough ‘snagging’ time. There will always be things you overlook.
Regularly review requirements. Peter said there project used an agile-esq approach and this review of requirements was useful.
Ensure SFDC knowledge is up to date.
Justin Halfpenny : MobileCaddy
Our CEO, Justin, was presenting the second talk. This was entitiled Delivering Enterprise Mobility. It was as much about getting the audience to ask themselves about their own views on Enterprise Mobility as it was about anything else. You need to start thinking about some of the issues that are fundamental to delivering an excellent mobile offering, but are often forgotten about when the journey begins. The earlier you’re aware of what factors and pitfalls are present in the mobile ecosystem, the better. People tend to be focused on getting an app up and running, but thinking about it’s lifecycle is equally, if not more, important. How does it work when offline? What happens when the organisation purchases new devices? What happens when the OSs upgrade automatically?
Justin started off by addressing these 3 questions;
The Who? deals with who are we talking about? Who is mobile and which organisations can take advantage of the move to mobile? The Why? asks what is driving organisations to embark on a mobile strategy and the How? focussed on how to start and how to make it work? Theslides can be found here.
Kevin Bromer : NGO Connect Roadmap
Last up was a remote presentation from Kevin Bromer, a Solutions Architect at the Salesforce.com Foundation. This was focused on NGO Connect and the NFP Starter Pack. To be honest the content was somewhat dry and I had really hoped for more. That’s not to say that what you get with NGO Connect and the NFP Starter Pack isn’t pretty amazing, I think it is, it’s just that demoing the standard Salesforce UI is a bit underwhelming. If you’re interested then I suggest you head over to SalesforceFoundation.org to find out more about both products.
Many thanks go to Julia and Faith and dotmailer for hosting, and the Salesforce foundation who funded the nibbles and drinks. There have historically been about 3 events a year, so keep your eyes peeled as I recommend going to one.
When running up an app built with the Salesforce Mobile SDK there is an option to login to a custom domain. This is useful when testing against a sandbox or developer environment. The option, when running on an Android device, is accessible via the Change Server menu item which is available via the hardware menu button.
The issue comes though if your device doesn’t have a hardware button… what then?
If an acceptable option for you is to have this custom domain hard-coded (so that it cant be changed) then you can modify some code to use your defined custom domain as the default. It is as easy as replacing a single line in one file… so let’s have a look. In the below I have commented out one line and replaced it, and in my example I’m setting the default domain to https://test.salesforce.com (as in my case I’m testing against a sandbox environment).
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.
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.
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.