Mastering Application Development with Force.com

There are three main development tools for building Force.com applications. The first and perhaps the most efficient development tool is the Force.com IDE. The IDE is distributed as a plugin for the venerable Eclipse development environment. If you've done Java development, you will feel at home with this. Additionally, in the past few months, an excellent plugin for the venerable Jetbrains Intellij IDEA IDE has been released. It is called Illuminated Cloud (refer to http://www.illuminatedcloud.com/ for more information). If you're a fan of the Intellij platform, you'll feel at home with it. The Salesforce community has also established another tool called MavensMate for developing Salesforce1 applications. MavensMate is a set of plugins for the excellent sublime text and the atom text editors. The plugins use the metadata and tooling APIs to provide a rich set of development tools. These tools include logging, anonymous apex execution, and the creation and editing of metadata. Documentation on installation and use of the MavensMate plugin can be found at the MavensMate home page, http://mavensmate.com/. The developer console is a relatively new feature to Salesforce. It provides an in-browser tool for developers to create and edit metadata, as well as run tests, execute queries, and generally inquire into the state of your application code. You can access the developer console by clicking on your name in the upper right-hand corner of the screen and selecting developer console, as shown here:

At various points, you'll see text items denoted by the pipe symbol( | ), for example, File | New | Class.

Let's take a look at the following screenshot of menu instructions for the developer console:

For example, if you click on the File menu, followed by the new menu item, and finally on the class menu item, you'll be given an opportunity to create, name, and create a new Apex class:

The Salesforce1 platform runs the Apex programming language. Like most other contemporary programming languages, Apex is object-oriented. Object-oriented development is focused on the creation of and interaction between objects. Objects are the result of instantiating classes. Classes describe properties and methods that can be interacted with. For instance, you might have a Box class, with properties of height, width, and depth. A box object would refer to a specific instance of the class box, with it's own values for height, width, and depth. Classes are the basic building blocks of object-oriented development and, therefore, Force.com development. Classes come in many varieties, from Visualforce controllers and controller extensions to inner and wrapper classes and normal classes. We will work with a number of class types throughout the book. Each class type can be created via the developer console using the new class option in the file menu and giving it a name.

While classes are building blocks of object-oriented development in the Salesforce1 ecosystem, there are a couple of other code containers, specifically, triggers and lightning bundles. Aside from where the files are stored, the biggest difference between classes and triggers is found in their first line. Classes use the class keyword, whereas triggers use the Trigger keyword:

