Difference in ISNULL and ISBLANK

ISNULL:

•  Determines if an expression is null (blank) and returns TRUE if it is. If it contains a value, this function returns FALSE.
• Text fields are never null, so using this function with a text field always returns false. For example, the formula field IF(ISNULL(new__c) 1, 0) is always zero regardless of the value in the New field. For text fields, use the ISBLANK function instead. 
• Multi-select picklist fields are never null in s-controls, buttons, and email templates, so using this function with a multi-select picklist field in those contexts always returns false.
• Empty date and date/time fields always return true when referenced in ISNULL functions.
• Choose Treat blank fields as blanks for your formula when referencing a number, percent, or currency field in an ISNULL function. Choosing Treat blank fields as zeroes gives blank fields the value of zero so none of them will be null. 
• Merge fields can be handled as blanks, which can affect the results of components like scontrols because they can call this function.
• When using a validation rule to ensure that a number field contains a specific value, use the ISNULL function to include fields that do not contain any value. For example, to validate that a custom field contains a value of ’1,’ use the following validation rule to display an error if the field is blank or any other number: OR (ISNULL(field__c), field__c<>1)

ISBLANK:

• Determines if an expression has a value and returns TRUE if it does not. If it contains a 
  value, this function returns FALSE.
• Use ISBLANK instead of ISNULL in new formulas. ISBLANK has the same 
  functionality as ISNULL, but also supports text fields. Salesforce.com will continue to 
  support ISNULL, so you do not need to change any existing formulas.
• A field is not empty if it contains a character, blank space, or zero. For example, a field 
  that contains a space inserted with the spacebar is not empty.
• Use the BLANKVALUE function to return a specified string if the field does not have a 
  value; use the ISBLANK function if you only want to check if the field has a value.
• If you use this function with a numeric field, the function only returns TRUE if the field 
  has no value and is not configured to treat blank fields as zeroes.

Difference between 15 digit and 18 digit ID in Salesforce

• 15 digit case-sensitive version 
• 15 digit ID is referenced in the UI
• 18 digit case-insensitive 
• 18 digit id is referenced through in the API
• Why do we need 18 digit IDs, because many Legacy system [ex: excel sheets] work with Case insensitive IDs
• The id displayed by a report is the 15-digit case-sensitive id. The ids returned by web services api are 18-digit id. For updates web service accept both the 15-digit and 18-digit ids.

BreakDown of 15 Characters - 

As there is a combination of lower and upper case letters the casing of the 15 character Id has significance. E.g. 50130000000014c is a different ID from 50130000000014C.

Within a 15 character Id the breakdown is:

• First 3 characters - The first 3 characters are the key prefix that identify the object type. There are some exceptions to this where multiple objects all share the same key prefix! 
• There are a number of fixed key prefixes that are common across all of Salesforce .  Custom objects in managed packages can have a different keyprefix in each installed org.(Cross check once)
• The 4th and 5th characters - Reserved. Currently used for the instance id / POD Identifier. Indicates which pod/instance the record was created on.
• 6th character - Reserved. Will be 0 until such time that Salesforce has a need for it. See more
• Remaining 9 characters - basically a really big number. Like 62^9 big.

To this you can add an optional 3 character suffix that will make the Id unique case-insensitive.

 This is useful when working with programs that can't maintain the case of the ID (E.g. Excel VLookup).

See More 1 

Salesforce Certified Platform App Builder exam syllabus

Salesforce Certified Platform App Builder exam syllabus -

 A candidate should have hands-on experience developing custom applications on the Force.com platform and have demonstrated the application of each of the features/functions below -

