Remoting is awesome.

JavaScript Remoting for Apex operates in a very different paradigm from what you might be used to i.e. Visualforce pages have controllers and the two interact through action methods – where this might be a full form submission or some neat AJAX functionality. Remoting also calls controller methods but there is a gaping maw in terms of how the two work under the hood.

I’ve seen a few great articles on the syntax and example usage of JavaScript Remoting for Apex but when I started using it I came across a number domain differences that weren’t documented anywhere. Hopefully my list here will help you in the learning process. The best way to describe the new way of thinking is to examine the features set in contrast to “normal” Apex and Visualforce.

How JavaScript Remoting Differs

• Pass parameters naturally i.e. the call matches the method signature syntactically instead of requiring <apex:param/>.
• Action methods when called in “normal” Visualforce can only return NULL or a PageReference. Remoting allows you to return a wider range of data types, even objects and collections.
• Remoting methods have no access to the view state e.g. if a static variable is initialised to some value (outside the remoting method) a remoting method will see this as NULL unless it is re-initialised in that method! Conversely if a remoting method sets a state variable value the scope of that value is only within that method.
• It’s much faster. I’m building an application at the moment that is 95% backed by JS Remoting and when I show it to other developers they are struck dumb for at least 3 hours because of the speed.
• Neater debugging info in the browser console. Salesforce has done a great job of providing feedback directly to the browser’s console log.
• Each method call gets its own executional/transactional context i.e. fresh governor limits per call!

If I’ve missed anything please let me know and I’ll add it. Viva la knowledge crowdsourcing!

This solution is quite difficult to find.

Call me crazy but I need to do this from time to time, and every time I do I can’t remember how I did it before! So I then trudge through the API and the Apex docs until I find the answer and that’s no mean feat in this specific case. Well, no more my friends because I’m putting it right here on this very blog!

In short the code below will return (as a String) the type of field that we’re working with. Neither the name of the object or the name of the field need to be known in advance.

    public static String getFieldType(String fieldName){
    	// Assume that "sObjectName" is populated elsewhere
	Schema.SObjectType t = Schema.getGlobalDescribe().get(sObjectName);

	Schema.DescribeSObjectResult r = t.getDescribe();
	Schema.DescribeFieldResult f = r.fields.getMap().get(fieldName).getDescribe();

	if (f.getType() == Schema.DisplayType.String){
		return 'String';
	} // .... else if

	return null;
    }

Spot the difference.

Many people are finding that their tests are reporting different degrees of test-coverage in different environments. There are a few things to check if you are getting inconsistent results but there’s a new bug in the wild. Before you assume you have the bug make sure that you’ve:

1. ‘Run All Tests’ in each environment. This will tell you a few things viz.
• Perhaps there are tests failing that are bringing coverage in that environment down.
• There are some tests that only fail when run in the browser e.g. MIXED_DML_EXCEPTION will not rear it’s head through the IDE.
2. Click the ‘Compile all classes’ link above the Setup > Develop > Apex Classes view. I’m not sure when this lil’ bugger first appeared but it’s darn useful. Essentially it makes sure that all the dependencies in your code are fulfilled e.g. if page A uses controller B that in turn refers to utility class C it’ll make sure each of those pieces exist and work (as far as compilation goes at least).
3. Double-check your test classes to make sure they’re not data dependent. If they are and you have different types/amounts of data in your respective environments it’s 100% feasible that the test coverage will be different.

Now if you’ve checked all of the above you might have been afflicted by a new bug which, for some reason, counts braces, whitespace (and more!) as being uncovered by your tests. This is preposterous of course and to fix it simply remove all test history from the deranged environment. Re-running the test and/or deploying them should now be back to normal!

I’ve had to do this a few times but infrequently enough for me to forget how to do it each time. Forgetting things isn’t usually an issue because of our Google Overlords and their mighty The Google but it’s quite a journey down the rabbit hole to find this specific information.

The reasons it’s tricky to find is because the setting that controls whether an email is sent to the user on creation is not directly associated with users but with DML. Long story short you need to set a particular Database.DMLOption e.g.

User u = new User();
// Add some details here ...

// Set the DML options
Database.DMLOptions dlo = new Database.DMLOptions();
dlo.EmailHeader.triggerUserEmail = false;

Database.insert(u,dlo);

Hopefully this information will now be easier to find next time I forget

I’m not sure if this concept is obvious when reading my previous post, so I thought I’d run through it with a specific example.

Rule one of packaging - Finish your bolognese first!

Let’s say that you’ve created what can only be described as an exemplary application in the form of a Managed Package. Although your user interface is beyond compare, you’d also like to populate some of your core objects with example data. Some options that immediately spring to mind are:

1. Get the person that installs the package to call you, and you can do it post-installation.
2. Get the person that installs the package to create sample data manually post-installation.
3. Give the user a “Start Here” page with a call-to-action – such as a commandButton – that fetches the data from some API and parses into object data.

