Posted by Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps

Seasons greetings! In case you missed it last week, the Google Drive team announced the release of the next version of their API. Today, we dig deeper into details about the release with developers. In the latest edition of the Launchpad Online developer video series, you'll get everything you need to know about the new release (v3), as well as its relationship with the previous version (v2).

This jam-packed episode features an introduction to the new API, an interview with a Google Drive engineer about the API design and a code walkthrough of real source code you can use today (as with all my Launchpad Online episodes). This time, it's a command-line script that performs Google Drive file uploads and downloads, presented first in v2 followed by a how-to segment on migrating it step-by-step to v3. In addition, the uploading segment includes the option of converting to Google Apps formats while the download portion covers exporting to alternative formats such as PDF®.

To get started using the Drive API, check out the links to the official documentation above (v2 or v3) where you’ll also find quickstart samples in a variety of programming languages to the left. For a deeper dive into both Python code samples covered here, including v3 migration, start with the first of two related posts posted to my blog.

If you’re new to the Launchpad Online, we share technical content aimed at novice Google developers -current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!

Posted by Matt Hessinger, Project Specialist, Google Apps Script

Welcome to our 100th blog post on Apps Script! It’s amazing how far we’ve come from our first post back in 2010. We started out highlighting some of the simple ways that you could develop with the Apps platform. Today, we’re sharing tips and best practices for developing more complex Apps Script solutions by pointing out some community contributions.

Apps Script and modern development

The Apps Script editor does not allow you to use your own source code management tool, making it a challenge to collaborate with other developers. Managing development, test, and production versions of a project becomes very tedious. What if you could have the best of both worlds — the powerful integration with Google’s platform that Apps Script offers, along with the development tooling and best practices that you use every day? Now, you can.

npm install -g node-google-apps-script

This project, “node-google-apps-script”, is a Node.js based command-line interface (CLI) that uses Google Drive API to update Apps Script project from the command line. You can view the node package on the NPM site, and also view the GitHub repo. Both links have usage instructions. This tool was created by Dan Thareja, with additional features added by Matt Condon.

Before using the tool, take a look at the Apps Script Importing and Exporting Projects page. There are a few things that you should be aware of as you plan out your development process. There are also a few best practices that you can employ to take full advantage of developing in this approach.

There is a sample project that demonstrates some of the practices described in this post: click here to view that code on GitHub. To get all of the Apps Script samples, including this import/export development example:

git clone https://github.com/google/google-apps-script-samples.git
The sample is in the “import_export_development” subdirectory.

Your standalone Apps Script projects live in Google Drive. If you use a command-line interface (CLI) tool like the one linked above, you can work in your favorite editor, and commit and sync code to your chosen repository. You can add tasks in your task runner to push code up to one or more Apps Script projects, conditionally including or excluding code for different environments, checking coding style, linting, minifying, etc. You can more easily create and push UI-related files to a file host outside of Apps Script, which could be useful if those same files are used in other apps you are building.

Typical development tools, integrated with Apps Script via the Drive API

Apps Script Project Lifecycle Best-practices

In addition to the information on the Importing and Exporting Projects page, here are a few things to consider:

• Your local file set is the master. If you add, delete or rename files locally, the next upload with either of the linked tools will automatically make the Apps Script project reflect your local file set.
• You can name local files whatever you want. You just need to then append “.html” to any client-side “.js” or “.css” in a file staging task before uploading to your project. The tool referenced above treats any “.js” files that you stage for upload as Apps Script server script files (“.gs” in the editor). It treats any “.html” that you stage as “client” code that you’ll access via the HtmlService. This means that you can develop server scripts as JavaScript, with the “.js” extension, so that your local tools recognize JavaScript syntax. While developing, client-side code (i.e., code that you need to interact with via the HtmlService) can be “.html”, “.js”, or “.css”, allowing your editor to provide the right syntax highlighting and validation experience.

Over and above the editing experience, the biggest improvements you get by working outside the script editor is that you are no longer locked into working in just one Apps Script project. You can much more easily collaborate as a team, with individual developers having their own working Apps Script projects, while also having more controlled test, user acceptance and production versions, each with more process and security. Beyond just the consistency with other normal project practices, there are a few Apps Script specific ways you can leverage this multi-environment approach.

If you are going to use this approach, here are three best practices to consider:

• Use specific configuration values for “local” development.
• Build test methods that can run standalone.
• Include dependencies for development and testing.

Best practice: Use specific configuration values for “local” development.

The provided sample shows a simple example of how a base configuration class could allow a developer to inject their local values for their own debugging and testing. In this case, the developer also added the annotation @NotOnlyCurrentDoc, which tells Apps Script that they need the full scope for Drive API access. In this project, the “production” deployment has the annotation @OnlyCurrentDoc, which leads to the OAuth scope that is limited to the document associated with script running as Sheets, Docs, or Forms add-on. If you add a standard file pattern to the source project’s “ignore” file, these developer-specific files will never get into the actual codebase.

Benefits for your project — Production can have more limited OAuth scopes, while a developer can use broader access during development. Developers can also have their own personal configuration settings to support their individual development efforts.

Best practice: Build test methods that can run standalone.

While there is no current way to trigger tests in an automated way, you still may want to author unit tests that validate specific functions within your projects. You’ll also likely have specific configuration values for testing. Once again, none of these files should make it into a production deployment. You can even use the Apps Script Execution API to drive those tests from a test runner!

