Sunday 20 August 2017

WITNESS SUCCESS - Women in Tech



WITness Success is the event to celebrate success of women. in Salesforce

Its goal is to Empower, support and invest in Salesforce Women in Tech user group members & leaders with a 1 ½ day event. Attendees will learn, network, grow & ultimately excel in their Salesforce careers, be role models and mentor others.

Yesterday, i attended this event in Noida organized by Noida and Gurgaon Salesforce group.

This was indeed great opportunity to learn Salesforce and meet with other girls. Shared our experiences, knowledge and challenges we face in IT industry.

This is again a very good event to praise women success in IT. I hope to have more event like this in future.





Thank you to the entire WITness Success planning team for putting together such an event. You are the reason why the Salesforce community is so great!

Monday 14 August 2017

Singleton Design Pattern

Singleton design pattern is the simplest design pattern in Apex. By using this pattern we can initiate class instance only once.

The Singleton pattern attempts to solve the issue of repeatedly using an object instance, but only wishing to instantiate it once within a single transaction context. It's most common use is to create an object instance that's instantiated only once for the lifetime of that execution context. 

The Singleton design pattern allows Apex code to repeatedly reference an object instance in an optimal manner, whilst mitigating the impact of governor limits.

Problem:- This is one example of inefficient code where developer is initializing class every time  new record is getting inserted in contact object. This will cause an error when we try to insert more than 100 records.

Trigger

trigger AccountTrigger on Contact(before insert, before update) {
for(contact record : Trigger.new){
ContactFSRecordType rt = new ContactFSRecordType ();
....
}
}

Class

public class ContactFSRecordType {
public String id {get;private set;}
public ContactFSRecordType (){
// This could breach the governor limits on describes
// if a trigger is executed in bulk
id = contact.sObjectType.getDescribe()
.getRecordTypeInfosByName().get('Foo').getRecordTypeId();
}
}

Solution
  • Creating a class with a method that creates a new instance of the class if it doesn't already exist
  • If it already exists, then simply return a reference to that object

Trigger

trigger ContactTrigger on Contact(before insert, before update) {
for(Contact record : Trigger.new){
// Instantiate the record type using the singleton class
ContactFSRecordType rt = ContactFSRecordType.getInstance();
....
}
}


Singleton Class

public class ContactFSRecordType {
// private static variable referencing the class
private static ContactFSRecordType instance = null;
public String id {get;private set;} // the id of the record type
// The constructor is private and initializes the id of the record type
private ContactFSRecordType (){
id = contact.sObjectType.getDescribe()
.getRecordTypeInfosByName().get('Foo').getRecordTypeId();
}
// a static method that returns the instance of the record type
public static ContactFSRecordType getInstance(){
// lazy load the record type - only initialize if it doesn't already exist
if(instance == null) instance = new ContactFSRecordType ();
return instance;
}
}
In order to implement a Singleton pattern in Apex, the class must instantiate only a single instance and be globally accessible. It is implemented by:
Some important points from above example:- Constructor should be private so that it can not initialized outside getInstance
method. 

getInstance method will only initiate instance of class if it does not exist
The class defines a private, static instance of itself that can only be referenced
via the getInstance() static method.

The ID member stores the record ID of the record type and is initialized in the
constructor.

Reference

https://developer.salesforce.com/page/Apex_Design_Patterns

http://www.tgerm.com/2010/03/apex-implementing-singleton-design.html

http://www.oyecode.com/2012/12/implementing-singleton-design-pattern.html 

Sunday 13 August 2017

Visualforce Page Life Cycle

First, we need to understand how visualforce page is created and destroyed during the course of a user session. The lifecycle of page is determined by the way page is requested.


There are two types of Visualforce page requests:

  • get request - When a user enters an URL or when a link or button is clicked that takes the user to a new page, get request is made.
  • postback request - When user interaction requires a page update, such as when a user clicks on a Save button and triggers a save action.


Order of Execution for Visualforce Page Get Requests


This diagram is self explanatory.

  1. When user request for visualforce page then Constructor method of controller are called.
  2. If there are custom component of page then constructor of controller or extension are executed. If attributes are set on the custom component using expressions, the expressions are evaluated after the constructors are evaluated.
  3. If attributes are set on the custom component using expressions, the expressions are evaluated after the constructors are evaluated.
  4. View state is maintained. Its updated when page is updated.
  5. The resulting HTML is sent to the browser. If there are any client-side technologies on the page, such as JavaScript, the browser executes them.


Once a new get request is made by the user, the view state and controller objects are deleted.

Order of Execution for Visualforce Page Postback Requests

When user clicks on Save button then postback request is sent.

  1. The view state is decoded and used as the basis for updating the values on the page.
  2. After the view state is decoded, expressions are evaluated and set methods on the controller and any controller extensions, including set methods in controllers defined for custom components, are executed.These method calls do not update the data unless all methods are executed successfully. 
  3. The action that triggered the postback request is executed. If that action completes successfully, the data is updated. If the postback request returns the user to the same page, the view state is updated.
  4. The resulting HTML is sent to the browser.
  5. Once the user is redirected to another page, the view state and controller objects are deleted.



Saturday 12 August 2017

Lightning Experience Roadmap

                     


Lightning has awesome features and Salesforce is continuously working on to improve it. 

Lightning features and ideas on which Salesforce is working can be seen from here

Lightning Report and Dashboard


Lightning Platform