Advanced Apex Programming for Salesforce.com and Force.com
Format: PDF / Kindle (mobi) / ePub
Beyond the Force.com documentation - Third edition
Advanced Apex Programming for Salesforce.com and Force.com is neither a tutorial nor a book for beginners. Intended for developers who are already familiar with the Apex language, and experienced Java and C# developers who are moving to Apex, this book starts where the Force.com documentation leaves off.
Instead of trying to cover all of the features of the platform, Advanced Apex programming focuses entirely on the Apex language and core design patterns. You’ll learn how to truly think in Apex – to embrace limits and bulk patterns. You’ll see how to develop architectures for efficient and reliable trigger handling, and for asynchronous operations. You’ll discover that best practices differ radically depending on whether you are building software for a specific organization or for a managed package. And you’ll find approaches for incorporating testing and diagnostic code that can dramatically improve the reliability and deployment of Apex software, and reduce your lifecycle and support costs.
Based on his experience as a consultant, Salesforce MVP and architect of major AppExchange packages, Dan Appleman focuses on the real-world problems and issues that are faced by Apex developers every day, along with the obscure problems and surprises that can sneak up on you if you are unprepared.
This third edition contains updates through Summer 15 (API 34) along with significant new content on asynchronous design patterns, optimization and maintaining Apex applications.
book is all about thinking in Apex. There’s a tendency, when coming to Apex from other languages, to think of it as a familiar language, where limits are just one of those quirky things to consider when programming, just as every other platform has its little quirks. Then one day, when you run up against those limits, they suddenly become an annoying obstacle, and you find yourself cursing Salesforce.com for building them into the system and getting in your way, even though you intellectually
ahead and add the revised object into the map. contactmap.put(sameContacts[x], x); } As this assert shows, entering the modified object caused a new entry to exist in the map. The contactmap size is now 10. system.assertNotEquals(contactmap.size(),5); } You can see this same phenomena with sets as well in the FunWithCollections.objectSets example in the sample code. Apex uses a hash of the field values as the internal value to use when searching for the object in the map or set. Changing a
wait in turn until it either obtains an AsyncRequest__c record or times out. However, as it turns out, all of those queries blocking each other impose quite a load on the system, and Salesforce operations really frowns upon that. So this scenario will likely prompt a nasty Email from them complaining that you are using too many system resources and cause them to place a delay on queueable apex in that org. The approach shown here avoids that problem by making sure that you don’t add a new
setting that StartTime field. The only trick would be to make sure someone or something enqueued the Apex job for the next pending request. That remains the legitimate task of scheduled Apex. Going Asynchronous with Scheduled Apex Scheduled Apex provides a mechanism to schedule an Apex class to run at a set time. It has a rather interesting history. Originally, it was advisable to avoid using scheduled Apex. This is because when you had a class scheduled using scheduled Apex, it was
synchronize access. Which is a good thing; given that Apex has no real synchronization objects. But if Apex eliminates some design patterns that are common in other languages, it offers some new ones that are essential for every Apex developer to understand. Maintaining Data Across Trigger Invocations Earlier in this chapter, you saw an example of how a static variable could be used to remember that you had already executed the code in an after-update trigger. Here’s another common