Tag Archives: Google APIs

Gmail Add-ons framework now available to all developers

Originally posted by Wesley Chun, G Suite Developer Advocate on the G Suite Blog

Email remains at the heart of how companies operate. That's why earlier this year, we previewed Gmail Add-ons—a way to help businesses speed up workflows. Since then, we've seen partners build awesome applications, and beginning today, we're extending the Gmail add-on preview to include all developers. Now anyone can start building a Gmail add-on.

Gmail Add-ons let you integrate your app into Gmail and extend Gmail to handle quick actions.

They are built using native UI context cards that can include simple text dialogs, images, links, buttons and forms. The add-on appears when relevant, and the user is just a click away from your app's rich and integrated functionality.

Gmail Add-ons are easy to create. You only have to write code once for your add-on to work on both web and mobile, and you can choose from a rich palette of widgets to craft a custom UI. Create an add-on that contextually surfaces cards based on the content of a message. Check out this video to see how we created an add-on to collate email receipts and expedite expense reporting.

Per the video, you can see that there are three components to the app's core functionality. The first component is getContextualAddOn()—this is the entry point for all Gmail Add-ons where data is compiled to build the card and render it within the Gmail UI. Since the add-on is processing expense reports from email receipts in your inbox, the createExpensesCard()parses the relevant data from the message and presents them in a form so your users can confirm or update values before submitting. Finally, submitForm()takes the data and writes a new row in an "expenses" spreadsheet in Google Sheets, which you can edit and tweak, and submit for approval to your boss.

Check out the documentation to get started with Gmail Add-ons, or if you want to see what it's like to build an add-on, go to the codelab to build ExpenseItstep-by-step. While you can't publish your add-on just yet, you can fill out this form to get notified when publishing is opened. We can't wait to see what Gmail Add-ons you build!

Gmail add-ons framework now available to all developers



Email remains at the heart of how companies operate. That’s why earlier this year, we previewed Gmail Add-ons—a way to help businesses speed up workflows. Since then, we’ve seen partners build awesome applications, and beginning today, we’re extending the Gmail add-on preview to include all developers. Now anyone can start building a Gmail add-on.

Gmail Add-ons let you integrate your app into Gmail and extend Gmail to handle quick actions. They are built using native UI context cards that can include simple text dialogs, images, links, buttons and forms. The add-on appears when relevant, and the user is just a click away from your app's rich and integrated functionality.

Gmail Add-ons are easy to create. You only have to write code once for your add-on to work on both web and mobile, and you can choose from a rich palette of widgets to craft a custom UI. Create an add-on that contextually surfaces cards based on the content of a message. Check out this video to see how we created an add-on to collate email receipts and expedite expense reporting.

Per the video, you can see that there are three components to the app’s core functionality. The first component is getContextualAddOn()—this is the entry point for all Gmail Add-ons where data is compiled to build the card and render it within the Gmail UI. Since the add-on is processing expense reports from email receipts in your inbox, the createExpensesCard()parses the relevant data from the message and presents them in a form so your users can confirm or update values before submitting. Finally, submitForm() takes the data and writes a new row in an “expenses” spreadsheet in Google Sheets, which you can edit and tweak, and submit for approval to your boss.

Check out the documentation to get started with Gmail Add-ons, or if you want to see what it's like to build an add-on, go to the codelab to build ExpenseIt step-by-step. While you can't publish your add-on just yet, you can fill out this form to get notified when publishing is opened. We can’t wait to see what Gmail Add-ons you build!

Generating Google Slides from images using Apps Script



Today, we announced a collection of exciting new features in Google Slides—among these is support for Google Apps Script. Now you can use Apps Script for Slides to programmatically create and modify Slides, plus customize menus, dialog boxes and sidebars in the user interface.

Programming presentations with Apps Script

Presentations have come a long way—from casting hand shadows over fires in caves to advances in lighting technology (magic lanterns) to, eventually, (in)famous 35mm slide shows of your Uncle Bob's endless summer vacation. More recently, we have presentation software—like Slides—and developers have been able to write applications to create or update them. This is made even easier with the new Apps Script support for Google Slides. In the latest G Suite Dev Show episode, we demo this new service, walking you through a short example that automatically creates a slideshow from a collection of images.
To keep things simple, the chosen images are already available online, accessible by URL. For each image, a new (blank) slide is added then the image is inserted. The key to this script are two lines of JavaScript (given an existing presentation and a link to each image):

var slide = presentation.appendSlide(SlidesApp.PredefinedLayout.BLANK);
var image = slide.insertImage(link);

The first line of code adds a new slide while the other inserts an image on the new slide. Both lines are repeated for each image in the collection. While this initial, rudimentary solution works, the slide presentation created doesn't exactly fit the bill. It turns out that adding a few more lines make the application much more useful. See the video for all the details.

Getting started 

