London Salesforce Dev Meetup – Jan 2015

Written by

 

lightning

Yesterday myself, Paul and Justin attended the first London Salesforce Developer’s meet-up of 2015. We had all been to many in the past but were particularly excited about this one, as Doug Chasman and Skip Sauls were presenting on the much hyped Salesforce Lightning.

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.

LonDevSFDC

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
londevsfdc

Security

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).
  • The Lightning team are working closely on getting integrations with other JavaScript libraries. These include Angular, Polymer, React, Meteor, and others.

For more information on Lightning, check out the Salesforce developer site.

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 Flash session of the West London Salesforce1 Users and Developers group, where our good selves will be among the presenters.

Ionic Beta.14 Bottom Aligned Tabs In Android

Written by

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.

IonicTabsAndroid

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.

IonicTabsAndroid

As defined in the Ionic Tabs documentation and the related $IonicConfigProvider documentation it is possible to specify a tabs.position config item. This can be done as per this code extract;

This $IonicConfigProvider is new to this latest version of Ionic and allows for a huge amount of configuration of the look and behaviour to the apps that can be created.

The change to this alignment of tabs for Android follows the other changes made in the Beta.14 release in terms of trying to follow platform specific design guides and patterns. More information on the 1.0.0-Beta.14 release can be found on the Ionic Blog.

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.

Offline Ionicons – Getting them working

Written by

ionicons-logo

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;

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 this means is that the URLs for the font files in the outputted CSS are actually like this;

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.