Month: April 2015

General

Streams of Lightning. A Simple Lightning App Part One

| sudovi

Ever since Dreamforce 13 and the announcement of Salesforce1 I’ve been itching to get at some mobile dev. I couldn’t wait to get started on it when we returned. However my excitement dwindled when I realized that there was very little one could do from a development standpoint with Salesforce1 at that point. Fast forward to Dreamforce 14 and the announcement of Lightning Components. The fire was once again lit.

Today I begin my first tutorial in creating a simple lightning application. But first a bit of a disclaimer. I’m doing some things “wrong” and have every intention of coming back and cleaning up afterward. (And a few things may go awry as I remove bits of code that I want to present later but will do my best to not break it).

We will be building a simple Poll application that will allow you to present a question to your users. Each question will have a group of answers that can be voted on. In the end we will plug the whole thing into the streaming API so that as people vote, the results are updated in real time right in Salesforce1. (This is the part where you say “oooooohhh, aaaaahhhh” — it makes me feel better).

Coming in the Summer 15 release is the Lighnting App Builder. We will build a very simple component and make it available for use with this new feature.

For this tutorial you will need a developer org that has Summer 15 features. (Currently only available as a pre-release org), and a familiarity with HTML, CSS and Javascript. I don’t even understand it all 100% yet, but I’m getting there. (I won’t tell if you won’t…)

First, admire the beauty that is Lightning App Builder (we won’t “use” it yet, but I just want you to see it and notice whats available).

  • Click on Setup->Lightning App Builder
  • It will give you a brief intro screen
  • Clicking Next will prompt you to select a layout. This is a simple test app so I kept it simple and chose the 1 column layout.
  • Clicking Next will ask you to give it a name. I call mine Poll of the Moment.
  • Clicking Next brings you to the App Builder itself

Along the left hand side is a list of pre-made components. At this point in time there appear to be 5 “Standard” components: Filter List, Recent Items, Report Chart, Rich Text, and Visualforce. For this demo however, I wanted to see something completely custom so I didn’t choose any of them and therefore won’t cover them here.

Underneath that area is the place where you’d find any custom components you write. THIS is what I wanted. Below that is the Custom Managed area, I’m assuming this is where any third party components you install from the app exchange will appear.

For now just click Back to Setup. We want to figure out how to get a simple custom component to appear in that list. I will show you how to do that.

We will need to use the Developer Console to create our Lightning Component. If you’re not familiar with how to get there, click on your Name and choose Developer Console. A new window should open up and this is where we will write our code. In the new window select File->New->Lightning Component.

  • A small dialog box will pop up asking us to name the component. I called mine “PollItem” (notice the case and no spaces. I believe you aren’t allowed to have spaces in your names, so using a “camel case” makes it at least easier to read). Enter a description if you want to, we’re used to entering descriptions for everything right?
  • Clicking Submit will open a couple tabs in our console.
  • Click on the tab labeled “PollItem.cmp” — you will notice that it has already populated some minor code for us.

The tags that it created should look something like this:

<aura:component >

</aura:component>

For part one of this example we will keep it very low key and simple. Lets add a heading.

<aura:component >
    <h1 style="text-align:center">Poll of the Moment</h1>
</aura:component>

With this, it isn’t much and isn’t very useful, but it *is* a new component. Albeit its always going to have that title, not be interactive at all and completely boring and useless. Matter of fact we can’t even use it in the App Builder yet. If you were to save this and hop over to App Builder, it would not yet appear in the Custom Components area. We are going to remedy that right now. Lets get it ready for Lightning App Builder, that way we can add it to an app, view it in Salesforce1 and then begin writing code so we can see how what we write affects our app in SF1.

In order for our component to be available to to the App Builder, we need to tell Salesforce where this component can be used and the type of component it is. This is done with a very simple declaration: implements=”flexipage:availableForAllPageTypes” — so now we should have:

<aura:component implements="flexipage:availableForAllPageTypes" >
    <h1 style="text-align:center">Poll of the Moment</h1>
</aura:component>

While we are at it, lets make it so that our admin can title the page whatever they want. This will be done by creating an aura:attribute tag to hold the title of the page that the admin is going to type in when they configure the component in App Builder. But first, an aura:attribute is like a variable for components. They will hold values that can be retrieved or set within the component. Since we are creating a title for this component lets just call it “title” and will be string of characters:

<aura:component implements="flexipage:availableForAllPageTypes" >
    <aura:attribute name="title" type="String" />
    <h1 style="text-align:center">{!v.title}</h1>
</aura:component>

Now that we’ve added just a simple touch of interactivity so that the admin can specify a title, we need to tell the App Builder which properties are available to be set via App Builder. This is done with a new component type called a design. You’ll notice on the far right side of the developer console there is a menu. Make sure you are in the PollItem.cmp tab and click over on that menu on the Design button. This will open a new tab automatically called PollItem.design and will look like this:

<design:component>
	
</design:component>