To get started, check the documentation to learn more about Apps Scripts for Slides, or check out the Translate and Progress Bar sample Add-ons. If you want to dig deeper into the code sample from our video, take a look at the corresponding tutorial. And, if you love watching videos, check out our Apps Script video library or other G Suite Dev Show episodes. If you wish to build applications with Slides outside of the Apps Script environment and want to use your own development tools, you can do so with the Slides (REST) API—check out its documentation and video library.

With all these options, we look forward to seeing the applications you build with Google Slides!

Monitoring the Apps Script issue tracker…with Apps Script

Originally posted by Paul McReynolds, Product Manager (@pauljmcr), Apps Script and Wesley Chun (@wescpy), Developer Advocate, G Suite on the G Suite Developers Blog

Apps Script is just as popular inside Google as it is among external users and developers. In fact, there are more than 70,000 weekly active scripts written by thousands of Googlers. One of our many uses for Apps Script at Google is to automate and monitor our internal issue tracker.

Your business depends on Apps Script...so does ours

In spring of this year, we migratedour G Suite issue trackers to a new system based on our internal tracker. This carries a lot of benefits, including improving our ability to track how issues reported from outside of Google relate to bugs and features we're working on internally. We also have an internal Apps Script API that talks to our issue tracker, which we can now use to work with issues reported from outside of Google.

As soon as the migration was finished, we put Apps Script to work monitoring…itself. Now we have a script in place that monitors Apps Script issues as they are reported and upvoted on the public tracker. When we see an issue that's having widespread or sudden impact, the script generates an alert that we can then investigate. With the help of our large, active community of developers, and leveraging Apps Script, we're now able to identify and respond to issues more quickly.

There's no substitute for independent monitoring, and our Apps Script-based approach isn't the first or the last line of defense. Instead, this new script helps us catch anything that our monitoring systems miss by listening to what developers are saying on the tracker.

If you see something, say something

Please help us keep Apps Script humming! When you notice a problem, search the issue trackerforit and file an issue if it's new. Click the star to let us know you're affected and leave a comment with instructions to reproduce, along with any other relevant details. Those instructions and other details help us respond to the issues more effectively, so please be sure to include them.

Happy scripting!

Monitoring the Apps Script issue tracker…with Apps Script



Apps Script is just as popular inside Google as it is among external users and developers. In fact, there are more than 70,000 weekly active scripts written by thousands of Googlers. One of our many uses for Apps Script at Google is to automate and monitor our internal issue tracker.

Your business depends on Apps Script...so does ours 

In spring of this year, we migrated our G Suite issue trackers to a new system based on our internal tracker. This carries a lot of benefits, including improving our ability to track how issues reported from outside of Google relate to bugs and features we’re working on internally. We also have an internal Apps Script API that talks to our issue tracker, which we can now use to work with issues reported from outside of Google.

As soon as the migration was finished, we put Apps Script to work monitoring…itself. Now we have a script in place that monitors Apps Script issues as they are reported and upvoted on the public tracker. When we see an issue that’s having widespread or sudden impact, the script generates an alert that we can then investigate. With the help of our large, active community of developers, and leveraging Apps Script, we’re now able to identify and respond to issues more quickly.

There’s no substitute for independent monitoring, and our Apps Script-based approach isn’t the first or the last line of defense. Instead, this new script helps us catch anything that our monitoring systems miss by listening to what developers are saying on the tracker.

If you see something, say something 

Please help us keep Apps Script humming! When you notice a problem, search the issue tracker for it and file an issue if it's new. Click the star to let us know you’re affected and leave a comment with instructions to reproduce, along with any other relevant details. Those instructions and other details help us respond to the issues more effectively, so please be sure to include them.

Happy scripting!

Stackdriver Logging for Google Apps Script is now available


Google Apps Script has always provided a simple logging tool—the Logger service—to help developers better test their scripts. This works for many simple use cases, but developers need other ways to log messages and errors, particularly when:
  • Troubleshooting or analyzing scripts across multiple executions
  • Working on a script or add-on with multiple users 
  • Looking for trends or insights about their scripts and users
To make Apps Script a friendlier environment for developers, we are announcing general availability of a new integration with Google Stackdriver. This is in addition to the pre-existing Logger service, which is still available.

Using Stackdriver Logging in Google Apps Script

Log messages can now be sent to Stackdriver Logging using the familiar console.log(), console.info(), etc. functions. You can also instruct Apps Script to log messages and stack traces for all exceptions, which also become available for analysis in Stackdriver Error Reporting by simply checking a box. No need to add a single extra line of code.

In Stackdriver, logs are kept for 7 days for free, and the premium tier offers 30-day retention. Powerful search and filtering are available to quickly find log entries by text content or metadata, and developers can also choose to export logs to BigQuery, Cloud Storage, and Cloud Pub/Sub for further analysis, long term conservation, and custom workflows.

Log messages and errors are reported for all users of a script, with a unique but obfuscated identifier assigned to each user. This means log entries can be aggregated anonymously per user, for example allowing developers to count unique users impacted by an issue or analyze user behavior, but without logging users’ personally identifying information.


Developers get some of these aggregated analyses for free. In the Stackdriver Error Reporting tab of the developer console, you can see recurring errors and the numbers of users impacted. You can even subscribe to receive an email alert when a new type of error is detected.


