Know your apps from your apps

Having just been at Dreamforce 2013 with Desynit, we have all come away with bright, wide eyes, staggering forward repeating the word "app, app, app" like a mob of geeky zombies. Filling the "app gap" has been cited as our number one priority, and the new Salesforce 1 Platform has basically been given to us as an incredible "free tonne of bricks" to start doing this.

But it appeared during discussions that this concept is starting to confuse a few people, and after a few whiteboard sessions explaining similar concepts over and over, I decided a blog post was in order on "what is the difference between an app, an app, and an app?"

It's a good question actually, and typically we use a couple of pre-cursors to help us separate the types of app, and it's important you know the difference before you go applying the term to your business.

The traditional, and predominant use of the term "app" is referring to what we technically call a "native app" and these are specifically (and expensively) written pieces of software designed to run on a certain type of device. Everything you download from the AppStore™ for your iPhone™ is ultimately a native app for your Apple™ devices.

These native apps are written in the appropriate programming language for the device they are intended to run on (ObjectiveC for Apple™ devices, Java for Android etc.etc.) and are typically fairly difficult to port between the different devices. They communicate with your Salesforce org via the various APIs sending data back and forth over secure external connections.

They are also written, compiled and released at a set moment in time, and do not change from that point (other than by lengthy update processes). This means if your underlying Salesforce data structure or business processes change, your expensive app might become redundant.

One worldwide example of a native app could be seen in downloading the facebook app available to almost every mobile device in existence.

The second most common use of the term is referring to "web apps" these are slightly newer to the scene in their most popular format as it has taken longer for mobile and tablet devices to consistently come up to speed supporting the predominant technologies, HTML5 and CSS3.

The key to web apps is that they are not "downloaded" and stored on the mobile device, but are instead "accessed" - typically though the phones standard web browser - and are so cleverly written they provide a rich and functional experience. The actual compilation and markup is generated by the webservers, off on the internet, and the interfaces then rendered out by the phone. A lot of interesting libraries and technologies exist (such as Dojox.mobile and PhoneGap) that can detect the "type" of device being used and then make the web page mimic the native control's appearances giving the user a very consistent experience, but in fact actually running almost no logical code on the device at all.

Some of the huge perks of these apps is that they quite simply run on any device that can access the internet. They can be seemlessly updated on the servers, and the user receives the updated version immediately, and because they are probably typically provided by, or hosted on the users core system, have unrivalled access to the company data.