OBJECTIVE (WEIGHT)
Salesforce Fundamentals ( 8% )
Describe the capabilities of the core CRM objects in the Salesforce schema.
Given a scenario, identify the boundaries of declarative customization and the use cases for programmatic customization
Identify common scenarios for extending an org using the AppExchange.
Data Modeling and Management ( 20% )
Given a scenario, determine the appropriate data model.
Describe the capabilities of the various relationship types and the implications of each on record access, user interface (UI), and reporting.
Identify the considerations when changing a field's type.
Given a set of requirements, identify the considerations and select the appropriate field type.
Describe the capabilities and considerations of the schema builder.
Describe the options and considerations when importing and exporting data.
Describe the capabilities of and use cases for external objects.
Security ( 10% )
Describe the features and capabilities available to restrict and extend object, record, and field access
Given a set of business requirements, determine the appropriate sharing solution.
Business Logic and Process Automation ( 27% )
Describe the capabilities of and use cases for record types.
Describe the capabilities of and use cases for formula fields.
Describe the capabilities of, use cases for, and implications of roll-up summary fields.
Describe the capabilities of and use cases for validation rules.
Describe the capabilities of and use cases for approval processes.
Describe the capabilities of and use cases for workflow, visual workflow, and the Lightning Process Builder.
Given a set of business requirements, recommend a solution to automate business processes.
Describe the ramifications of field updates and the potential for recursion.
Social ( 3 % )
Describe the capabilities of and use cases for social features.
User Interface ( 14% )
Describe the user interface customization options.
Describe the capabilities of and use cases for custom buttons, links, and actions.
Describe the declarative options available for incorporating Lightning Components in an application.
Given a scenario, determine the appropriate user interface design.
Reporting ( 5% )
Determine the features and capabilities available when creating reports, report types, and dashboards.
Mobile ( 5% )
Describe the declarative customization options available for the Salesforce1 mobile application user interface.
Given a set of requirements, determine the appropriate global and object-specific actions and action layouts to optimize the Salesforce1 user experience.
App Deployment
Describe the key milestones and considerations when managing the application lifecycle.
Describe the differences between and considerations when using the various types of sandboxes.
Describe the capabilities of and considerations when using change sets.
Describe the use cases of and considerations when using unmanaged packages.
Given a scenario, determine the appropriate deployment plan.

Click here For Salesforce Certified Platform Developer - I exam Syllabus
Click here For Salesforce Certified Platform Developer - II exam Syllabus

Salesforce Certified Platform Developer II exam syllabus

Salesforce Certified Platform Developer II exam syllabus -



If you are new to Salesforce and do not have any practical work experience or hands on actual development ,then my suggestion is that you should go for Platform App Builder Certification Exam

And If you have not yet given Salesforce Certified Platform Developer I exam and do not have advance/vast experience on Salesforce Development then you should first go for  Platform Developer I Certification

OBJECTIVE (WEIGHT)
Salesforce Fundamentals ( 5% )
Describe the capabilities of base-system objects such as sharing objects, history objects, metadata objects, multi-currency, and Chatter objects
Describe the different capabilities of and use cases for the various Salesforce development platforms (Heroku, Fuel, Force.com)
Data Modeling and Management ( 7% )
Describe how to design code that accommodates multi-language, multi-currency, multi-locale considerations
Describe the implications of compound data types in Apex programming.
Describe the use cases for and benefits of external IDs.
Identify use cases for different types of custom settings, and describe how to implement solutions for those use cases.
Logic and Process Automation ( 46% )
Given a scenario, describe the implications of the order of execution of a record save.
Describe the interactions between Visualforce/Apex with Flow/Lightning Process Builder.
Given a scenario, identify the optimal programmatic or declarative solution.
Given a scenario, debug unexpected behavior due to save execution order.
Describe the Apex features available for error handling and maintaining transactional integrity.
Identify potential issues with inefficient code and mitigation techniques to avoid exceeding governor limits.
Describe the data return types for SOQL and SOSL queries and their impact on variable assignment.
Describe the options, best practices, and use cases for asynchronous execution.
Given a scenario, identify the appropriate dynamic Apex feature.
Given a scenario, describe when and how to use Apex managed sharing.
Describe the use cases for the various authentication techniques.
User Interface ( 20% )
Given a scenario, describe how to use a standard set controller.
Describe the considerations when creating custom controllers and controller extensions.
Describe the techniques for using Visualforce to perform actions and partial page refresh.
Describe the messaging techniques and best practices when displaying errors in user interfaces.
Describe techniques to maximize code re-use with Visualforce.
Describe use cases for JavaScript in a Visualforce page.
Given a set of requirements, describe the process for designing Lightning components.
Debug and Deployment Tools ( 10% )
Describe how to monitor and access various types of debug logs.
Describe the capabilities and security implications of the Developer Console, Workbench, and Force.com IDE.
Describe the different processes for deploying metadata and business data.
Describe how the different environments are used in the development and deployment process.
Performance ( 7% )
Describe the common performance issues for user interfaces and the techniques to mitigate them.
Describe the considerations for query performance.
Integration ( 11 %)
Describe how to expose Apex classes as SOAP and REST web services.
Describe how to use system classes to integrate with SOAP- or REST-based web services.
Describe when and how to use metadata, streaming, and Analytics API to enhance Apex and Visualforce solutions.
Testing ( 12 %)
Describe the best practices for unit testing in Apex.
Describe how to apply different techniques to create test data and responses.
Describe the implications of testing Visualforce controllers and controller extensions.
Describe various ways to execute tests and specify test execution options.
Debug and Deployment Tools ( 5% )
Given a scenario, identify the appropriate tool to analyze application performance profiles and troubleshoot data and performance issues.
Given a scenario, identify the appropriate deployment tool.

