Spring '16 Logo

Spring ’16 – Developer Tidbits

The Salesforce Spring ’16 release is right around the corner and there are some noteworthy features for developers.  In this post I call out a few of the Spring ’16 developer tidbits and explain their significance.

Tidbit 1 – Visualforce for Lightning

Lightning Components for Visualforce were made generally available in Winter ’16 and now Visualforce for the Lightning Experience is beta in the Spring ’16 release.

Visualforce For the Lightning Experience
Visualforce For the Lightning Experience

When you edit a Lightning Experience Record Home Page, you’ll notice a Visualforce component in the list of Standard Components. This allows you to drag on to the record home page any Visualforce pages that contain standard controller for the object’ whose record home page your editing.  What’s cool about this feature is that if you have some sort of functionality in a VF section of a page layout in classic you can easily port it into the Lightning Experience. You may wish to style it differently, though, depending on the context, which leads me to the next cool tidbit…

Tidbit 2 – User’s Theme

Prior to Spring ’16 the only way to determine in what context your page was executing was to detect the presence of the sforce.one object which, technically, wasn’t 100% complete because it didn’t differentiate Salesforce1 from LEX.  Additionally, since it was a JavaScript solution you couldn’t make use of it where you would make use of controller properties or global variables in Visualforce. In Spring ’16 the $User global object has been improved with $User.UITheme and $User.UIThemeDisplayed and, in Apex there is now UserInfo.getUITheme(). and UserInfo.getUIThemeDisplayed()  The themes are defined in the documentation as:

  • Theme1 – ObsoleteSalesforcetheme
  • Theme2 – Salesforce Classic 2005 user interface theme
  • Theme3 – Salesforce Classic 2010 user interface theme
  • Theme4d – Modern “Lightning Experience” Salesforce theme
  • Theme4t – Salesforce1 mobile Salesforce theme
  • PortalDefault – Salesforce Customer Portal theme
  • Webstore – Salesforce App Exchange theme

Now we have a way to know absolutely in which context our code is running and we can do so outside of JavaScript in areas such as rendered attributes (e.g., rendered=”{!$User.UITheme == ‘Theme4d’}”).

Tidbit 3 – Unit Test Suites

Unit Test Suites are something that give us the ability to better organize our tests. They are currently available to be used in the Developer Console and also the REST, SOAP, and Tooling APIs so, hopefully, if they aren’t already, they’ll soon show up in other tools.

Unit Test Suite

Unit Test Suites give us the ability to organize our tests into meaningful higher level groups. For example, there might be a suite for running tests related to Community code in your org, a suite for testing a custom coded pricing app, or others. You might have a smoke test suite that you run on sandboxes after refresh. If organized correctly, it also gives a self-documenting guide to functionality for new devs. If someone wants to learn about the code associated with communities, they can go to the Community Test Suite and run and look at the well-named methods and various classes under test in the suite.

Tidbit 4 – Set Created Date in Unit Tests

Yes. This is here! There is a very highly voted question on the Salesforce Stack Exchange about how to set the created date in unit tests. There are answers that use JSON serialization and Test.loadData and now there is one that uses Test.setCreatedDate(Id sObjectId, Datetime createdDateTime).  Note that it can’t be used in SeeAllData=true tests.

Sometimes you might have code that executes conditionally or otherwise based on whether or not a record was created within a certain time period (e.g., all records created more than a week ago that have not been modified since).  In the past that type of code was harder to test. With this new method it is much easier.

Tidbit 5 – Sandbox Post Copy Script

You can now specify an Apex class to be run after a sandbox has been copied. It must be global and implement the SandboxPostCopy interface which has a single runApexClass(SandboxContext) method.  I haven’t worked with Sandboxes in a couple of years, so I have yet to play around with this to see its full capabilities, but there are a ton of different use cases — environment specific configuration changes (e.g., call out end point urls and credentials), data alteration (e.g., email addresses), and possibly quick data creation or data validation. I love this feature, because lists of manual post sandbox refresh steps can hopefully be whittled down to near nothing and replaced with intelligent automation.

Tidbit 6 – New Apex Site Class Methods

There were a few new methods added to the Apex Site Class. The two that I thought were the most interesting are  Site.isValidUsername(String username) and Site.validatePassword(sObject User, String password, String confirmPassword). The isValidUsername method is useful because now our custom pages for user management can easily detect whether the newly entered user name is valid without hard coding some validation logic against an entered string or without waiting for a DML operation to fail.  The validatePassword is really nice, since different password policies may exist depending upon what is configured. Like with the isValidUsername, we no longer have to rely on hard coding or waiting for the Site.changePassword method to not work.

More Spring ’16

I’ve shared 6 interesting developer features in Spring ’16 and why I find them particularly interesting. There are many more interesting features for developers.  I encourage you to take a look at all of the Spring ’16 resources and release notes, get a pre-release org, and check out the Maintenance Calendar at trust to get a full picture of the Spring ’16 maintenance release dates.  If you want to hear me go into more depth on some of these feature and a few other ones, check out my Developer Group presentation.