Benefits for your project — You can author test functions, and keep them separate from the production Apps Script file. This slims down your production Apps Script project, and keeps the correct OAuth scopes that are needed for production users.

Best practice: Include dependencies for development and testing.

If you are developing an add-on for Sheets or Docs, and you expect to have an “active” item on the SpreadsheetApp. However when you are developing or testing, you may be running your Apps Script without an “active” context. If you need to develop in this mode, you can wrap the call to get the current active item in a method that also can determine what mode you are running in. This would allow your development or test instance to inject the ID of an “active” document to use for testing, while delegating to the getActive* result when running in a real context.

Benefits for your project — You can integrate better unit testing methodologies into your projects, even if the end deployment state dependents on resources that aren’t typically available when debugging.

Wrapping up

You now have the option to use your own development and source management tools. While you still do need to use the Apps Script editor in your application’s lifecycle — to publish as a web app or add-on, configure advanced services, etc. — taking this step will help you get the most out of the power of the Apps Script platform. Remember to check out Apps Script on the Google Developers site to get more information and samples for your Apps Script development.

If you happen to use python tools on the command line to facilitate your team’s build process, you can check out Joe Stump's python-gas-cli. You can view the package info here or the GitHub repo where you’ll also find usage instructions.

Here are some additional reference links related to this post:

• node-google-apps-script on NPM
• Importing and Exporting projects
• The Apps Script Execution API
• OAuth scoping to the current document/sheet

Posted by Andrew Garrett, Software Engineer, Classroom API and Michael Stillwell, Developer Advocate, Google Apps

By popular developer request, the Classroom Share Button now supports JavaScript callbacks and a question post type (in addition to announcements and assignments).

The following callbacks are supported:

• onsharestart is called immediately after the user clicks the share button
• onsharecomplete is called after the user successfully shares the URL to their class

The callbacks are supported by both the share tag and the JavaScript API, and they work on all supported browsers except Internet Explorer.

What can you use this for? There's a bunch of different things you can do, but to get you started, here are some suggestions:

• Analytics and reporting How frequently is the share button used? What's the most frequently shared URL across the site?
• Shared URL history Store the list of URLs a user has shared, to provide a customized and more engaging site.
• Contextual help The first time a user shares a link back to your site, explain what happened and what they should expect to see next.
• A/B testing Are many users starting a share action, but failing to finish?