Click here For Salesforce Certified Platform Developer - I exam Syllabus

Salesforce Certified Platform Developer - I exam Syllabus

Salesforce Certified Platform Developer I exam syllabus -

A candidate should have hands-on experience developing custom applications on the Force.com platform and have demonstrated the application of each of the features/functions below.

If you are new to Salesforce and do not have any practical work experience or hands on actual development ,then my suggestion is that you should go for Platform App Builder Certification

OBJECTIVE (WEIGHT)
Salesforce Fundamentals ( 10% )
Describe the considerations when developing in a multi-tenant environment.
Describe how the Salesforce platform features map to the MVC pattern.
Describe the capabilities of the core CRM objects in the Salesforce schema.
Identify the common scenarios for extending an application's capabilities using the AppExchange.
Given a scenario, identify common use cases for declarative customization.
Data Modeling and Management ( 12% )
Given a set of requirements, determine the appropriate data model.
Describe the capabilities of the various relationship types and the implications of each on record access, user interface (UI), and object-oriented programming.
Describe the impact of schema design and modifications on Apex Development.
Describe how to visualize and create entity relationships.
Describe the options for and considerations when importing and exporting data into development environments
Logic and Process Automation ( 46% )
Describe how to programmatically access and utilize the object schema.
Describe the capabilities and use cases for formula fields.
Describe the capabilities and use cases for roll-up summary fields.
Describe the capabilities of the declarative process automation features.
Describe when to use declarative automation features vs. Apex classes and triggers.
Describe how to declare variables and constants in Apex and how to assign values using expressions.
Describe the primitive and complex Apex data types and when to use them.
Describe how to use and apply Apex control flow statements.
Describe how to write and when to use Apex classes and interfaces.
Describe how to use basic SOSL, SOQL, and DML statements.
Describe the basic patterns used in triggers and classes to process data efficiently.
Describe when to use and how to write triggers.
Describe the implications of governor limits on Apex transactions.
Describe the relationship between Apex transactions, the save execution order, and the potential for recursion and/or cascading.
Describe how to implement exception handling in Apex.
Describe how to write Visualforce controllers.
Describe when and how to use standard Visualforce controllers vs. Apex custom controllers and controller extensions.
Describe the programmatic techniques to prevent security vulnerabilities in Apex and Visualforce.
Describe how Apex impacts the ability to make declarative changes.
User Interface ( 10% )
Describe how to display Salesforce data using a Visualforce page.
Describe the types of web content that can be incorporated into Visualforce pages.
Describe how to incorporate Visualforce pages into Force.com applications.
Describe the benefits of the Lightning Component framework.
Describe the resources that can be contained in a Lightning Component.
Testing (12% )
Describe the testing framework and requirements for deployment.
Describe how to write unit tests for triggers, controllers, and classes.
Describe when and how to use various sources of test data.
Describe how to execute one or multiple test classes.
Describe the differences between invoking Apex in execute anonymous vs. unit tests.
Debug and Deployment Tools ( 10% )
Describe how to monitor and access various types of debug logs.
Describe the capabilities and security implications of the Developer Console, Workbench, and Force.com IDE.
Describe the different processes for deploying metadata and business data.
Describe how the different environments are used in the development and deployment process.

Click here For Salesforce Certified Platform Developer - II exam Syllabus

SOAP API and REST API

* SOAP API and REST API are two commonly used API's to expose your data from force.com platform to the other platforms(JAVA , .NET ,etc) or to allow external application to invoke Apex methods.

What is SOAP ?

The Simple Object Access Protocol (SOAP) is an attempt to define a standard for creating web service APIs. It is a pattern, a web service architecture, which specifies the basic rules to be considered while designing web service platforms. It typically uses HTTP as a layer 7 protocol, although this is not mandatory. The SOAP message itself consists of an envelope, inside of which are the SOAP headers and body, the actual information we want to send. It is based on the standard XML format, designed especially to transport and store structured data. SOAP may also refer to the format of the XML that the envelope uses.

SOAP is a mature standard and is heavily used in many systems, but it does not use many of the functionality build in HTTP. While some consider it slow, it provides a heavy set of functionality which is a necessity in many cases. It might now be the best solution for browser-based clients, due to its custom format.

 What is REST ?

The Representational State Transfer (REST) is another architectural pattern (resource-oriented), an alternative to SOAP. Unlike SOAP, RESTful applications use the HTTP build-in headers (with a variety of media-types) to carry meta information and use the GET, POST, PUT and DELETE verbs to perform CRUD operations. REST is resource-oriented and uses clean URLs (or RESTful URLs).

