If this is your first attempt at submitting an add-on for the Google Marketplace, it—like all new experiences—can take longer than expected as you learn and get comfortable with all of the requirements. You should expect pushback from both the OAuth team and the Marketplace team, as they are on the frontline of ensuring that end users have a positive experience installing Add-ons. Taking the time to slowly go through and make sure you have each of the elements along with a willingness to update and improve your application will surely result in the successful publication of your Add-on published in the Google Marketplace.
Alice Keeler knows a thing or two about publishing Google Workspace Add-ons to the Marketplace with over 20 entries. In this post on the Google Cloud Blog Alice shares some of her top tips for surviving the publication process. This includes website essentials, tips on artwork as well as creating your verification video. Follow the source link for these tips and more.
When working in a team and/or with a client, you want to have multiple environments. At minimum, you probably want a dev environment (or multiple ones) in which you are working, and a test environment in which the client or your team can run acceptance tests before production. Of course, they must both be separate from the production environment. To push your code to the correct environment, you need to either update the
file manually or keep multiple copies of your script with different
files. Fortunately, things have just become significantly easier, as I recently built an app for this purpose called
clasp-env, which is available on NPM. See the source link for details.
This is a sample script for retrieving the values of dropdown list of the smart chips on Google Document using Google Apps Script.
At August 23, 2021, 3 Classes for retrieving the smart chips have been added to Google Apps Script. But, in the current stage, unfortunately, all values of the smart chips cannot be retrieved by the Classes. For example, the dropdown list of the smart chips cannot be retrieved
Incredibly useful report and workaround from Kanshi Tanaike for Google Workspace Devs needing to get some ‘smart chips’ values from Google Docs. Hopefully classes/methods will be added to Apps Script and the Google Docs API (here is a related feature request you can star in the issue tracker), particularly as the current solution is to convert the Google Doc to .docx and then back to Google Doc.
When we use HTML in the Google Apps Script project, in order to show the values from the Google Apps Script side, the HTML template is used. When I used the HTML template with a large value, I understood that the process cost can be reduced by devising a script. In this report, I would like to introduce the process cost of the HTML template using the benchmark.
A great feature of Google Apps Script is the ability to create and serve custom HTML, often used to interface data you have in Google Workspace such as Google Sheets. Google highlight a coupe of different ways you can mix Apps Script code and HTML. Some of these ways are better in terms of process time and this report from Kanshi Tanaike highlights the cost of calling Apps Script functions as scriptlets in HTML templates. The good news is you can avoid delays in your web app rendering by making asynchronous calls with
, which you can read more about in Google’s best practices documentation.
Update: I’ve replicated this benchmark (smaller dataset) with
and it was only marginally slower (0.3s) than the ‘create HTML table with Google Apps Script’:
See four different API Authentication methods presented in Apps Script, including authentication in query string, headers, and OAuth2.
I got fed up digging around in my Drive folder for old scripts to refresh my memory on the syntax, so I created this reference.
It’s not a comprehensive post on how to connect to APIs, instead, it’s a short summary of common protocols for easy reference.(If you’re new to APIs, start with my Apps Script API tutorial for beginners.)
We are currently spoilt for choice with Google Apps Script community contributions. This is a great post from Ben Collins for Google Apps Script beginners highlighting different patterns used to interact with third party websites with APIs.
An API is essentially an interface that can be used by a computer programme to retrieve or interact with another application.
Another in the SuperFetch (a proxy for Apps Script UrlFetchApp) plugins series, Frb is a plugin to access a Firebase Real time database.
If you want to take your use of APIs a little further Bruce Mcpherson is continuing his series exploring his recently published SuperFetch library showing how a client can be setup to interact with Firebase. As Bruce highlights: “Firebase is pretty fast, so there’s not a huge speed benefit from caching, but if you’re on a pay as go plan, SuperFertch caching can reduce your Firebase costs.”
The source post provided by Bruce provides everything to need to set up the SuperFetch client and Firebase project.
Many of us undisciplined hacks (read: not professional developers) sometimes find ourselves wondering when we will buckle down and start using Github to store our Apps script source files and versions.
If you sometimes find yourself in the same boat: needing to restore or access an old script version, the first thing you probably do is revert back to the old Apps script editor (IDE), (filling out the form regarding the lack of version history as your reason), and then hoping the version queue goes back far enough for you to recover what you need.
Well, today my undisciplined friend, I will show you a way to recover your script files, all the way back to version 1!! Yes, no more switching back to the old code editor.
In Pulse we’ve previously highlighted Romain Vialard’s solution to Retrieve previous versions of Google Apps Script projects, which uses
to make a call to the Script REST API and add recovered files to your Google Drive. In this new contribution from Clark Lind a clever ‘no-code’ solution using Google’s interactive API Explorer. The post includes all the steps you need to follow if you need to recover an old version of a script project.
In this post, we’ll be going through a quick workaround so that you can get back to running your scripts. Note that this issue is still not entirely resolved, but you can follow any developments in Google’s issue tracker.
If you are a Google Apps Script developer using a consumer @gmail.com account for development/testing or sharing script projects for other users to use with their gmail.com account you may have encountered the “This app is blocked” issue. This issue appears to prevent a Google account from completing the Apps Script authentication flow even when using limited scopes.
This post from Aiman Fikri provides a solution for getting around this issue by associating an Apps Script project to a Google Cloud Platform (GCP) project. Google also provide documentation on setting up Standard Cloud Platform projects, but if you are supporting novice users directing them to Aiman’s post might be less daunting for them.
There are some benefits of using Standard GCP project particularly when you are developing scripts as it gives access to Cloud logs and Error Reporting. If you encounter “This app is blocked” on all your script projects you can group multiple scripts with a single Cloud Platform project to save having to go through the full setup process.
Fortunately, Kanshi Tanaike has been exploring the impact the increased volume of data in Google Sheets has when using Google Apps Script and both
and Sheets API. The linked report contains a number of useful findings and strategies for handling large Google Sheets with Apps Script.