Salesforce development struck by Lightning

One of the biggest bombs Benioff dropped (say that 5 time fast!) at Dreamforce 2014 this year was Salesforce1 Lightning:

salesforce1 lightning

 What theblue-lightning-hi is Lightning?

Not unlike the announcement of Salesforce1 at last year’s Dreamforce, Lightning has a lot of marketing hype and ambiguity.  This is due mostly to the fact it includes a suite of products.  However, also like Salesforce1, there is a piece of the offering that stands WAY out as the most important.  When all the dust settled around Salesforce1 it was the mobile experience that proved to be the real offering.  With Lightning it is going to be the new component framework, essentially the next generation of Visualforce, that is the real crown jewel.  The schema builder, process builder, and lightning connect are all awesome, don’t get me wrong, but they have been around in one form or another for awhile, and are just incremental innovation with rebranding.  The lightning app builder is also awesome, but it is just a tool for implementing the component framework in a WYSIWYG fashion.

New component framework?  What about Visualforce?

Well, what about S-Controls?  The one sure thing about technology is it is outdated as soon as it is released.  S-Controls made way for Visualforce.  Visualforce has had a long run in the life of development, but is really starting to show its age.  In recent years ISVs and customers have had to deviate more and more from the strict Visualforce components to meet their requirements.  JavaScript frameworks have been creeping into Visualforce pages to the point where Visualforce tags are becoming a minority of the code in a page in many cases.  Controller extensions, viewstates, page refreshes and synchronous processing are victims of attrition.  They are being turned into museum pieces by more efficient user interfaces using JavaScript remoting, static methods, stateless behaviors, asynchronous processing.  Technically this is still a “Visualforce Page”.  But the composition of that page looks very different today then it did say 3 years ago.

Ok…  So, still why not keep using Visualforce?

Square Peg in a Round Hole_0565

In 2 words:  Mobile and Wearables.  Visualforce was designed for desktop computing with relatively fast, hard-wired network connections, large displays, and a full-fledged human interface devices.  Salesforce1 was a huge leap forward in addressing the needs of mobile computing.  But it left a gaping hole which developers had to attempt to fill as best they could.  Developing Visualforce for Salesfore1 is not an amazing experience.  Sure they threw us some bones like  But the architecture and styling just felt like a square peq in a round hole.  It doesn’t have that desktop Visualforce / Apex, Peanut Butter / Jelly meant to go together feeling.  Put another way, the Salesforce1 deficiency was the ability to create Salesforce1 mobile experiences in the same way salesforce created them “out of the box” on the Salesforce1 mobile app.

Salesforce1 Lightning to the rescue!

For sure the Visualforce pages of enterprises across the world will continue to be read and write data from and to the salesforce orgs they live in for years to come.  But no longer will Salesforce1 mobile app development have to feel like desktop shoehorned into mobile.  The beautiful, mobile, standard page layouts of Salesforce1 will flow more gracefully into custom Lightning apps.  <ui:button> will magically be the right button for Salesforce1 without needing to disguise <apex:commandButton> for the job.  Developers won’t be forced to go to other JavaScript frameworks every time they want to do something on the client side.  In a nutshell, Lightning allows us to go back to developing in a more streamlined “Visualforce-esque” manner, while still being able to leverage the latest technologies of the server and perhaps more importantly, the client.

Will the legacy desktop user interface go away?

I don’t know.  But there will definitely be new apps created with Lightning in a responsive fashion to work seamlessly across desktop, mobile, and wearable devices.  This is at least the start of a shift towards one UI to rule them all.  The {!$Browser.formFactor} global variable will let developers slightly customize their apps to work best on different devices.  One app customized for all platforms is much easier to maintain than a Visualforce desktop codebase and a Lightning Mobile / Wearable codebase.  The trick is doing it in a way where the experience isn’t compromised on any device.  This is hopefully where Salesforce will come in and handle the the lightning elements in different fashions depending on whether the Lightning app is run through the Salesforce1 mobile app on a smartphone, or through the desktop.  For example, a data grid that is smart enough to render differently for large vs. small screens without the developer having to handle that.  This also helps developers to “future proof” their code since salesforce provides an abstraction layer which they maintain so your app always works well on the latest devices.

