Why bother? Well, for more complex strings use of String.format can be easier to write and maintain than concatenation, but a great benefit comes from its combination with Custom Labels. Messages with tokens can be stored as Custom Labels and merged with values at run-time. Custom Labels are translatable, and as different languages may use different word order, String.format becomes the sensible choice.

String.format works in a similar way to the Visualforce apex:outputText component, and the value being formatted uses the same syntax as the MessageFormat class in Java.

If you read the Java documentation you will find that single quotes have a special meaning in format strings. By enclosing text in single quotes, any special meaning of the enclosed text is ignored. For example, braces { } were used in the above example to create tokens to be replaced with values from the args parameter. You will therefore need to use single quotes if you want to include braces in your formatted text:

Of course Apex uses single quotes to enclose literal strings, so we have to use backslashes in order to embed single quotes in our string text.

But if single quotes have a special meaning in a format string, how can we include a single quote in our formatted text? Here’s a typical scenario:

String value = 'I do not recognise the term \'{0}\'', term = 'foo';
String message = String.format(value, new List<String>{term});
System.assertEquals('I do not recognise the term \'foo\'',message);

This doesn’t work as intended:

Assertion Failed:
Expected: I do not recognise the term 'foo',
Actual: I do not recognise the term {0}

Our substitution hasn’t been done.

From the Java documentation we find that we need two consecutive single quotes to be interpreted as a literal single quote:

String value = 'I do not recognise the term \'\'{0}\'\'', term = 'foo';
String message = String.format(value, new List<String>{term});
System.assertEquals('I do not recognise the term \'foo\'',message);

Share this:

Like this:

A constructor in Apex is called when an instance of a class is created. Code-wise constructors might look like member methods, but they differ in a couple of significant ways.

First, constructors can’t be called any other time than when creating an instance of a class, and second, constructors do not return values. Ever had the build error “Invalid constructor name: foo“? We soon learn that this actually means “Doh! You forgot to provide a return type for your method”.

This does mean, as it does in Java, that Apex constructors are not members that can be inherited:

A subclass inherits all the members (fields, methods, and nested classes) from its superclass. Constructors are not members, so they are not inherited by subclasses, but the constructor of the superclass can be invoked from the subclass.

So, a subclass constructor can call a constructor of its superclass. Actually, constructors call superclass constructors automatically in Apex if we don’t do it explicitly. Try running this anonymous code block:

We have defined three classes where the second extends the first and the third extends the second. In each case we have defined a constructor, for debugging the order of execution, but we haven’t explicitly called a superclass constructor.

We find that each constructor implicitly invokes the superclass constructor before executing its own body. This works recursively until there are no more superclasses, so that the constructor method bodies are executed in order going down the inheritance chain from most-super-class to the actual class we are constructing.

We can influence the chaining behaviour to some degree by calling specific constructors with this and super.

If we have a class with several constructors, each with different arguments, we can delegate from one constructor to another of the same class using this(…), or select a particular constructor of a superclass using super(…):

It is important to note that in order to preserve the order of execution of the chain of constructors, super or this must be the first line of the body of a constructor.

Constructors however are optional, and so to preserve the constructor chain, the compiler will provide a default zero-argument constructor for us just as long as we don’t provide any constructors ourselves:

If you write a constructor that takes arguments, you can then use that constructor to create an object using those arguments. If you create a constructor that takes arguments, and you still want to use a no-argument constructor, you must include one in your code. Once you create a constructor for a class, you no longer have access to the default, no-argument public constructor. You must create your own.

Which also means of course that if you do create a constructor in an abstract/virtual class that takes argument(s), you must then also provide a zero-argument constructor in order to extend the class, even if you don’t need one (it has an empty body). If you don’t then you will get a build error when you extend the class:

Share this:

Like this:

One of the things I love about Force.com is how easy it can be to stitch together blocks of functionality provided in the platform, saving you development effort. Spending a little extra time working out how to best use platform features can also save effort downstream – when you align yourself with the platform you can usually benefit from enhancements and additional functionality very quickly as it is added by Salesforce.

I was recently asked whether we could assign Field Sets for Visualforce pages to a user’s profile (without using Field Level Security to limit access to the fields entirely). Although this is not out-of-the-box functionality, I felt sure that this should be possible with a little effort by stitching together Field Sets and Hierarchical Custom Settings.

Like this:

Just back from Dreamforce ’13, which was, what’s Marc’s word for it?… oh, yes… awesome.

As per my last post, I had two sessions in the DevZone this year: Practical Introduction to Chatter Publisher Actions (with Carolina Ruiz @CarolEnLaNube), and Tests and Testability: Apex Structure and Strategy

Share this:

Like this:

I will very shortly be off to San Francisco to attend Dreamforce 2013. I am delighted to be speaking at two DevZone sessions this year:

Practical Introduction to Chatter Publisher Actions

This session is on Tuesday, November 19th at 1:30 PM, and I am very fortunate to be presenting alongside FinancialForce colleague, Carolina Ruiz @CarolEnLaNube

Chatter Publisher Actions provide a new way of interacting with Salesforce applications, allowing users to take control of records and processes from within the Chatter feed. Publisher Actions are inherently mobile – providing an easy route to engaging users with your applications via touch devices. Join us as we demonstrate specific use cases, and code examples to help developers take advantage of this new feature of the Force.com platform.

Tests and Testability: Apex Structure and Strategy

I’m presenting this session solo on Wednesday, November 20th at 9:00 AM.

Join us as we look at unit tests in Apex – what they are and where they fit within an efficient and effective testing strategy. We’ll also consider the demands that implementing such a strategy makes on how Apex code is structured in a Force.com application. You’ll leave with an appreciation of the test pyramid, and some specific examples of mocking techniques.

Share this:

Like this:

Google Chrome has a great feature for customising your searches from the “omnibox” (URL/search box) which you can use to speed up your searches of the Force.com developer documentation. Continue reading →