//Definition of a class
Public with sharing class myExampleClass {
//Definition of a Trigger
Trigger myExampleTrigger on Account (before insert) {

Triggers differ from classes in that they define reflexive behavior that the system takes in response to certain data manipulation actions. Triggers have their own rules and ecosystems, and we will look at them in detail in their own Chapter 2, Architecting Sustainable Triggers using a Trigger Framework. Lightning Bundles, on, on the other hand contain more than just code. Lightning bundles also contain other assets like CSS style definitions, icons and documentation.

There is an old story about a new developer and a seasoned developer tackling the same problem. The new programmer Googles the problem, and after looking at a few stack exchange posts, pastes together some code and is confident that it works. After all, he thinks, other people have this exact same problem and they helpfully posted their results online. With their help, the new developer can put together a solution. On the other hand, the experienced developer first sits down and writes a test to prove that the problem exists. Only then does the developer write code to try to rectify it. This is one of the key differences between being an application developer and a master application developer. This is equally true for Salesforce1 platform. To truly master the platform, you not only need to know the language, logic, and patterns, but also how to know, objectively, when the code is done. Because of this, we'll be focusing on writing automated tests for our code.

Knowing when your code works is paramount to Apex solutions. However, the Salesforce1 platform provides a number of ways to develop solutions without writing Apex. Almost everything that can be done with the declarative tools can be done with Apex code, but to master the platform, you need to know when to use those declarative tools and when to write Apex.

Unless you're working with a brand new developer org that contains no metadata, you can open existing pages, classes, and triggers through the use of the file menu. To open up an existing class choose File | Open. You'll see a pop-up window with three panes:

The first pane shows various types of metadata you can open that is Triggers, Classes, Objects, and so on. Once you select a metadata type, the middle pane will populate with all of the files of that type. For instance, if you select classes, you'll see all the classes in the org. You can open up any given metadata file by double-clicking on the name in the middle pane. Additionally, other resources, such as lightning bundles and static resource bundles can be opened using the File menu option, Open Resource. If you've ever used sublime text, this works similarly to the open-anything command. Start typing in the filter modal and it will reduce your selection options helping you find what you're looking for.

Likewise, to create new classes, pages, and triggers use the New menu of the Developer console. The new submenu lists all of the various types of metadata you can create in the console, including things such as Static Resources and Visualforce Components. Ensure that you familiarize yourself with the process of creating new classes, triggers, and Visualforce pages; we will be doing this throughout the book.

Across the top of the shorter pane in the developer console is a series of tabs: Logs, Tests, Checkpoints, Query Editor, View State, Progress, and Problems. One of the most important features of the developer console lies in the ability to run SOQL and SOSL queries directly from it. To open the query editor, click on the Query Editor tab. Once opened, you can start typing your query in the lower pane.

Remember that SOQL queries must start with SELECT and SOSL queries must start with FIND when you run a query. After you run a query you'll see the results in the upper pane of the developer console. You can interact with these records by selecting a record and clicking on the command buttons at the bottom of the pane. This allows you to open the record in the Salesforce user interface, or delete the record right there in the developer console, as shown in the following screenshot:

While we're discussing this, let's go ahead and give it a try. Your developer org comes with a certain number of accounts and contacts pre-established. We can run a query right now and experience how the developer console query editor works. Write this query in the query editor of your developer console:

Select SELECT Id, name Name from FROM Account;  

If you're using a new developer org, you'll have between 10 and 12 accounts that are returned as results in the top pane of the developer console. In fact, unless you delete the accounts from your org, this query will always return at least a few records, each column being one of the two fields requested in select clause of the query. Double-click on the Name field of the first record. As soon as you do so, you'll find that you can edit the record name right there. However, once you have edited a field on a record, ensure that you hit the Save record button at the bottom of the pane. You'll also find buttons to insert a new row, access that record in the Salesforce user interface, and open the records detail page.

Another tab in the bottom pane is the Tests tab. This is where you will run and, otherwise, interact with unit tests. Unit tests are methods of code that we run to execute and test units of live code. We'll talk extensively about unit tests in Chapter 5, Writing Efficient and Useful Unit Tests. Unit tests are run asynchronously, meaning they don't run immediately when you fire them up. You'll need to wait a bit while your tests run and the tests tab will show you when they start. As the test run completes, you'll see that the individual suites are completed and the individual tests are underneath them via disclosure triangles. Should you have a failure, you can double-click on the failure to bring up the results of that particular test in the upper portion of the developer console. Here, you can see the tests tab with the test suites and test methods expanded:

When viewing the Tests tab, an additional data pane shows up in the lower-right corner. While the bottom-left pane allows you to view test runs, the bottom-right pane shows you the code coverage for the various classes and triggers in your org:

This window shows the overall aggregate code coverage metric that matters when deploying from one org to another and you must have at least 75% of your code covered as measured here. As you can see, I don't have anywhere near the code coverage I need. Double-clicking on a class or trigger listed in this code-coverage pane will open the class and display which lines are covered and which are not. This is an incredibly useful tool for finding testing gaps!

Lightning Components are the building blocks of lightning apps. They're written in JavaScript, Apex, and HTML/CSS; they represent the next evolution of Salesforce application development. If you've enabled Lightning Components in your org, you'll see that the ability to create new Lightning Components is in the same New menu list as classes, triggers, and so on. Specifically, you'll see options to create new lightning apps, Lightning Components, lightning interfaces, and lightning events. However, opening lightning resources is slightly different than opening a Visualforce page or an Apex class. Instead of navigating to File | Open, you have to use the new open lightning resources menu item in your file. We'll talk more about lightning components in Chapter 6, Deploying Your Code.

One of the great benefits of the developer console is that you can read all of the debug logs that come through your org. Debug logs are log files generated by code execution on the platform. Whenever a user navigates to a Visualforce page or a trigger is run, for instance, the platform generates detailed logs about what happened and how long it took, developers can insert data into these logs using the Apex method, System.debug(string). By default, only debug logs created when your user has taken action are shown on the Logs option. However, you can toggle seeing the debug logs for all users via the Debug menu. Once an event that has generated logs has occurred, you'll see them listed under the Logs tab, as shown here:

Default sorting is by time, with the newest on top; however, you can sort by the username, application, and so on. More importantly, you are able to sort through them by status. To open the log, simply double-click on it. This will open up in the larger pane of the developer console. Alternatively, if you'd like more of a raw view of the log, you can right-click on it and open Raw Log.

Regardless of how you open the log, the more you deal with them, the more you'll realize they can get to be quite large; sometimes, several megabytes in size. To help with this, the developer console has a way for you to alter the log verbosity. These settings are referred to as the log levels and they provide a fairly fine-grained level of control over how verbose the various system components log. To modify the log levels, click on the Debug menu and then select Change Log Levels:

Here, you can set the general log levels for a given period of time for database (DB) calls, Callouts, Apex Code, Validation (validation rules), Workflow (workflow rules), Profiling and Visualforce, and the System itself. Each log type has seven verbosity levels ranging from ERROR at the lowest verbosity to FINEST at the most verbose. At the most basic, at the least verbose setting of ERROR, only true errors are logged. On the other hand, FINEST logs the most minute details of the code execution:

More importantly, you can set per class and per trigger overrides if you want to debug a specific class or trigger. Increasing the logging verbosity for your troublesome class or trigger can help you highlight performance problems as well as logic issues. In general, while writing code, it's good to leave most log types on INFO but I set workflow and validation rule logging to error, as workflow and validation rules can log quite a lot.

Anonymous Apex is probably one of the most misunderstood and easily overlooked aspects of Force.com development. Anonymous apex allows you to run scripts or snippets of Apex code without compiling it into a class. Functionally, this means that you can run a query and iterate over the results to do a one-off data cleanup script, for example. Alternatively, you can also do functional system tests, such as making callouts and executing code. You can think of this as a little bit like a DOS batch job or a Linux shell script. To access the execute anonymous window, open the developer console and click on the Debug menu and then select Open Execute Anonymous Window:

This will open a resizable modal window where you can type the Apex code, as shown in the following screenshot:

Unlike the main class and trigger editor you will not receive syntax help, but you will get syntax highlighting. Anonymous apex is not terribly different from a Swiss Army chainsaw. You can do anything you want with it, but if you're not careful, you'll cut your foot off. A mistake can easily delete records or modify them beyond repair. Be careful.

The last bit of the developer console we need to cover is the Problems tab. Should you have a syntax error in any of your code, the Problems tab will list them along with the class name and line number:

For instance, if you forget a ; it will list the name of the class, a pretty decent rough estimate of the problematic line number, and what the compilation error is. The Problems tab updates asynchronously to other activities. However, it will update a badge style count of errors in the background. Whenever you see a badge icon over the Problems tab, you have a syntax error in your code.