Learn more here : http://appinventor.googlelabs.com/about/

As a user of google spreadsheets I was very aware of performance issues when working with large data files and this new version of the application seems to boost performance and at least scrolling seems to work very well.

These are some great enhancements to the Google Docs suite and hopefully this brings more ideas for integrating Google Docs with Force.com through the Google Data API Toolkit.

Here’s a video with more info:

I just developed an Apex class for performing replace/merge operations on any kind of object, and yes any kind of relations as well! , so it doesn’t matter if you have master-detail relationships that can’t be modified, objects tied in a master-detail relationship will be cloned, deleted and inserted with the new values to simulate a merge operation!

To use the Merge class  just create an ObjectMerge instance, passing as an argument of the constructor your current record:

ObjectMerge oMerge = new ObjectMerge(SourceObject);

And to peform the merge operation just use the replaceRecord method and thats it!, you can specify if you want to delete the source record after the merge operation is done.

oMerge.replaceRecord(MergeToThisObjectID,DeleteSourceObject);

You can limit the number of records that will be processed in the merge operation for Master-Detail relations  to avoid hitting governor limits. The ObjectMerge class will let you know if there are any objects left, and if this is the case just continue performing the merge operation.

Force.com provides a merge DML operation but it’s only available for some of their standard objects, this class can help you get around that. There are still some limitations with this class due to governor limits in the number of describe calls but unless you have a large amount of objects related to the replaced/merged record it should work pretty well.

For now, the Object Merge class only merges/replaces custom objects related to your record, but this can be changed  in the class , however keep in mind that no more than 10 relations can be processed due to describe calls limitations so be careful when removing the custom objects limitation because there can be many Non-Custom objects related to your record.

I’ll leave a link in this post to the files but for now here’s an example of how to use the ObjectMerge class in a VisualForce controller that merges contacts, if you have custom objects tied a contact A and want to merge contact A to Contact B you will see how the ObjectMerge class changes all of the objects from contact A to contact B then deletes contact A. Remember, you can try it with any custom object   Enjoy!

Download the files from here –> ObjectMerge

(NOTE: There’s a bug with the code viewer plug-in, please ignore the second viewer)

I came across a blog post at gokubi.com (http://gokubi.com/archives/two-interesting-ways-to-architect-apex-triggers) about some interesting ways of architecting Apex Triggers.

We have developed a lot of logic in Apex Triggers and ended with some really nasty code in some scenarios; this post got me thinking about new ways to architect triggers using a more object-oriented approach. So just to follow the thoughts in this post I’ll show you what I did to organize our triggers and it has been working pretty good so far.

NOTE: Please refer to the code section below

//Step 1

I started by creating an Apex Class to replicate some of the triggers functionality…

//Step 2

The next step will be to start coding our Apex Class that will perform all of the logic in our triggers, so let’s say the we are building a trigger for My_Object__c custom object.

//Step 3

And finally, we just need to create the Apex Triggers that will just initialize our Trigger class and initialize an instance of the corresponding Apex Class that will handle all of the logic.

And that’s it! Just remeber to cast the the collections correctly before accessing the collections from the ExtTrigger class because we can’t work with generic sobject collections.

Some of the benefits that I’ve seen by organizing Apex Triggers in this way are the following:

• 100% Test Coverage in Apex Triggers (although all of the Test Coverage should be done in the handler Apex Class)
• Since we can call functions to perform specific actions in Apex Classes, we end up with more organized code, it’s easier to read in the sense that you can just go to see the calls inside the “onBeforeInsert” section for example..
• Avoid the max number of characters governor limit:
  • Maximum number of characters for a class: 100,000
  • Maximum number of characters for a trigger: 32,000

Thanks to everyone that posted in gokubi’s blog post any feedback on this is appreciated

For more information go to: http://developer.force.com/releases/release/Spring10

Here’s a small demo of how code scheduler works:

This platform as a service concept is new for me and I think it offers great advantages in matters of development & deployment time,acquisition and maintenance costs of hardware & software. And now, with Visualforce, it gives developers the ability to follow the Model-View-Controller Design Pattern in order to have data models, business logic and user interface in different layers.

I’ll post more information about how to work on each of these layers and maybe show some code of examples that i come to write in this platform.

For more info, check out salesforce.com

The purpose of the component is to enable autocomplete in lookup fields. I used the autocomplete js created by Jim Roos:
(http://www.jimroos.com/2007/05/ajax-autocomplete.html) but made some modifications to it so that it could interact with an Apex controller among some other things…

So my idea was that if you were making a VF page that had an inputfield that was related to a lookupfield you would just insert this autocomplete component to that inputfield.

Something like this:

<apex:inputField value=”{!Contact.accountid}” id=”accname” styleClass=”cField”>

<c:autocomplete ObjectName=”Accounts” InputId=”{!$Component.accname}”

AutoCompleteId=”accACid” ClassName=”autocomplete300″/>

</apex:inputField>

The component has 4 parameters:

The name of the object or custom object that the inputfield relates to (new objects must be added inside the apex classes since i had some problems constructing a dynamic query).
The InputId which is used to relate the component to the input field
The id for the Component
A classname parameter that basically just defines the width of the suggestions menu.

Here’s a screenshot of how it looks like in action:

Here’s a link to the file containing the required files:

AutoCompleteComponent