The programming language of Google Apps Script is JavaScript (ECMAScript). JavaScript is a very flexible and forgiving language which suits us perfectly, and there's also a surprising amount of depth and power in the language. To help users get into some of the more useful power features we're starting a series of articles introducing some more advanced topics.
Let's say we want to create an object that counts the number of occurrences of some event. To ensure correctness, we want to guarantee the counter can't be tampered with, like the odometer on your car. It needs to be "monotonically increasing". In other words, it starts at 0, only counts up, and never loses any previously counted events.
Here's a sample implementation:
Counter = function() { this.value = 0; };
Counter.prototype = { get: function() { return this.value; }, increment: function() { this.value++; } };
This defines a constructor called Counter which can be used to build new counter objects, initialized to a value of zero. To construct a new object, the user scripts counter = new Counter(). The constructor has a prototype object, providing every counter object with the methods counter.increment() and counter.get(). These methods count an event, and check the value of the counter, respectively. However, there is nothing to stop the script from erroneously writing to counter.value. We would like to guarantee that the counter's value is monotonically increasing, but lines of code such as counter.value-- or counter.value = 0 roll the counter back, breaking our guarantee.
Most programming languages have mechanisms to limit the visibility of variables. Object-oriented languages often feature a private keyword, which limits a variable's visibility to the code within the class. Such a mechanism would be ideal here, ensuring that only the methods counter.increment() and counter.get() could access value. Assuming that these two methods are correctly implemented, we can be sure that our counter can't get rolled back.
Javascript has this private variable capability as well, despite not having an actual keyword for it. Let's examine the following code:
Counter = function() { var value = 0; this.get = function() { return value; }; this.increment = function() { value++; }; };
This constructor gives you objects that are indistinguishable from those built with the first constructor, except that value is private. The variable value here is not the same variable as counter.value used above. In fact, the latter is undefined for all objects built with this constructor.
How does this work? Instead of making value a member variable of the object, it is a local variable of the constructor function, by use of the var keyword. The get and increment functions are the only functions that can see value because they are defined within the same code block. Only code inside this block can see value; outside code does not have access to it. However, these methods are publicly visible by having been assigned to the this object.
Limiting visibility of variables is considered a good practice, because it rules out many buggy states of your program. Make sure to use this technique wherever possible.
Cross-posted from Google Apps Script Blog
by: Jason Ganetsky, Software Engineer, Google Apps Script
Editor's Note: Jeff Bonforte is CEO at Xobni. Xobni gives you instant access to email, contact information, conversations and attachments that are often lost in exploding inboxes. Xobni has leveraged Gmail Contextual Gadgets to make your email more responsive. We invited Xobni to share their experience with the Gmail Contextual Gadgets.
The new Gmail contextual gadgets platform announced at I/O last month is bringing renewed innovation to the inbox. Using this new simple but powerful platform, developers can write new innovative gadgets for users of Google Apps and Gmail. But to offer the same gadgets to Outlook’s 600 million users, a developer would need to do quite a bit of extra work.
They would need to be very familiar with COM, know about CBT hooks, have mastery of runtime callable wrappers (RCWs) and Outlook’s primary interop assembly (PIA). They should know MAPI inside and out. They should be experts in Windows forms and Redemption. They should understand the requirements of the new 64-bit support needed for Outlook 2010. They should understand the nine APIs of Outlook, including OOM (introduced in 2007) and OSC (introduced in 2010). They should develop in .Net, and have a massive variety of QA virtual machines running every version of Win XP to Win 7, with every version and service pack of Outlook 2003 to 2010, including a large variety of the top 400 add-ins to Outlook, and every version of Redemption (running with each version installed in various order to trap on likely conflicts).
And even the most experienced engineer in these technologies will need to reference Charles Petzold’s seminal Programming Windows 95 (out of print, 1996, Microsoft Press) and De la Curz Thaler’s Inside MAPI (out of print, 1996, Microsoft Press).
Given these non-trivial hurdles, we were pretty sure most developers would forgo the opportunity to offer their clever new gadgets to Outlook’s millions of users. That is a shame.
So we got on the case to bring this innovation from Gmail gadget developers to Outlook users. Enter Xobni.
Xobni, (“inbox” spelled backwards) is a San Francisco startup that offers and easier and better way to manage the people and information in email and on your phone. Our free Outlook search and contact manager add-in for Outlook has been downloaded over five millions times in the last two years. We focused early on Outlook for two simple reasons: size and pain.
When the team at Google called to encourage us to bring our Xobni app to Gmail in time for Google I/O, we were thrilled. It has long been the #1 request of our customers…and engineers. It didn’t take much work for us to realize the simplicity and power of this platform. In fact, we had our first gadget for Hoover’s business information written in about a day. Though we are excited to write gadgets, we wanted to do something bigger. We wanted Gmail gadgets to run natively for the millions of people using Outlook.
So we set out to port over Google’s platform to Outlook in a ridiculously short amount of time. The first step was to get Google on board. We weren’t sure what to expect from them when we explained our plan. The first response we got from the Google team was puzzlement. Why and how would we do this? In a short amount of time, Google’s mood progressed from quiet to excited (phew). So we set up the war room in the office, cleared our calendars and weekends for the foreseeable future and started cranking away. (And, yes, even with our Outlook expertise, we frequently referenced Programming Windows 95 and Inside MAPI along the way.)
The result: Developers can now write one application for Gmail contextual gadgets and will soon deploy not just to the millions of Gmail users, but also to the millions of Outlook users: the same code available in both worlds. Thanks to Google’s simple but powerful platform (and the hard work of Xobni’s engineers), you just write your gadgets for Gmail and they are ready to be used in Outlook as well.
Want to get started? Download the Xobni for Outlook Developer Preview today. It includes a “Welcome Gadget” with sample code, so you can see your Gmail gadgets in Outlook. We plan to release an updated version of Xobni that will allow end users to start enjoying your gadgets.
We’d love to hear from you. Let us know what you think and how we can continue to make email a better place to be.
Author: Jeff Bonforte, CEO Xobni
Following up on our recent post about the new Doc List capability in Google Apps Script, we thought we’d take a moment to look a little more closely at another new feature in Apps Script - integration with Google Maps. Google Maps has had an API for quite some time, but now we’ve made it very easy to generate customized maps and driving directions straight from a script.
A mail merge is often used to automate some of the drudgery involved in sending invitations to a large number of people. With the new Apps Script Maps Service you can easily add a map image to the email, and even add a marker showing the event location.
While that’s nice, it’s hardly a time saver - why write code to generate the same image repeatedly? A much more useful feature is generating a custom map for each guest, along with personalized driving directions. We’ve made a spreadsheet template that includes just such a script - it’s available here.
Let’s look at a short code snippet that illustrates the calls required to generate a map image and add a marker at the start and end addresses:
function getMap (start, end) {
// Generate personalized static map.
var directions = Maps.newDirectionFinder()
.setOrigin(start)
.setDestination(end)
.getDirections();
var map = Maps.newStaticMap().setSize(500, 350);
map.setMarkerStyle(Maps.StaticMap.MarkerSize.MID, "red", null);
map.addMarker(start);
map.addMarker(end);
return map.getMapUrl()
}
Running the function with start and end set to Google, San Francisco and Google, Mountain View, we get a link to the following image:
Along with generating maps images, the Maps feature can also find directions, retrieve elevation data and even perform some geocoding operations. Please note that any data returns by these APIs should not be used without displaying an associated map image - see the Google Maps API Terms of Service for more details.
Posted by Evin Levey, Google Apps Script Product Manager