Finally, if you want to fully control the appearance and behavior of the share button (and don't need the callbacks), you can customize the Classroom icon (as long as it still meets our branding guidelines) and initiate the share via a URL of the form:

https://classroom.google.com/share?url=https://foo.com/

As ever, please continue asking questions (or answering them!) on StackOverflow (use the google-classroom tag) and report bugs and feature requests via the Classroom API bug tracker.

Posted by Muzammil Esmail, Product Manager, Google for Work and Wesley Chun, Developer Advocate, Google Apps

Over the years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new services offer developers improvements over previous functionality and introduces new features that help Apps administrators better manage their domains.

To deliver even more granular control, today we are announcing the new Calendar Resource API as part of the Admin SDK’s Directory API that enables Google for Work customers to manage their physical resources, like conference rooms, printers, nap pods, tennis courts, walkstations, etc. These physical resources can be added to meetings by end users as needed. The API released today replaces the GDATA Calendar Resource API, so we encourage developers to begin moving their applications and tools to the new API. Please note that we will begin deprecation in January 2016 and sunset the existing API in January 2017. Stay tuned for a formal deprecation announcement with details.

Posted by Dan McGrath, Product Manager, Google Drive

Today, version 3 (v3) of the Google Drive API is available, providing developers with a leaner, faster by default, and more consistent interface to Google Drive. This latest update is designed to be easier for developers who are integrating with Drive for the first time.

In the time since we launched the original version of the Drive SDK, we’ve learned a lot about how developers are using our API and the pitfalls they’ve encountered. This version simplifies the API in several ways, including:

• Reducing the number of collections developers need to understand
• Removing some duplication
• Cleaning up method and property names to be more consistent
• Setting defaults that are faster and more efficient

For example, our files.list call now only includes the most commonly used fields that we serve efficiently by default, with additional fields able to be added via the fields parameter. This makes the default call nearly 6X faster in v3 than in v2:

While future versions of the API will be more feature-focused, this release provides improved performance and ease of use over the previous version of the API (v2). We will continue to support both versions so that existing apps using v2 can run without changes (developers don’t have to upgrade). For developers with a v2 app who want to take advantage of the new improvements, we’ve got a handy cheat sheet to help with migration.

To get started using the new version of the API, check out the developer docs; and for any questions, find us with the google-drive-sdk tag on StackOverflow. We look forward to seeing what you’ll build with the new API!

Posted by Rishi Dhand, Product Manager, Google Apps Admin SDK and Wesley Chun, Developer Advocate, Google Apps

In a Google Apps domain, Admin role management (i.e. create, assign, and update admin roles) is a critical function for super admins that helps them distribute admin responsibilities in a more secure manner. Until now, this functionality was only available via the Admin console UI.

This is what Role management looks like in the Admin console, but now you can also do this programmatically with the Roles API.

Today’s launch of the Roles API (one of the Admin SDK Directory APIs) enables developers to build admin tools that can perform role management programmatically.

This new API will be useful to admins who have either built internal admin tools using the Admin SDK, or developers of third-party admin tools. Both can now use the Roles API to provide selective access to Delegated Admins (DAs) to specific admin capabilities within third-party applications.

Here are some examples of use cases where the Roles API can be leveraged:

• A third-party user management app that relies on the Admin SDK to perform various user related operations can now use the Roles API to selectively show the capabilities of User management DAs, such as creating/deleting users or resetting passwords.
• A mobile device management (MDM) app developer looking to build a tool for access by Mobile Management DAs can use the Roles API to determine the privileges of the logged-in DA and selectively display MDM related admin functionality.
• Admins (or admin tools) can now programmatically create reports on admin role assignments which can help super admins better manage access to DAs.

For more information and to get started, please check out the Roles API documentation. We look forward to helping more admins manage their domains in a more programmatic way so they can focus on more critical aspects of managing their corporate IT infrastructure.

Posted by Saurabh Gupta, Product Manager, Google Apps Script

Back in December 2014, we announced the IFRAME sandbox mode for HtmlService which has helped improve the speed of an application’s user interface (UI). It also gives users a choice of using a variety of JS libraries on the client. We have been working hard to improve IFRAME sandbox mode and have added many features since then, including: Firefox support, file uploads, top navigation support, and improved Google Picker API support. Since IFRAME sandbox provides faster UIs and has more capabilities than NATIVE and EMULATED modes, developers should only be using IFRAME sandbox mode moving forward.

As of today, both EMULATED and NATIVE modes in HtmlService are deprecated. Over the next few months, we plan on sunsetting both EMULATED and NATIVE modes in stages to give you enough time to migrate your scripts.

We have created a migration guide to help you with this transition. For many scripts, no changes will be needed, unless they use a small set of features described in the migration guide. The guide also describes a few potential breaking changes. It is important that you review all your scripts that use HtmlService to ensure that the switch to IFRAME sandbox mode does not cause them to fail.

Here’s the timeline:

In November 2015, all new scripts will default to IFRAME sandbox mode unless NATIVE mode is explicitly specified. For example, if you make a copy of an existing script, the new script will use IFRAME sandbox mode unless you have explicitly set the sandbox mode to NATIVE.

In December 2015 (see sunset schedule for exact dates), EMULATED mode will be shutdown. Any scripts explicitly using EMULATED mode will default to IFRAME sandbox mode.

On April 28th, 2016, all scripts will default to IFRAME sandbox unless you have explicitly specified NATIVE mode in your script. For example, if your script has not specified any mode, then it will change from using NATIVE mode to IFRAME sandbox mode. Please make sure that your UI works well in IFRAME sandbox mode.

On June 30th 2016, NATIVE mode will be shutdown. All scripts explicitly using NATIVE mode will default to IFRAME sandbox mode.

While deprecations may at times seem inconvenient, this staged deprecation should ease in the migration process. Our goal is to provide a modern and secure environment enabling developers to create great apps for their users with Google Apps Script.

Originally posted on the Google Developer blog

Posted by Wesley Chun, Developer Advocate, Google Apps

Happy Monday! Have you ever been asked by your boss to do something simple (good) but long and tedious (bad)? Take for example, the simple task of counting up all of the YouTube views for your corporate videos and your competitors’. It doesn’t even have to be your boss. What if you and your gamer friends are competing to see whose gameplay clips are garnering the most attention? It’s easy to manually track ten videos, but how about 100 or even 1,000? While simple -- you can visit the YouTube to grab the view count for each video -- you know the real problem with a task like this is that you don’t scale with the amount of content, so it’s better to automate with a simple app instead. This is the exact scenario that my colleagues and I set out to address in the latest episode of the Launchpad Online, introducing users to a pair of Google developer tools that can help solve this particular problem:

The first developer tool covered is the YouTube Data API. You can access it like most modern Google APIs from your preferred programming environment using one of the Google APIs Client Libraries. However, this type of data generally lives in a spreadsheet, and if you’re using Google Sheets, you can instead write the app with Google Apps Script, a JavaScript environment running in Google’s cloud that, if authorized, can write that video information to the cells in your Sheet. YouTube is just one of the many supported services available to Apps Script developers.

As with all my Launchpad Online episodes, I walk you through a short code snippet (only eight lines this time) that will get you started building your own custom solution. If you’re new to the developer series, we share technical content aimed at novice Google developers… current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!

Posted by Sushmit Goswami, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Apps

To provide developers and administrators with more fine-grained control, the Google Apps Admin SDK now includes new domain management features. These new APIs let you programmatically manage domains for your Google Apps account, similar to other RESTful resources like Users, Groups, etc., providing a superset of the domain management capabilities available on the Domains page in the admin console today.

Change your primary domain

The Customers API gives enterprise developers and administrators the ability to swap the current primary domain with a selected secondary domain for a Google Apps installation. The “change primary” operation is essentially transparent to the user, but users moved to the secondary domain will be subject to certain restrictions (refer to Help Center article for details). Customers who want to rebrand their business with a new primary domain can follow this up by renaming users from the old (now secondary) to the new (now primary) domain using the Users API.

Add and remove domains & aliases

The Domains API lets developers create tools for administrators to add and remove domains, similar to the functionality available on the Domains page in the admin console. In addition, the API lets you programmatically add aliases for any domain, primary or secondary, but aliases for secondary domain can only be added via the API.

Posted by Edward Jones, Software Engineer, Google Apps Script and Wesley Chun, Developer Advocate, Google Apps

Have you ever wanted a server API that modifies cells in a Google Sheet, to execute a Google Apps Script app from outside of Google Apps, or a way to use Apps Script as an API platform? Today, we’re excited to announce you can do all that and more with the Google Apps Script Execution API.

The Execution API allows developers to execute scripts from any client (browser, server, mobile, or any device). You provide the authorization, and the Execution API will run your script. If you’re new to Apps Script, it’s simply JavaScript code hosted in the cloud that can access authorized Google Apps data using the same technology that powers add-ons. The Execution API extends the ability to execute Apps Script code and unlocks the power of Docs, Sheets, Forms, and other supported services for developers.

One of our launch partners, Pear Deck, used the new API to create an interactive presentation tool that connects students to teachers by converting slide decks into interactive experiences. Their app calls the Execution API to automatically generate a Google Doc customized for each student, so everyone gets a personalized set of notes from the presentation. Without the use of Apps Script, their app would be limited to using PDFs and other static file types. Check out the video below to see how it works.

Bruce McPherson, a Google Developer Expert (GDE) for Google Apps, says: “The Execution API is a great tool for enabling what I call ‘incremental transition’ from Microsoft Office (and VBA) to Apps (and Apps Script). A mature Office workflow may involve a number of processes currently orchestrated by VBA, with data in various formats and locations. It can be a challenge to move an entire workload in one step, especially an automated process with many moving parts. This new capability enables the migration of data and process in manageable chunks.” You can find some of Bruce’s sample migration code using the Execution API here.

The Google Apps Script Execution API is live and ready for you to use today. To get started, check out the developer documentation and quickstarts. We invite you to show us what you build with the Execution API!

Posted by Muzammil Esmail, Product Manager, Google for Work

Google Apps users generate a lot of content at work—project plans, design documents, client presentations, and more. Many of these files are still relevant to an employee’s company or team even after he or she has left or transferred internally. The new Data Transfer API will make it easier for developers to build tools that will allow admins to better manage their end-user data, specifically apps that can transfer ownership of Google Docs, Sheets, and Slides, and all the other Google Drive files as well as Google+ pages in your Google for Work account—in bulk—from one employee/end-user to another using the API.

In July, we introduced the Data Transfer privilege, which makes it easier for admins to transfer data ownership. That same privilege is leveraged by the Data Transfer API. When enabled, it allows admins to programmatically migrate file ownership anytime they want using the API—provided they’ve enabled API access. In order to transfer ownership of Google Drive content as well as Google+ pages, super admins will need to grant/delegate the Data Transfer privilege to admins before end-user content can be migrated programmatically (via API or 3rd-party tools) or from the admin console.

This is what User Deletion looks like in the Administration console,
but now you can also do this programmatically with the API.

To get started with the Data Transfer API, take a look at the developer documentation. Keep in mind that while this programmatic feature is new, admins can still transfer user data manually from the admin console. For more general information, see the Help Center pages on transferring file ownership on Google Drive and how to delete a user.

Originally posted on the Google Developers Blog.

Posted by Wesley Chun, Developer Advocate

Have you ever booked a dining reservation, plane ticket, hotel room, concert ticket, or seats to the game from your favorite app, only to have to exit that booking app to enter the details into your calendar? It doesn’t make for a friendly user experience. Why can’t today’s apps do that for you automatically?

In case you missed it the episode 97 of #GoogleDev100 the other week, I aim to inspire how app developers can streamline that process with the help of the Google Calendar API. A short Python script, anchored by the following snippet, is illustrated to show developers how easy it is to programmatically add calendar events:

CALENDAR = apiclient.discovery.build('calendar', 'v3', http=creds.authorize(Http()))
GMT_OFF = '-07:00' # PDT/MST/GMT-7
EVENT = {
    'summary': 'Dinner with friends',
    'start': {'dateTime': '2015-09-18T19:00:00%s' % GMT_OFF},
    'end':   {'dateTime': '2015-09-18T22:00:00%s' % GMT_OFF},
    'attendees': [
        {'email': 'friend1@example.com'},
        {'email': 'friend2@example.com'},
    ],
}
CALENDAR.events().insert(calendarId='primary', body=EVENT).execute()

For deeper dive into the script, check out the corresponding blogpost. With code like that, your app can automatically insert your relevant events into your users’ calendars, saving them the effort of manually doing it themselves. One of the surprising aspects is that a limited set of actions, such as RSVPing, is even available to non-Google Calendar users. By the way, inserting events is just the beginning. Developers can also delete or update events instantly in case that upcoming dinner gets pushed back a few weeks. Events can even be repeated with a recurrence rule. Attachments are also supported so you can provide your users a PDF of the concert tickets they just booked. Those are just some of the things the API is capable of.

Ready to get started? Much more information, including code samples in Java, PHP, .NET, Android, iOS, and more, can be found in the Google Calendar API documentation. If you’re new to the Launchpad Online developer series, we share technical content aimed at novice Google developers… the latest tools and features with a little bit of code to help you launch that app. Please give us your feedback below and tell us what topics you would like to see in future episodes!

Posted by, Chris Han, Product Manager Google Apps Marketplace

The Google Apps Marketplace brings together hundreds of third-party applications that integrate with and enhance Google Apps for Work. It’s a great place to get discovered by more than five million Google Apps customers. Many of these customers depend on Google Apps Marketplace to find the solutions their organizations need, driving millions of users to the top listed apps.

Today, we’ve launched a brand new Google Apps Marketplace site aimed to improving discoverability and getting your app installed by even more customers. No need to do anything if you’ve already listed your app publicly on Google Apps Marketplace. Your app will appear on the new site automatically.

If you haven’t listed your app yet on Google Apps Marketplace, follow these instructions to get started!

Posted by Dan McGrath, Product Manager, Google Drive

Beginning August 31st, 2015, web hosting in Google Drive for users and developers will be deprecated. You can continue to use this feature for a period of one year until August 31st, 2016, when we will discontinue serving content via googledrive.com/host/[doc id].

In the time since we launched web hosting in Drive, a wide variety of public web content hosting services have emerged. After careful consideration, we have decided to discontinue this feature and focus on our core user experience.

For those who have used Drive to host websites, Google Domains can refer you to third parties for website hosting functionality.

For those who use this feature to serve non-user content to web and mobile applications, Google Cloud Platform offers a better-performing solution.

Editor's note: Posted by Romain Vialard, a Google Developer Expert and developer of Yet Another Mail Merge, a Google Sheets add-on.

Yet Another Mail Merge is a Google Sheets add-on that lets users send multiple personalized emails based on a template saved as a draft in Gmail and data in a Google Sheet. It can send hundreds of emails, but this kind of operation usually takes a few minutes to complete. This raises the question: what should be displayed in the user interface while a function is running on server side for a long time?

Real-time notifications in Add-ons

Firebase is all about real-time and became the answer to that issue. Last December, the Apps Script team announced a better version of the HtmlService with far fewer restrictions and the ability to use external JS libraries. With Firebase, we now had a solution to easily store and sync data in real-time.

Combined, users are able to know, in real-time, the number of emails sent by an Apps Script function running server-side. When the user starts the mail merge, it calls the Apps Script function that sends emails and connects to Firebase at the same time. Every time the Apps Script function has finished sending a new email, it increments a counter on Firebase and the UI is updated in real-time, as shown in the following image.

Implementation

Inside the loop, each time an email is sent (i.e. each time we use the method GmailApp.sendEmail()), we use the Apps Script UrlFetch service to write into Firebase using its REST API. Firebase's capabilities makes this easy & secure and there’s no need for an OAuth Authorization Flow, just a Firebase app secret, as shown in the following example:

function addNewUserToFirebase() {
  var dbUrl = "https://test-apps-script.firebaseio.com";
  var secret = PropertiesService.getScriptProperties().getProperty("fb-secret");
  var path = "/users/";
  var userData = {
    romainvialard:{
      firstName:"Romain", 
      lastName:"Vialard",
      registrationDate: new Date()
    }
  };
  var params = {
    method: "PUT",
    payload : JSON.stringify(userData)
  }
   UrlFetchApp.fetch(dbUrl + path + ".json?auth=" + secret, params);
}

On the client side, thanks to the improved Apps Script HtmlService, we can use the official JS client library to connect to Firebase and retrieve the data stored previously. Specifically, the on() method in this library can be used to listen for data changes at a particular location in our database. So each time a new task is completed on server side (e.g. new email sent), we notify Firebase and the UI is automatically updated accordingly.

var fb = new Firebase("https://test-apps-script.firebaseio.com");
var ref = fb.child('users/' + UID + '/nbOfEmailsSent');
ref.on("value", function(data) {
  if (data.val()) {
    document.getElementById("nbOfEmailsSent").innerHTML = data.val();
  }
});

More Firebase in Add-ons

In addition to the example above, there are other places where Firebase can be useful in Google Apps Script add-ons.

• “Yet Another Mail Merge” also offers paid plans and it needs to store our customer list. It turns out, Firebase is perfect for that as well. Each time someone buys a plan, our payment tool calls an Apps Script web app which writes the payment details in Firebase. So right after the purchase, the user can open the add-on and a function on server side will call Firebase and see that premium features should now be enabled for this user.
• Last but not least, at the end of a mail merge, we also use Firebase to provide real-time reporting of emails opened, directly in the sidebar of the spreadsheet.

Those are just a few examples of what you can do with Apps Script and Firebase. Don’t hesitate to try it yourself or install Yet Another Mail Merge to see a live example. In addition, there is a public Apps Script library called FirebaseApp that can help you start with Firebase; use it like any other standard Apps Script library.

For example, you can easily fetch data from Firebase using specific query parameters:

function getFrenchContacts() {
  var firebaseUrl = "https://script-examples.firebaseio.com/";
  var base = FirebaseApp.getDatabaseByUrl(firebaseUrl);
  var queryParameters = {orderBy:"country", equalTo: "France"};
  var data = base.getData("", queryParameters);
  for(var i in data) {
    Logger.log(data[i].firstName + ' ' + data[i].lastName
        + ' - ' + data[i].country);
  }
}

Build your own add-ons via Google Apps Script. Check out the documentation (developers.google.com/apps-script) to get more information as well as try out the Quickstart projects there. We look forward to seeing your add-ons soon!

Romain Vialard profile | website

Romain Vialard is a Google Developer Expert. After some years spent as a Google Apps consultant, he is now focused on products for Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.

Posted by Pepper Lebeck-Jobe, Classroom API Tech Lead

Classroom debuted last year to help teachers and students save time and collaborate with each other, and since then we’ve been working on how to make sure it worked well with other products that educators love and use in their classes.

Starting today, developers can embed the Classroom share button and sign up for the developer preview of the Classroom API. These tools make it easy for developers to seamlessly integrate with Classroom in ways that help teachers and students — like letting teachers create assignments directly from Quizlet, Duolingo, PBS and many other favorites.

Classroom API

By using the API, admins will be able to provision and populate classes on behalf of their teachers, set up tools to sync their Student Information Systems with Classroom, and get basic visibility into which classes are being taught in their domain. The Classroom API also allows other apps to integrate with Classroom.

Until the end of July, we’ll be running a developer preview, during which interested admins and developers can sign up for early access. When the preview ends, all Apps for Education domains will be able to use the API, unless the admin has restricted access.

A few developers have been helping us test the API, and we’re excited to share a few examples of what they’ve built:

• The New Visions CloudLab (makers of Doctopus) built rosterSync for Sheets, an add-on integrated with Classroom. Harnessing the power of Google Sheets, admins can sync data from any student information system with Classroom.
• Alma, a hybrid student information and learning management platform, will let schools easily create and sync their class rosters directly to Classroom with just a few clicks. And if an admin adds a student to a class in Alma, that student will get automatically added in the Classroom class. See more in their demo video.
• And if you use Pear Deck, it’s now easy to start an interactive Pear Deck session with any of your Classroom classes. Just click “Invite from Google Classroom,” choose a class and your students will automatically be invited. Pear Deck will always use your current roster of students from Classroom, so you don’t have to keep rosters up to date across apps.

Classroom share button

Today we’re also introducing the Classroom share button, a simple way for developers – or schools – to allow teachers and students to seamlessly assign or turn-in links, videos and images from another webpage or product.

The share button only requires a few lines of JavaScript, and you can customize the button to meet the needs of your website. When teachers and students click the button, they can quickly share to Classroom without having to leave the site they’re on. More than 20 educational content and tool providers have already committed to integrating the Classroom share button, including:

• PBS
• Quizlet
• American Museum of Natural History
• Discovery Education
• Duolingo
• TIME for Kids

To get started or learn more about either the API or integrating the share button, visit developers.google.com/classroom. And let us know what you’re building using the #withclassroom hashtag on Twitter or G+. As always, we’re looking forward to hearing your feedback and making sure that we’re addressing top needs. We’ll use the developer community site Stack Overflow to field technical questions and feedback about the Classroom API. Please use the tag google-classroom.

Posted by Iskander Akishev, Software Engineer, Google Calendar

The Google Calendar API allows you to create and modify events on Google Calendar. Starting today, you can use the API to also attach Google Drive files to Calendar events to make them—and your app—even more useful and integrated. With the API, you can easily attach meeting notes or add PDFs of booking confirmations to events.

Here's how you set it up:

1) Get the file information from Google Drive (e.g. via the Google Drive API):