How developers are using Stackdriver Logging

Developers of scripts and add-ons have started to rely more on more on this new logging capability. Romain Vialard, creator of Yet Another Mail Merge, a popular Google Sheets add-on, is using Stackdriver Logging to time the execution of his add-on, exporting data to BigQuery to perform aggregations and analyze trends. Read this tutorial to learn how to export logs to BigQuery and run queries to analyze how users are interacting with your script.

Stackdriver Logging is one of the ways we’re making Apps Script a more manageable platform for developers. We hope that it and other features coming soon make Apps Script developers more productive and their scripts, add-ons and integrations more robust.

You can read more about how to enable and use the Stackdriver integration by reading Apps Script’s logging documentation.

About the authors 

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

Paul McReynolds is a Product Manager at Google focused on Apps Script and G Suite Marketplace. Previously a startup founder and CTO, Paul believes that the easy things need to be easy or the hard things don’t get done. At Google, he's excited to be a part of the company that makes solving problems for business fun again.

Editor's note: Yet Another Mail Merge and Form Publisher are not created, sponsored, or supported by Google.

What’s new for shortcuts and widgets in Android O

Posted by Gloria Liou, Associate Product Manager Intern


Why use shortcuts and widgets?


One of our favorite features in Android O is the ability to pin shortcuts and widgets for your app onto the launcher through deep linking.


Shortcuts let users quickly start a specific task, while widgets give users instant access to specific actions and information from your app. Users want to get things done, and get things done fast - shortcuts and widgets are a way to help them and to increase user engagement with your content.

To pin a shortcut or widget, users long press your app's icon for options and drag and drop the selected item to a location of their choice.


Dynamic / static shortcuts
Pinned shortcuts






Adding shortcuts and widgets from within your app




The API has a new flow for adding shortcuts and widgets from within your app. The new method uses a modal dialog, deprecating the old method of using a broadcast, which will not work on O devices.

That's not all. We've made improvements to the user interface and experience. In the old experience, there was no app icon on the shortcut, so users had no idea which app the shortcut was from. Marking shortcuts with the app icon provides better branding while protecting users from potential malware.





Old shortcut
New shortcut



There is also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.



With these new additions and improvements, users will be more likely to use your shortcuts and widgets, leading to more meaningful and impactful engagement with your app and happier, more productive users.

To learn more, head over to the shortcuts and widgets page on the Android Developers website.


New security protections to reduce risk from unverified apps

Originally posted by Naveen Agarwal, Identity team and Wesley Chun (@wescpy), Developer Advocate, G Suite on the G Suite Developers Blog

We're constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.

Over the past few months, we've required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.

Today, we're expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.

Protecting against unverified apps

Beginning today, we're rolling out an "unverified app" screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the "error" page that developers and users of unverified web apps receive today.

The "unverified app" screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.

The "unverified app" consent flow

This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the 'unverified app' alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).

Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.

Extending security protections to Google Apps Script

We're also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.

Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to "consider whether you trust" an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.

Updated Apps Script pre-OAuth alert with cautionary language
Apps Script user-generated content banner

Extending protections to existing apps

In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.

To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.

In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article.

We're committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.

New security protections to reduce risk from unverified apps



We’re constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.

Over the past few months, we’ve required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.

Today, we’re expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.

Protecting against unverified apps 

Beginning today, we’re rolling out an “unverified app” screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the “error” page that developers and users of unverified web apps receive today.

The “unverified app” screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.

The "unverified app" consent flow

This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the ‘unverified app’ alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).

Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.

Extending security protections to Google Apps Script 

We’re also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.

Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to “consider whether you trust” an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.
Updated Apps Script pre-OAuth alert with cautionary language
Apps Script user-generated content banner

Extending protections to existing apps 

In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.

To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.

In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article

We’re committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.

Identifying app usage in your Google Drive audit logs



If you’re a G Suite admin (or a developer creating apps for admins), it’s important to understand the various applications your company’s employees are using and how they’re accessing them. Today, we’re making that easier by introducing app identification (i.e. originating_app_id) in the Google Drive audit logs within the Admin SDK Reports API.

Now, your apps will be able to determine whether an activity logged was performed by a user in the Drive Android app, Drive iOS app, Google Chrome, or through a variety of other third-party apps that leverage, modify or create files within Google Drive, like Smartsheet or Asana. This will give you a better sense of the apps being used in your organization, as well as the extent and context of that usage.

Note that App IDs that show up in the logs will be numeric. Should you want to retrieve app names, a separate request using the Google Drive REST API is needed. If you already retrieve information through the Drive activity request, you should start seeing the originating_app_ids show up in your logs. Here are a pair of HTTP requests you can use to query this information:

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/userKey

Or
GET 
https://www.googleapis.com/admin/reports/v1/activity/users/all/applications/drive

To learn more about this new feature, take a look at the documentation, then integrate into your code so you and other G Suite admins can gain a better understanding of app usage in your domain(s). We look forward to seeing what you build!