For example :

http://www.developingthefuture.com/index.php?page=foo

becomes

http://www.developingthefuture.com/foo

This kind of URLs syntax greatly improves both visibility and usability. It doesn’t use any query strings, and it also provides certain SEO benefits (the crawlers just love plain text). The body of the REST message can be XML, JSON or any other format, although JSON is usually the preferred choice. On the other hand, you can’t use JSON with SOAP. Or at least not entirely, because SOAP uses XML by definition for it’s envelope. It should also mentioned that REST is, by design, protocol-agnostic, although it is usually used with HTTP. 

SOAP API

1)Supports data in the form of XML only 2)Requires WSDL for the integration 3)Use SOAP API in any language that supports Web services.

REST API

1)Supports both XML and JSON format 2)Preferred for mobile and web apps since JSON being Lighter the app runs smoother and faster

>>>>>>> VISIT THIS FOR MORE INFORMATION  >>>>>>>>>>

(Courtesy Groundwire Consulting)

Maximum View State Size Limit (135kB) Exceeded

I bet many Salesforce Developer face this issue while working on  Visualforce Pages where they are trying to do something like - "Render VF page as PDF", "Upload File", etc.

Problem :  Maximum View State Size limit (135kB) exceeded

Error : Maximum view state size limit (135KB) exceeded. Actual view state size for this page was 838.719KB   (<- this last digits can be any)

Solution : 

- View state size of your Visualforce pages must be under 135KB. 

- The View State tab shows you which elements on your page are taking up that space. A smaller view state size generally means quicker load times.

- In order to avoid this error, minimize your pages' view state. You can optimize your Apex controller code and remove any superfluous Visualforce components used.

Try following :

• If you notice that a large percentage of your view state comes from objects used in controllers or controller extensions,consider refining your SOQL calls to return only data that's relevant to the Visualforce page. 
• 
  
• If your view state is affected by a large component tree, try reducing the number of components your page depends on.
• 
  
• Only those variables which are used on visual force page should be PUBLIC rest all variables should be PRIVATE, if they are not used by any other class.
• 
  
• Make variables TRANSIENT which leads to increase the view state size, which shouldn't be transmitted as part of the view state for visual force page. Transient variables are not stored in the view state. 
• I mean simply put "transient" keyword in front of your variable declarations.
•  
• We should nullify all the instance of objects which are no longer in use, Like clear your object instance, Lists, Maps,etc.   (Example : after done with working on List in for loop simply do -> mylist=null;  after for loop)

Try this if you are comfortable with JavaScript : 

The best way to achieve this use case is to use AJAX API.  After you have fixed view state error, it will hit apex heap limit of 6MB. But using AJAX API you can upload files of size up to 25MB, which is the maximum size limit of attachments in salesforce.

You just need to pass the parent Id and the image file. For sample code please check THIS POST.

• 
  

Useful Links: 

View State

Using Transient keyword

Best Practices for Improving Visualforce Performance

Difference between Object-Level Security , Field-Level Security and Record-level Security

Object-Level Security

The bluntest way that we can control data is by preventing a user from seeing, creating, editing, and/or deleting any instance of a particular type of object, like a position or review. Object-level access allows us to hide whole tabs and objects from particular users, so that they don't even know that type of data exists. On the platform, we set object-level access rules with object permissions

on user profiles.

Field-Level Security

A variation on object-level access is field-level access, in which a user can be prevented from seeing, editing, and/or deleting the value for a particular field on an object. Field-level access allows us to hide sensitive information like the maximum salary for a position or a candidate's social security

number without having to hide the whole object. On the platform, we set field-level access rules with the field-level security.

For More Detail Click Field-Level Security

Record-Level Security

To control data with a little more finesse, we can allow particular users to view an object, but then restrict the individual object records that they're allowed to see. For example, record-level access allows an interviewer like Melissa Lee to see and edit her own reviews, without exposing the reviews

of everyone else on her team. On the platform, we actually have four ways of setting record-level access

rules:

• Organization-wide defaults allow us to specify the baseline level of access that a user has in your organization. For example, we can make it so that any user can see any record of a particular object to which their user profile gives them access, but so that they'll need extra

permissions to actually edit one.

• Role hierarchies allow us to make sure that a manager will always have access to the same records as his or her subordinates.

• Sharing rules allow us to make automatic exceptions to organization-wide defaults for particular groups of users.

• Manual sharing allows record owners to give read and edit permissions to folks who might not have access to the record any other way.