GET https://www.googleapis.com/drive/v2/files

{
 ...
 "items": [
  {
   "kind": "drive#file",
   "id": "9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q,
   ...
   "alternateLink": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk",
   "title": "Workout plan",
   "mimeType": "application/vnd.google-apps.presentation",
   ...
  },
  ...
 ]
}

2) Pass this information into an event modification operation using the Calendar API:

POST https://www.googleapis.com/calendar/v3/calendars/primary/events?supportsAttachments=true

{
  "summary": "Workout",
  "start": { ... },
  "end": { ... },
  ...
  "attachments": [
   {
      "fileUrl": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk",
      "title": "Workout plan",
      "mimeType": "application/vnd.google-apps.presentation"
   },
   ...
  ]
}

Voilà!

You don’t need to do anything special in order to see the existing attachments - they are now always exposed as part of an event:

GET https://www.googleapis.com/calendar/v3/calendars/primary/events/ja58khmqndmulcongdge9uekm7

{
 "kind": "calendar#event",
 "id": "ja58khmqndmulcongdge9uekm7",
 "summary": "Workout",
 ...
 "attachments": [
  {
   "fileUrl": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk",
   "title": "Workout plan",
   "mimeType": "application/vnd.google-apps.presentation",
   "iconLink": "https://ssl.gstatic.com/docs/doclist/images/icon_11_presentation_list.png"
  },
  ...
 ]
}