We need to tell App Builder about our Title field that the admin will be able to set. We do that like so:

<design:component>
    <design:attribute name="title" label="Title" Description="Title for the component on the page" />
</design:component>

Before we hop back over to the App Builder, I want to point out one of the things I’m doing “wrong.” You will notice that I have some style tags in some of my markup. I prefer to work this way when developing so I can affect just the pieces I need to. Once happy with my styling and going production ready, any inline styles I’ve created will be ripped out and placed in the Lightning Component’s CSS file.

Save your files and hope back over to the App Builder. Choose the single column layout as you did earlier in the tutorial, give it a name, (Poll of the Moment sounds good). You should now see your custom component in the App Builder listing. Drag it to the panel in the middle of the App Builder screen. You will see our Title field become editable on the right hand side. Enter a title for our page. (Current Poll works). Lastly click Save and then click Activate. A final dialog will pop up allowing you to give the Salesforce1 menu option a name for the app. It should default Poll of the Moment (if that’s what you entered a few minutes ago).

Fire up Salesforce1 and when you go to the main menu under the Apps section, you should see your new app. Tap on it and bask in all your glory. You’ve just added your first app to Salesforce1 using the App Builder and Lightning components.

Up next, we’ll create our Poll Object and Options and display the latest one on the screen for our users to see. We still have to add the capability to vote, and finally tie it to the streaming API for a nice finishing touch.

Until next time — I’m out.

:wq!

Fun, Lightning Components, Salesforce, Trailhead

Trailhead Lightning Module is a Major Charge!

| sudovi

If you haven’t heard about Salesforce Trailhead by now, allow me to help you out from underneath that rock (I kid because I care).

Salesforce Trailhead was launched at Dreamforce ’14 and if you haven’t tried it out yet, its incredibly cool. I’ve been in a number of different communities and aside from Python/Django (who gets an A for effort), nobody has such a great intro to a platform. Salesforce Trailhead is heads and tails above any “tutorial” for a learning a platform anywhere.  Its professionally put together, it quizzes you on what you’ve learned, it connects to your development org (it helps you set that up too) and keeps track of your progress, and actually rewards your progress along the way with fancy badges.

You can start at the beginning and work your way through the platform or you can pick and choose modules at will. Originally I was going to walk through module by module but since I have the attention span of a gold fish and like to jump right into shiny things, I quickly finished my first module so that I could jump into Lightning Components. I’m not quite finished with it yet, but I’ve made it through 69% of the exercises and already have greatly improved my initial grasp of the concepts. (Three more to go and I get my badge!)

If you’re not quite sure what Lightning Components are, its basically the next step in Salesforce development. Its really more of a framework made up of re-usable and extendable UI components that you can use to work with your Salesforce data. These components can hold other components and they can be extended to create custom components that work on the Salesforce1 platform. At DF14 when they were announced you could only write Single Page Applications, but will soon have the ability to extend existing Salesforce1 screens. They’re javascript based on the front end and use an MVC type of approach to building the UI. That javascript then talks to Apex on the Salesforce side.

Back to trailhead: The Lightning Components module starts out with your basic Hello World application and gets you on the ground running right away. The challenges aren’t so difficult that one wants to just toss it out, but they also leave you with plenty of room to stretch your own ideas and play some “what if” scenarios. (Actually my last unit was on the event handling and when I was done I tried to run the example and had some unexpected results, but with a little poking I was able to figure out how to get it functioning. As it turns out, the next chapter was going to cover what I’d just done (…its like they read my mind!)

The module moves on to creating a “reservations” type application where you create a form where users can “register for an event.” So its an completely relatable topic as well. Often times some examples on other sites are so out there, and so “basic” that you really don’t learn much. Not the case here. I’m not sure how they did it, but whatever it is they did, they did it right.

You can tell these modules are put together with a well thought out execution plan. The lightning components module especially seems to have most definitely been put together by developers for developers, but yet they are simple enough that even non-developers can jump in and start exploring (though some knowledge of javascript is probably advantageous).

Trailhead itself keeps you coming back as well. The gamification concept with the badges makes you feel like you are getting somewhere. While I haven’t scored by Lightning Components badge yet (I do have a job ya know…), its the desire to have that little logo on my profile and the ability to tweet my achievement out to the world that keeps me driving forward, all the while tricking me into learning something. How dare they teach this old dog new tricks! :)

In a world that is quickly going mobile, Salesforce is poised to lead the way and learning Lightning Components will put you at the forefront of this tidal wave. So grab a surfboard and paddle over to Trailhead and prepare yourself for the future.

I’d love to help you along the way if I can, so if there is something you’d like me to try and/or talk about or do a “deep dive” on, let me know in the comments.

:wq!

Coding Methods, General, Salesforce

Testing Tidbits

| sudovi

Today I’m going to talk about two of my go-to “tools” (for lack of a better term) when it comes to testing functionality in any Salesforce org that I do work in. I don’t always do these things…(but when I do….*never mind*) though I’m starting to do them more often and its been working for me.

