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.