An example of a web app can loosely be seen by accessing the facebook website on a mobile device (typically accessible on http://m.facebook.com) - you will receive a rich and integrated Facebook experience, but without a native app, purely through the browser.

The final kind of app a user might experience is called a "hybrid app" and you might not be surprised to hear that this is a mixture of the two app types mentioned above. Hybrid apps - such as the latest and greatest Salesforce 1 Platform typically have a native container, that the user downloads to their mobile device, but this then delivers rich web content through windows, or frames to the companies web service.

Hybrid apps, whilst therefore still limited to distribution through appstores on the relevant hardware (basically; sorry Blackberry users) can harness the full power of the devices features and hardware, whilst delivering an up-to-date web services.

In summary the original interpretation of the term "app" being a native piece of software for a phone, is - in this developers opinion - possibly now one of the more restrictive and life-limited meanings. The huge cost and limited flexibility means that unless you directly intend to take advantage of the increased local processing power/storage and access to the device hardware it really isn't the most sensible option any more. I am convinced that more and more apps will at the very least be naturally evolving into Hybrids, the incredible power demonstrated by Salesforce 1 shows how you can be seamlessly passed between native and web services without any interruption or hassle for the end user.

Never forget Salesforce ActionSupport events are case sensitive!

I'm pretty sure this is repeated around the world, but I thought one more blog post throwing it's weight behind it wouldn't hurt. Developers, do not forget that Visualforce ActionSupport events ARE case sensitive.

The Actionsupport DOM events include "onchange", "onclick", "ondblclick", "onfocus", "onkeydown", "onkeyup", "onmousedown", "onmousemove" and so on and so on, and these are all in lowercase, despite the occasional new Javascript convention to camelCase them.

That easily cost me half an hour of visualforce debugging, and not for the first time!

Now, as a quick test to make sure you were paying attention, why won't my daysbox element rerender in this code snippet?? Use your eyes, and your minds..

Reducing SOQL queries in Triggers by updating on ID

I have recently been battling the SOQL query limit on a large Force.com project I'm working on.

One of the biggest problems we have is with SOQL in Triggers, over and over again, we were using SOQL to load a list of parent/related objects, modifying their contents and then updating them.

Then one day, I realised, we didn't need to do this at all.

Here is an example of a trigger that "passed" a status field from an updated object back to it's parent:

trigger UpdateParent on Child__c (after insert, after update)
{ 
    // get the list of parent object IDs
    List Ids = new List();
    for(Child__c thisChild : Trigger.new) {
         Ids.add(thisChild.ParentRef__c);
    }

    // Load up the list of parent objects and map them out for altering and updating
    List parentList = [SELECT Id FROM Parent__c WHERE Id IN :Ids];

    Map parentMap = new Map();
    for(Parent__c thisParent : parentList) {
        parentMap.put(thisParent.Id, thisParent);
    }

    // This is our list of parents to finally update
    List parentsToSave = new List();
    
    // Finally we're ready to go through each child in the trigger and update it's parent

    for(Child__c thisChild : Trigger.new)
    {
        Parent__c par = parentMap.get(thisChild.ParentRef__c);
        par.Child_Status__c = thisChild.Status__c;
        parentsToSave.add(par);
    }

    // update the parents.
    update parentsToSave;

}

That's actually pretty hefty, it's a lot of maps and lists, and the SOQL query right in the middle there, just to update one field on a related object. I think this technique is a bastardisation of the Force.com Fundamentals teachings, which has emphasis on batchification, and in it's example, probably has a lot more cause to go through this process. For me though, this could be simplified by taking advantage of a simple Force.com fact:

If you create an instance of an sObject, and assign a valid record ID to it, you can update or upsert it exactly as if it was originally loaded to memory.

This means, that as we already have our parent object IDs in a reference field, we don't need to LOAD them, we can just conjure up new ones, update the relevant field, and update them. That makes the above trigger look like this:

trigger UpdateParent on Child__c (after insert, after update)
{
    // This is our list of parents to finally update
    List parentsToSave = new List();
    
    // Now we can just go through each child in the trigger "instantiate" it's parent, update and, update!

    for(Child__c thisChild : Trigger.new)
    {
        Parent__c par = new Parent__c();
        par.Id = thisChild.ParentRef__c;
        par.Child_Status__c = thisChild.Status__c;
        parentsToSave.add(par);
    }

    // update the parents.
    update parentsToSave;    
}

I can literally feel my governor limits squeeling with joy already!! No SOQL, half the script statements, a quarter of the lists and maps. Fantastic.

Merry Christmas from Desynit

I'm devastated to tell you that I wasn't in the office the day that this little productive gem was filmed, but all the same, Merry Christmas from Desynit and the Simon Lawrence Application Development Blog...

 

Don't forget to like Desynit on Facebook to make us feel all loved and popular, and if you so wish to know more about what I do (typically outside of programming) dig me up on twitter too.

Merry Christmas!

Outputting the Salesforce 18 character ID

Those familiar with Salesforce record IDs, and more specifically their use within the Salesforce API will probably know that they come in both 15 and 18 character variations.

The 15 digit ID, as seen in the URL of any record within Salesforce, is a case sensitive ID, and can be confidently used internally within your org for managing objects.

If you intend to use, load or manipulate records with an external program, for example, exporting data via reports or the API, you will probably need to use the 18 digit ID, which includes three extra "check digits" and is not case sensitive. It is important to remember, that functions like Excel's VLOOKUP are not case sensitive, nor, by default are MySQL queries.

There are a number of functions and tools available to manually calculate the last three characters, and a really brilliant explainantion of how the digits are calculated, and their use can be found on the Astadia blog post 15 or 18 Character IDs in Salesforce.com.

This isn't an ideal solution though, which leaves you thinking that there must be a simpler way to get the 18 digit ID out of the front end of your organisation. And of course, you can, and once you know how, it's actually incredibly simple!

All you need to do is create a new custom formula field on your object, give it a relevant name, set it's type to "text" and in the formula box enter:

CASESAFEID(Id)

and that's it! If you're feeling particularly lazy, it's even in the righthand box of "Functions" and you can just double click it to enter.

Save the field, alter your field level security settings, and add it to the relevant page layouts and this field will display the 18 digit ID on your Salesforce record.

Now when you want to test, or work, with your Salesforce records, as they will have been saved in external applications and data exports, you can grab the 18 character ID straight off your page layout.

Dreamforce 2012: Integrating PayPal Mass Payments with Force.com

"Welcome to Dreamforce 2012"

Everywhere you look at the moment in the Salesforce.com world, there are banners, blogs and news articles hailing the largest ever Enterprise IT conference.

It used to be held at the worlds biggest conference centre, the Moscone West in San Francisco; but now, it's held at the worlds biggest conference centre AND ten surrounding hotels and facilities. Not to mention closing off a few streets and booking out every hotel in the west of the city. With 70,000 attendees, and a gala headlined by the Red Hot Chilli Peppers, this is the CRM industry's flagship event.

So who wouldn't want to give a presentation there? Especially on such an awesome topic as combining one of the worlds most popular and accessible payment gateways with the worlds coolest CRM
(ok, it's just the inner-nerd in me that's getting so excited about those bits).

Welcome then to the supporting blog post to this Dreamforce 2012 developer track session:

Integrating PayPal Mass Payments with Force.com

If you are attending Dreamforce, you'll have access to the Chatter (touch!) session page here.

So what can you expect from this session? Well, having found this post, I can promise you will be well placed to take the most away from this presentation (and if you are here after the session, you will find this blog, along with what I presented an incredibly valuable combination towards understanding the process).

Firstly, let me link you up with the GitHub repository containing the integration code and demo files:

 https://github.com/srlawr/PaypalSFDC

Once I have clearance from Salesforce.com I will post the slides from the presentation up here too, but really, what you'll want is these two blog posts on the topic, which are the original works that landed me the Dreamforce presentation in the first place:

1) Salesforce - Paypal Masspay Integration

2) Salesforce - Paypal IPN integration

Working through these two blog posts should empower a talented developer to perform their own complete PayPal Mass Payments integration in a couple of days. If you don't have this kind of resource, or want to tap into my expert knowledge on the topic.. please get in touch with my employers Desynit, and I'm sure they will be more than happy to talk to you.

Certified Force.com Developer

I remember a time when I blogged about coding and solving technical problems with intelligent solutions, but now I seem to write more and more about qualifications and user-meetups.

Maybe I am becoming a consultant after all?

Well asides, because it's time for a new badge, and about time too. I have just taken and passed my Salesforce.com Certified Force.com developers exam. I have huge thanks to pass on to Christopher Lewis, a colleague with the qualification who helped me prepare, through conversations, debates and a wicked revision guide, and also to the boss himself who took the exam minutes before me (and passed) which boosted my confidence nicely.

So here's to DREAMFORCE 2012, and my Developer Session "Integrating PayPal Mass Payments with Force.com" - presented Friday September 21st 11:00 San Francisco time (7:00pm UK time) in the Developer Theatre.