Apps Script developers that wished to share their work with a larger audience have traditionally turned to the Script Gallery, which allows other users to copy and install the script into their own spreadsheets. While appropriate for custom functions and spreadsheet extensions, it didn't fit well when distributing more complex functionality and apps.
In this blog post we'll be highlighting a newer way to distribute your scripts: deploying them as a web app and publishing them to the Chrome Web Store. Compared to the Script Gallery, the Chrome Web Store has some distinct advantages for developers:
Looking through the Script Gallery we believe there are many scripts that would be a great fit for the Chrome Web Store and would benefit from the advantages listed above. Some aspects of a good candidate script are:
A great example of such a script is Gmail Meter, which was first launched in the Script Gallery but has since been published to Chrome Web Store. Now users can install and run the script without needing to create a spreadsheet, see script code, or set up triggers. It may take a little work to update a spreadsheet-based script to use the web app model, and some common tasks are:
Publishing to the Chrome Web Store only takes a few clicks, and we provide instructions for the process in our documentation. We hope that you are inspired to take your scripts to the next level, and if you have any questions along the way feel free to reach out to us on StackOverflow or Google+.
At Google I/O in June, we launched two new features that made it easier to build and distribute web apps with Google Apps Script. First, we added the ability to deploy web apps that run as the user. Second, we added simple integration for publishing web apps that you’ve built with Apps Script to the Chrome Web Store.
Recently we’ve come across some new and useful web apps that developers have built using Apps Script and published in the Chrome Web Store. In this blog post, we’d like to highlight a few of those.
To try these and other web apps built using Apps Script, just visit the Chrome Web Store. If you’re interested in building and deploying your own web apps with Apps Script, see our documentation for web apps and publishing to the Chrome Web Store.
Hello Los Angeles! Following on the heels of our hackathon in Austin, Texas, we’ve decided that it’s time to bring the party to the City of Angels in sunny southern California. We’ll be hosting an Apps Script hackathon in our recently opened Los Angeles office on Tuesday, November 13th, 2012 between the hours of 2-8pm Pacific Time. We invite anyone that either uses or wants to learn about Google Apps Script to come and meet the team!
We’ll start off with a quick introduction to Apps Script followed by a short tutorial. At that point, we’ll break off into groups or individual work to either build apps or work through tutorials - both are fine, and you’ll have direct access to the Apps Script team to help you with any questions or ideas. We’ll provide food, drinks, power and wifi - you just bring your laptop, your creativity, and your appetite for code! Check out the detailed Google Sites page, RSVP once you know you can make it, and tell your friends about the event!
Official event page: https://sites.google.com/site/appsscripthackathonlosangeles
Hope to see you there!
- Ikai
Did you know you can write a complete Google Drive App with JavaScript that runs completely in the web browser? You can! Your browser-based application, including Chrome extensions, can take advantage of our client library, or just use CORS requests to the API.
Your app can support all the functionality of the Drive API, including uploading files, downloading files, tracking changes, listing files and managing revisions. Also you can take advantage of our user interface components that make opening and sharing files easy.
We are really keen to offer first-class support to browser-based applications, so we have added JavaScript snippets to all our API reference documentation. Please let us know how we are doing by posting to Stack Overflow.
Want to try it out? Check out our Javascript Quickstart Guide, which helps you get your application up and running in five minutes or so.
With the arrival of the new Google Drive API v2, we are deprecating the Google Documents List API v3. We are confident that the Google Drive API covers all the functionality of the Documents List API, in addition to adding many improvements, including Drive UI Integration, a finer grained security model, and a better client library experience.
What does this mean for your app?
The Documents List API v3 will remain in action for more than a year, as per our deprecation policy, so there’s no rush, but we encourage you to migrate your code to the new platform. Documentation is available with samples in multiple languages and a migration guide outlining some of the major transition points.
If you have any questions or issues, please ask them on StackOverflow.com, where our team is waiting to hear from you.
Not long after the Drive SDK was first released, we started receiving requests for a simpler developer and user experience. It took too long for developers to get started, and users were sometimes confused by the ways apps were installed. We’re now announcing a new feature that helps address these concerns: the Drive installation scope.
As the name suggests, this new OAuth 2.0 scope lets users install an app by approving an access request. Along with all the other levels of access you can request from users, it’s now possible to ask users for permission to install your app in their Drive.
This means that an app, or an app’s promotion page, could present an option to “Install this app in Google Drive,” and then users who select this option would interact with an OAuth 2.0 dialog that requests the installation scope. For example, the following script creates an “Add to Google Drive” button that could be embedded in a web page:
<script src="https://apis.google.com/js/client.js"></script> <script> var CLIENT_ID = '123456789.apps.googleusercontent.com' function installDriveApp() { gapi.auth.authorize({ client_id: CLIENT_ID, scope: 'https://www.googleapis.com/auth/drive.install', immediate: false }, function(authResult) { // Callback when installation complete }); } </script> <button onclick="installDriveApp();">Add to Google Drive</button>
On clicking this button, the user sees a standard OAuth 2.0 dialog box like the following (text for the installation scope is expanded in this example):
When the user approves these scopes, the app is installed for the user. Then, once it is installed this way, the app appears in the user’s Open with options as well as the Create > more contextual menu for files of registered MIME types.
Apps still need to specify primary and secondary MIME types when they enable the Drive SDK in the APIs console. But, unlike before, there is no need to install via the Chrome Web Store in order to get UI integration -- web store integration is entirely optional (though recommended).
Essentially, Drive now offers three levels of integration, which apps can combine according to their needs:
For guidance in getting started integrating your app in any of these ways, see “Build a Drive Web App” or "Integrate with the Drive UI" in the SDK documentation.
We still recommend that developers consider the many benefits of creating a Chrome Web Store listing for their application. In addition to providing ease of installation for users “shopping” in the Drive app collection, a web store listing provides helpful features to market and promote an app. Our usage analysis shows that apps in the Chrome Web Store receive more usage than apps that aren’t listed. But now, with the installation scope, you can get started developing and testing your app more quickly and then list it in the Chrome Web Store when you’re ready.
If you have any questions about the installation scope, don’t hesitate to let us know on our Stack Overflow tag, google-drive-sdk.
Editor’s Note: Guest author Bruce McPherson is a contributor to the Excel Liberation website and blog. -- Eric Koleda
If you are new to Google Apps Script and the JavaScript programming language, migrating legacy automation code written in Microsoft's Visual Basic for Applications (VBA) can be a daunting task. This blog post describes a Google Apps Script library which mimics the behavior and calling structure of common VBA functions, allowing you to more easily convert your existing applications.
If you are planning to continue to use VBA, you can minimize both the work involved in maintaining the same capability in both platforms, and in porting from one to the other, by preserving backwards compatibility with VBA. This means breaking a few JavaScript conventions, but the result is worth it.
For example, JavaScript variables are normally written in lowerCamelCase, with classes being in UpperCamelCase. VBA is not case sensitive, and uses hungarian notation by convention, except for the built-in functions, which have a capitalized first letter. Since the objective here is to minimize change, I have decided to retain this capitalization for VBA functions replacements (for example CStr(), Mid() etc. ).
CStr()
Mid()
In VBA, indices (normally) start at 1, while in JavaScript they start at 0. Since these functions are to minimize change in application written in VBA, they also start at 1. For example Mid(x, 1, 2) means the first 2 characters of string x in both VBA and JavaScript versions.
Mid(x, 1, 2)
JavaScript does not have a collection object. The vEquivalents library provides an implementation of a collection class so that continuity for migrated code that relies on the collection can be maintained. But how to enumerate through that collection? There are a number of ways, but the forEach() method of the collection most closely resembles the 'For Each member in collection' approach VBA developers are familiar with. The syntax may seem a little fiddly at first, since it passes the code you want executed against each member of the collection as an anonymous function.
forEach()
var coll = new collection(); // by index for (var i=1; i <= coll.count() ;i++) { DebugPrint (coll.item(i)); } // by key for (k in coll.keys()) { DebugPrint (coll.item(k)); } // forEach coll.forEach( function (item, index) { DebugPrint (item, index); } );
With the great new libraries functionality, you can now include these scripts in your project by using the project key "MEQ3tE5y5_cTOAgUbUKSIAiz3TLx7pV4j", or you can make a copy of the scripts directly to include in your own project. You will find a selection of other scripts in the library, but the VBA equivalents are all in the module vEquivalents. Note that as you include external libraries in your project (see here for how), you need to prefix the functions with the library identifier (for example mcpher.CStr())
mcpher.CStr()
You can access the documentation here, and you will see that most of the common VBA functions are included. Some examples are
var x = Trim(s); var x = Len(s); var a = Split(s); var x = Instr(1, s1, s2); var d = DateSerial(y, m, d); MsgBox(s); var x = InputBox(s); DebugAssert (b, s); var w = ActiveSheet();
Using the same approach, I have converted many other VBA utility classes and procedures built over time and added them to this library. This means that the implementation of something on either platform not only looks the same, but can be accomplished in hours or even minutes. For example, on my blog I publish a daily API, implemented in both VBA and Apps Script (both versions even use ScriptDB for the same parameter data). Here's a recent one.
function testUkPostcodes() { mcpher.generalDataSetQuery ("uk postcodes", "uk postcodes", "postcode"); } Public Sub testUkPostcodes() generalDataSetQuery "uk postcodes", "uk postcodes", "postcode" End Sub
You can find more projects that have been migrated this way here.
We keep adding new features to the Drive SDK and the Drive API, but always want to make it easy for new developers to get started. That’s why we are introducing a quickstart guide in 6 languages to run your first Drive app in less than 10 minutes: Java, Python, PHP, .NET, Ruby and Go.
At the end of this short guide, you’ll have:
We are also covering this quickstart guide in our Google Developers Live sessions: Python, PHP and .NET are already available and check-out our schedule for the remaining languages.
Once you are up and running, add more features such as reading a file’s metadata and content, update an existing file, integrate with the Drive web UI and list your Drive app on the Chrome Web Store to drive in more users!
Questions, feedback? Let’s follow-up on StackOverflow under the google-drive-sdk tag.