The first of these items also comes up often in the #salesforce IRC channel as well and its been talked about in many places but I see this brought up so often that its probably a good idea to mention it yet again.

Use Hierarchy Custom Settings to “short circuit Validation Rules, Workflow Rules and even Triggers. (If you aren’t sure what Custom Settings are or what they do, then watch this video[1]). These are very valuable not only for day to day operations, but also in my unit tests. The idea for unit testing is to test small chunks of functionality. Sometimes things like Validation Rules can get in the way of that. If you’re testing a bit of code that operates on an opportunity, but that functionality doesn’t care whether or not certain fields are required, use the Custom Setting to turn off the Validation Rules that would fire so you don’t have to populate a bunch of fields that you aren’t testing/don’t care about.

For example lets say we have some validation rules in place that ensure a specific group of fields are filled out on an opportunity. Further more, lets say that we are testing a trigger that will create some child object(s) when that opportunity is created/updated, etc. If all we really want to test is whether or not that trigger works when an opportunity is inserted, why run validation on that opportunity? (Unless of course those child objects depend on these fields, lets assume they don’t for now). If our Validation Rules have the short circuit in place, our test code can turn them off in our test to ensure we don’t get errors. This is also valuable because IF we are breaking our tests down into small bite-sized chunks, when someone comes along later and adds a Validation Rule it won’t break our test. (Again, this will assume those creating the Validation Rule are inspecting our Custom Setting first, so it will take some cooperation). So lets say we have a Custom Setting called Admin Settings and a checkbox on that custom setting called Run Validation Rules. In our test setup, or in the test itself we can simply do this:

Admin_Settings__c settings = Admin_Settings__c.getInstance();
settings.Run_Validation_Rules__c = false;
insert settings;

Now when our test code runs the Validation Rule will be skipped. If we get in the habit of doing this for all of our Validation Rules, Workflow Rules, etc. then we can keep things pretty clean and not so brittle. Its never a nice surprise when you go to deploy a changeset and tests start failing because someone added a Validation Rule in production! Of course there are times when you are testing larger chunks of code or functionality and you’ll want to ensure that these rules run. In that case, instead of setting Run Validation Rules to false, just set it to true and you should be good to go.

You can also use this short circuit in triggers by creating another checkbox field on Admin  Settings called Run Triggers and in your trigger inspect that field to see if its true or false:

Admin_Settings__c settings = Admin_Settings__c.getInstance();
if(settings.Run_Triggers__c == true) {
    doIt();
}

You could even get really specific and create custom settings for different objects. Maybe don’t want to short circuit all VRs or WFRs. You could get more specific with fields like: “Run Opportunity Validation Rules” etc…

The second tidbit isn’t necessarily Salesforce specific as you can use this all over the place. I was actually surprised by the number of people that didn’t know you could do this so that’s why its here.

Take advantage of Gmails flexible email addresses.  For instance, if my email is thedude@ihatetheeagles.com, I have several ways that emails can be addressed to me:

  • thedude@ihatetheeagles.com
  • the.dude@ihatetheeagles.com
  • the.d.ud.e@ihatetheeagles.com (etc)
  • thedude+test1@ihatetheeagles.com
  • thedude+myappname@ihatetheeagles.com (etc)

You get the idea. I’m not sure if other email services allow this and if so great, use them. I use them to have unique email addresses on my test users/contacts etc but still have all messages come to my email address when testing. You could potentially use this as a form of getting a stream of messages on a per-app basis and applying a filter in gmail to automatically archive/apply label to messages coming in to thedude+myapp1@ihatetheeagles.com to have groups of messages filtered out by app. If I’m doing a ton of testing and messages that are coming to me are coming from different areas of the app, I can use these addresses even to figure out what app, what part of an app, etc the messages are coming from.

What are some of your favorite goto nuggets for testing, or anything for that matter? As always if there is something you perhaps want me to deep dive on, let me know in the comments.

P.S. I actually love the Eagles…

 

[1] video found on youtube, author: Shannon Hale (@shannonsans)

:wq!

 

General

My Top Five Parodies for Salesforce

| sudovi

I  get asked quite a bit what song is coming next. I’ve helped others write several parodies of existing songs and while I don’t generally perform the parodies, here is a list of what I have coming up next. I may or may not be performing them on my own, but we’ll see:

Top 5 Salesforce parodies in the works:

5) You’ll Be a Closed Opp Soon (Girl, You’ll Be a Woman Soon)

4) Valdiation Rules (California Girls — Katy Perry)

3) Ben-i-off (Shake it Off — Taylor Swift)

2) I Only Added One More Rule (Only Wanna Be with You — Hootie & the Blowfish)

1) It’s Friday, Lets Deploy (It’s Friday I’m in Love — The Cure)

I was so excited to do the It’s Friday, Let’s Deploy that I couldn’t wait to do it, so without further delay: enjoy!

 

:wq!