Check out the guide and reference in the Google Calendar API documentation for additional details.

For any questions related to attachments or any other Calendar API features you can reach out to us on StackOverflow.com, using the tag #google-calendar.

Posted by Janet Traub, Program Manager, Google Apps APIs

The Google Apps Developer team recently hosted a 3-part Hangout On Air series that provided the developer community a unique opportunity to engage with the creative minds behind Google Apps developer tools. Each session covered topics ranging from business automation using Apps Script to Google Calendar API usage to creating Add-Ons for Docs & Sheets.

In the first installment of the series, Mike Harm, the creator of Apps Script and his colleague Kenzley Alphonse delivered a captivating session entitled, “Automate your Business with Apps Script.” Together, they reviewed the various features of Apps Script that can help developers build powerful solutions with Google Apps, such as simple scripts, to easily do a mail merge, export calendars into a Sheet, and to generate regularly scheduled reports.

The series then shifted focus to Google Calendar. In “Creating Calendar Events - Easy and Useful” Ali A. Rad (Product Manager) and Lucia Fedorova (Tech Lead) for Google Calendar API, explained how developers can benefit from injecting content into users’ calendars. In addition, they reviewed different approaches on Google Calendar to create events and meetings, such as API features, email markups, Android intents, Calendar import, and more.