Option 3 is pretty excellent, especially now that you can package Remote Site Settings but I think we can do one better. And when I say better I mean simpler and with fewer potential points of failure. Read the rest of this entry »

Okay book’s done, now where were we? Oh yes software development, right? Programming software engineering application development h4x0R-ing. Oh how I’ve missed getting my mitts dirty so without further ado…

Now this one goes right about... here!

Some time back Custom Settings were introduced on the Force.com Platform and we all star-jumped in the air, w00ting to anyone who would listen. Up till this point – if you’re anything like me – you were using custom objects to hold configuration data, whether this be lists of language-codes, or operational settings such at outbound web service endpoints, usernames, passwords etc. With Custom Settings you finally had a place to put this information – a home if you will – for your lonely, orphaned Control Data.

Quite quickly however I realised there was still a gaping hole that could be filled with Custom Settings but just didn’t feel right. Lists of data (such as currency codes and descriptions) fit really well into this structure but more serious Control Data that you only need to be listed once-off (such as important URLs, flags to active/deactive modules in your application, usernames and passwords) just don’t seem like they really belong with this other crowd. A quick list of reasons highlights this:

• Control Data is typically entered once off and creating an entire Custom Setting for a single line of data feels like a waste.
• Custom Settings are data so they can’t be deployed with code, they must be created after the fact. Control Data should be a little more important than regular data, it needs a smarter vehicle than plain-old data entry.
• If you’re creating packages you want as much autonomy for your clients as possible. If you use custom settings there will have to be that “Create data in Custom Setting X__c” step in each and every deployment. Read the rest of this entry »

For a time I’d wondered what the difference between the System.Assert and System.AssertEquals methods might be (System.AssertNotEquals to a lesser degree). To be honest this tip isn’t going to help much with World Peace or Curing Internetlessness, but it’s certainly gonna save you some time.

Looking at the documentation there are some obvious differences.

• System.Assert accepts two parameters, one (mandatory) which is the condition to test for and the other a message (optional) to display should that condition be false.
• System.AssertEquals and System.AssertNotEquals both accepts three parameters; the first two (mandatory) are the variables that will be tested for in/equality and the third (optional) is the message to display if the assert results in false.

Pretty standard stuff, and can all be learnt simply by Reading The Manual.

Now testing best practices state that you should assert some condition but also output a “console” message that shows the values of each of the operands. This certainly helps you debug unit tests when asserts are failing, but man I hate typing extra code just to check out some variable values! So the time saving trick that isn’t obvious is that when omitting the optional third parameter for System.AssertEquals and System.AssertNotEquals the compiler automagically outputs the values of the operands to the console log. That’s right, instead of typing:

System.assert(var1 == var2, "The value of var1 is: " +var1 + " and the value of... oh hell I don't care I mean it's just a variable");

You could type:

System.assertEquals(var1, var2);

If the second assertion fails the console will output the values of var1 and var2 with the labels “expected” and “actual”. Knowing this now I can see no exceptional reason to use System.assert any longer (sorry little guy).

As I said this trick’s not gonna start any Mexican Waves but it should help delay the onset of RSI.

(thanks to l-dawg for opening my eyes)

A few weeks ago I noticed a number of questions in the forums around how to use email templates from Apex classes. I Googled a few keywords and come up with very little. I then trawled the documentation but came up empty-handed. Eventually it was Eclipse that provided the knowledge required, and I thought I’d share it with the good ol’ developer community.

One part of the process is discovering that Salesforce stores all sorts of items as records in objects; some of them being email templates, user information and even Apex class bodies (scandalous). All you have to do is query them. The other major part is finding that the method you need is missing from the Apex documentation.

Read the rest of this entry »

Too Much Documentation (TMD) - The leading cause of baldness amongst men.

There are several tomes & tools to help you integrate with the platform; this article will concentrate on WSDL defined web services. Some help texts are specific to certain languages, others favour certain approaches but I’ve found there’s no short-and-sweet guide. As someone who’s nearly drowned in the documentation (including forums, tweets and blogs) I thought I’d try to save – at least some of you – the white-squall that is ‘Learning the basics of SFDC WSDL-based integration’.

I’ll be the first to admit that summarising such a broad topic can be difficult, so if I do miss anything out, y’all out there in the community just let me know. Read the rest of this entry »

Unit testing *sigh*. Oh how they vex me. If they weren’t so important (and required) I’d just skip the lot, but they are and so we – champions of software development – must press on in the face of dreary complexity; we will not back down, we will not surrender, we will look that CRT/LCD screen in the pixels and say, “Untested units, you will not defeat me!”.

Diving into the thick of things, the most common question seems to be, “Why can’t I get code coverage for my entire class?!”. The trick here is to think like a runtime engine, and consider how you might journey through all possible testing paths. Now I never said it’s easy, but with a bit of practice (and 8 truck loads of patience) you’ll get there. Let’s look at some common cases. Read the rest of this entry »