Advice to other Developers

You need to have at least intermediate level JavaScript experience.  If you don’t have it, get it.  Read a book, take an online course, or just google your way through some complex JavaScript projects.  Don’t focus just on standard JavaScript syntax, but frameworks like jQuery, various patterns, CSS and the DOM as well.  JavaScript is going to become a KEY skill for salesforce developers (it already is in many cases).  This will not only improve your ability to crank out hybrid Visualforce pages, but it will also make the move to Lightning less of a shock.  It will also position you well to be create interesting new projects on Lightning vs. being stuck a role maintaining Visualforce…  And we all know building new things is more fun than maintenance.  🙂

Salesforce1 Lightning Resources

Adding Reports to Salesforce1 with jQuery Mobile and the Analytics API

Salesforce1 comes with nice dashboards built in, but no reports!

This is somewhat understandable.  Dashboards are already fairly mobile friendly while reports can be quite unwieldy, even on a desktop experience.  The number of rows and columns and the controls needed to manipulate them are not trivial to implement on a small touch screen.

It is, however, possible to attempt to build this functionality yourself with the Salesforce Analytics API and whatever User Interface you wish.

Arun Varadharajan, Product Manager for Salesforce Analytics has put out a nice, simple example of how to do this:

Check the link in the tweet to see his GitHub repo.

This example is cool because it uses no apex controller.  It is all done in VisualForce and JavaScript.  It renders with the Google Charts API, to make something that looks like this:


However the Google Charts API isn’t all that mobile friendly.  And this example provided no method for choosing which report to display.

I decided to look deeper to push this solution further ahead for the salesforce community.

My Contribution… sf1Reports!

sf1Reports uses the latest jQuery mobile framework to create a mobile-friendly report search and render experience.

The search uses JavaScript Remoting and SOSL to return the results as you type. It searches all your reports you have created in your salesforce org:


You can choose 2 modes to render the report.  Reflow or Column Toggle.

See these links for more info:
jQuery Mobile 1.3.2 Docs – Table Reflow
jQuery Mobile 1.3.2 Docs – Table Column Toggle

Reflow mode will look like a standard table when the columns fit on the screen, or will collapse the rows down into a block of label/value pairs when they don’t fit on the screen.  Reflow mode is good for looking at the report data one record at a time, but not as good for comparing the records to each other:

Column Toggle mode lets you select which columns you want to display, so you can fit the relevant columns onto your mobile screen:

Installation Instructions

Grab the files from my GitHub repo: .
Deploy the 2 classes and 1 VisualForce page to your salesforce org. I didn’t package them, but they are easy to deploy with something like the IDE.

Enable Salesforce1 in your org:

Make sure the mobile checkbox is checked on the VisualForce page:

Make a VisualForce tab for the page:

Add it to the mobile navigation:

Navigate to https://<your instance> by manually entering it in the URL bar.  It will change to your visualforce domain which will look something like this: . Copy the visualforce domain portion of the URL as seen below.  You will need to paste it into the next step.

Take your visualforce domain, and add it to remote sites.  this is because we will be calling the rest API:

Final Notes

This is just v1.0.  It obviously is just a crude start, but it has potential.  Feel free to contribute to make it better.

It only supports tabular reports currently.  Summary and Matrix could be added with some more work.  I use the JSON Parser to blast through the Analytics API response.  That data is fairly complex, so I chose to iterate over the JSON rather than try to deserialize it.  There would need to be some thought as how to convert the JSON for Summary and Matrix reports to corresponding apex and ultimately HTML elements.

I chose a flat listing of all reports that is searchable by SOSL.  This seemed like a good mobile-first thing to do.  If desired, navigation through the report folders could be added.

It might make sense to make some mobile versions of reports in salesforce with a naming convention which have fewer columns and rows.

I noticed that the iOS Salesforce1 app would crash sometimes.  The Dreamforce 13 app also crashed in a similar manner, so I don’t know if it is a problem with my app or not.  Sf1reports didn’t crash which running it in a browser on my desktop with the /apex/sf1reports URL or the /one/ URL.  Hopefully Salesforce1 proves to be a reliable container for our custom VisualForce apps and this isn’t an indicator of a larger problem.

If you need report data on to go, it might just solve your needs!