We concluded the series with “How to Increase Traffic to Your Add-On with Google Apps Script.” This session, delivered by Apps Script Product Manager, Saurabh Gupta and Mike Harm, gave developers an in depth understanding of the Add-Ons framework, steps to deployment and strategies to increase adoption of their Docs, Sheets and Forms Add-Ons.

For more information on developing for Google Apps, visit developers.google.com/google-apps

If your app needs to keep up with changes in a Gmail mailbox, whether it's new mail being received or a label being added, you are likely familiar with periodically polling the Gmail API's history feed for updates. If you find this tedious, we have good news for you. Today, at Google I/O 2015, we're launching push notifications for the Gmail API.

Just subscribe to a Gmail mailbox and whenever a change occurs, the Gmail API will instantly notify your server using webhooks or another Cloud Pub/Sub API notification method. No polling required.

Check out the developers’ guide at https://developers.google.com/gmail/api/guides/push to get started. We can’t wait to see what you build.

Posted by Eric DeFriez, Gmail Extensibility Team. As a technical lead for Gmail APIs, Eric works to make it easy for developers to build on top of Gmail.

Posted by Saurabh Gupta, Product Manager

Originally posted to Google Developers blog

Back in 2014, we introduced add-ons for Google Docs, Sheets, and Forms in developer preview. Since then, the developer community has built a wide variety of features to help millions of Docs, Sheets and Forms users become more productive. Over the last few months, we launched a number of developer-friendly features that made it easier to build, test, deploy and distribute add-ons. Some key capabilities include:

• Ability to publish add-ons in Google Apps Marketplace
• Ability to bundle your add-on with existing Apps Marketplace listing
• Availability of Apps Script triggers in add-ons
• Testing tools for add-ons
• Using standalone scripts to publish add-ons
• Option to use your own Google Developers console project
• Iframe sandbox mode for faster UI

With these features under our belt, we are ready to graduate add-ons out of developer preview. Starting today, any developer can publish an add-on. To ensure users find the best tools for them, every new add-on will undergo a review for adherence to our guidelines before it’s available in the add-ons store.

We can’t wait to see what you will build!

Posted by Chris Han, Product Manager, Google Apps Marketplace team

Today we’re announcing two changes to the post install experience for Google Apps Marketplace. Both changes are geared towards improving end user awareness and active usage of your apps.

First, after installing a Marketplace app, admins will be given the opportunity to send a notification to end users. This enables admins to easily tell users that your app is now available, and how to access it.

The notification will only appear to the users in the Organizational Unit (OU) or domain for which the admin has installed the app. The notification will appear in each user’s Notification Center and will describe how to access and launch the app.

Second, we’ve completely changed the post install experience itself, making instructions for accessing your app clearer. During the post install experience, we now show how to access all the extension points of your app (e.g. Apps launcher, Drive, Add-ons to Docs, Sheets, and Forms).

For more information on this feature, please see the Help Center article.

Posted by Cheryl Simon Retzlaff, Software Engineer on the Realtime API team

Real-time collaboration is a powerful feature for getting work done inside Google docs. We extended that functionality with the Realtime API to enable you to create Google-docs style collaborative applications with minimal effort.

Integration of the API becomes even easier with a new in memory mode, which allows you to manipulate a Realtime document using the standard API without being connected to our servers. No user login or authorization is required. This is great for building applications where Google login is optional, writing tests for your app, or experimenting with the API before configuring auth.

The Realtime debug console lets you view, edit and debug a Realtime model. To launch the debugger, simply execute gapi.drive.realtime.debug(); in the JavaScript console in Chrome.

Finally, we have refreshed the developer guides to make it easier for you to learn about the API as a new or advanced user. Check them out at https://developers.google.com/drive/realtime.

For details on these and other recent features, see the release note.

Posted by Kalyan Reddy, Developer Programs Engineer

Apps Script includes many built-in Google services for major products like Gmail and Drive, and lately, we've been working to add other APIs that developers have been clamoring for as advanced Google services. Today, we are launching seven more advanced services, including:

• Admin SDK Groups Migration service
• Admin SDK Groups Settings service
• Admin SDK License Manager service
• Admin SDK Reseller service
• Apps Activity service
• DoubleClick Campaigns service
• Google+ service

Like all other advanced services in Apps Script, they must first be enabled before use. Once enabled, they are just as easy to use as built-in Apps Script services -- the editor provides autocomplete, and the authentication flow is handled automatically.

Here is a sample using the Apps Activity advanced service that shows how to get a list of users that have performed an action on a particular Google Drive file.

function getUsersActivity() {
  var fileId = 'YOUR_FILE_ID_HERE';
  var pageToken;
  var users = {};
  do {
    var result = AppsActivity.Activities.list({
      'drive.fileId': fileId,
      'source': 'drive.google.com',
      'pageToken': pageToken
    });
    var activities = result.activities;
    for (var i = 0; i < activities.length; i++) {
      var events = activities[i].singleEvents;
      for (var j = 0; j < events.length; j++) {
        var event = events[j];
        users[event.user.name] = true;
      }
    }
    pageToken = result.nextPageToken;
  } while (pageToken);
  Logger.log(Object.keys(users));
}

This function uses the AppsActivity.Activities.list() method, passing in the required parameters drive.fileId and source, and uses page tokens to get the full list of activities. The full list of parameters this method accepts can be found in the Apps Activity API's reference documentation.

Cross-posted from the Google Developers Blog

Since we introduced add-ons for Google Docs, Sheets, and Forms last year, our developer partners have brought a world of new features to millions of users. Still, administrators for Google Apps domains (and developers!) kept asking for two things:

• Installing and pre-authorizing of an add-on for every user in a domain or group. Starting today, admins can do just that, if the add-on's developer has published the add-on for domain-wide installation. This automatically creates a listing for the add-on in the Google Apps Marketplace.


• Installing some approved add-ons while restricting users from installing others. Thanks to the feature above, a domain admin can now disable add-on installation for users, then personally install approved add-ons either for all users in the domain or for a specific organizational unit.

So, if you’ve built (or are thinking of building) a Google Docs, Sheets or Forms add-on, then be sure to make your add-on available in Google Apps Marketplace today.

Posted by Saurabh Gupta, product manager, Google Apps Script

Update (2015-06-15): The sunset date listed below has been changed from June 26th to July 6th, 2015.

Posted by Eric Koleda, Developer Platform Engineer

OAuth is the de facto standard for authorization today and is used by most modern APIs. Apps Script handles the OAuth flow automatically for dozens of built-in and advanced services, but until recently only had limited support for connecting to other OAuth-protected APIs such as Twitter, etc. The URL Fetch service’s OAuthConfig class only works with the older OAuth 1.0 standard and only allows the developer of the script (not its users) to grant access to their data. To address this, we’ve create two new open source libraries:

• OAuth1 for Apps Script
• OAuth2 for Apps Script

With only a few clicks, you can add these libraries to your scripts. The full source code is available on GitHub if you need to tinker with how they work. These libraries allow for greater control over the OAuth flow, including the ability for users to grant access separately, a long standing feature request from the community.

We believe that these open libraries are a better alternative to our previous solution, and therefore we are deprecating the OAuthConfig class. The class will continue to function until July 6, 2015, after which it will be removed completely and any scripts that use it will stop working We’ve prepared a migration guide that walks you through the process of upgrading your existing scripts to use these new libraries.

Separate from these changes in Apps Script and as announced in 2012, all Google APIs will stop supporting OAuth 1.0 for inbound requests on April 20, 2015. If you use OAuthConfig to connect to Google APIs, you will need to migrate before that date. Update your code to use the OAuth2 library or the API’s equivalent Advanced Service if one exists.

OAuthConfig Connecting To	Migrate To	Migration Deadline
Google API (Calendar, Drive, etc)	OAuth2 for Apps Script or Advanced Service	April 20, 2015
Non-Google API (Twitter, etc)	OAuth1 for Apps Script	July 6, 2015

We see Apps Script and Sheets as the perfect hub for connecting together data inside and outside of Google, and hope this additional OAuth functionality makes it an even more compelling platform.

A few weeks ago, the Google Sheets team introduced improved control over protected sheets and ranges. Developers have told us they're looking for the same power in Google Apps Script — after all, ever since we added data validation to the Spreadsheet service, programmatic control over protected ranges has been the most popular request on the Apps Script issue tracker.

Today, we are excited to give you that granular control.

With the new Protection class in the Spreadsheet service, your scripts can touch every aspect of range or sheet protection, just like in the new UI. (The older PageProtection class, which had more limited features, will be deprecated, but will stick around in case you need to work with older spreadsheets. The new Protection class only applies to the newer version of Sheets.)

Code samples

So let's see the new stuff in action. Let's say you want to prohibit anyone other than yourself from editing cells A1:B10:

// Protect range A1:B10, then remove all other users from the list of editors.
var ss = SpreadsheetApp.getActive();
var range = ss.getRange('A1:B10');
var protection = range.protect().setDescription('Sample protected range');

// Ensure the current user is an editor before removing others. Otherwise, if the user's edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Or maybe you want to remove all range protections in the whole spreadsheet:

// Remove all range protections in the spreadsheet that the user has permission to edit.
var ss = SpreadsheetApp.getActive();
var protections = ss.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < protections.length; i++) {
  var protection = protections[i];
  if (protection.canEdit()) {
    protection.remove();
  }
}

Or perhaps you want to protect an entire sheet, but carve out a small hole in it — an unprotected range within a protected sheet — that others can still edit:

// Protect the active sheet except B2:C5, then remove all other users from the list of editors.
var sheet = SpreadsheetApp.getActiveSheet();
var protection = sheet.protect().setDescription('Sample protected sheet');
var unprotected = sheet.getRange('B2:C5');
protection.setUnprotectedRanges([unprotected]);

// Ensure the current user is an editor before removing others. Otherwise, if the user's edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Bam! Easy. Hope you find this useful, and happy scripting!

Posted by Sam Berlin, engineer, Google Sheets

Posted by Wesley Chun, Developer Advocate, Google Apps

Last summer, we launched the new Gmail API, giving developers more flexible, powerful, and higher-level access to programmatic email management, not to mention improved performance. Since then, it has been expanded to replace the Google Apps Admin SDK's Email Migration API (EMAPI v2). Going forward, we recommend developers integrate with the Gmail API.

EMAPI v2 will be turned down on November 1, 2015, so you should switch to the Gmail API soon. To aid you with this effort, we've put together a developer’s guide to help you migrate from EMAPI v2 to the Gmail API. Before you do that, here’s your final reminder to not forget about these deprecations including EMAPI v1, which are coming even sooner (April 20, 2015).