WorryFree Computers   »   [go: up one dir, main page]

For developers, part of the simplicity of Apps Script has always been that authorization requires zero setup — but we heard from users that the process required too many clicks. At Google I/O this year, we launched an opt-in version of an easier authorization flow; today, that new flow becomes the default for all new scripts.


The old way — and the new.

Besides being prettier and easier, the new flow offers benefits behind the scenes: it allows more scripts to be simultaneously authorized on the same account, which means you shouldn’t need to reauthorize a script unless the code changes substantially.

For developers who use the advanced Google services, the new flow also gets rid of some manual steps that were previously required. Every new script now automatically creates a project in the Google APIs Console — no more messing with secret keys!

If you want the same experience for your existing scripts, you can upgrade them manually in just a few seconds.


Steve Lieberman   profile

Steve is an engineer on the Apps Script team in NYC. Before joining Google, he developed financial-trading systems and researched automatically-parallelizing compilers.

Today, we are pleased to announce a new release of the Email Migration API. This version of the API provides a simple RESTful interface with several enhancements that make it even easier to write client applications to migrate email to Google Apps.

This API is now part of our Admin SDK, which is useful for managing applications for Google Apps users through the Google APIs Console. Additionally, the Email Migration API v2 now includes support for:
  • Delegated administrators
  • OAuth 2.0
  • Media uploads
The new API also provides support for migrating additional email metadata (such as folders and labels) from existing email systems into Google Apps. For example, a user’s email stored in a nested folder named engineering/backend-support can be migrated with the label engineering-backend-support to retain the previous organization structure.

For more information about the API, visit the the Getting Started guide or explore the API Reference.

Greg Knoke Google+

Greg Knoke is a technical writer in the Google Drive Developer Relations Team. Prior to joining Google, he worked as a scientist developing image and signal processing algorithms. His current interests include new technologies, content management, information architecture, cooking, music, and photography.

If your app needs to keep up with changes in Drive, whether to sync files, initiate workflows, or just keep users up to date with the latest info, you’re likely familiar with Drive’s changes feed. But periodic polling for changes has always required a delicate balance between resources and timeliness.

Now there’s a better way. With push notifications for the Drive API, periodic polling is no longer necessary. Your app can subscribe for changes to a user’s drive and get notified whenever changes occur.

Suppose your app is hosted on a server with my-host.com domain and push notifications should be delivered to an HTTPS web-hook https://my-host.com/notification:


  String subscriptionId = UUID.randomUUID().toString();
  Channel request = new Channel()
    .setId(subscriptionId)
    .setType("web_hook")
    .setAddress("https://my-host.com/notification");
  drive.changes().watch(request).execute();
 

As long as the subscription is active, Google Drive will trigger a web-hook callback at https://my-host.com/notification. The app can then query the change feed to catch up from the last synchronization point:


  changes = service.changes().list()
    .setStartChangeId(lastChangeId).execute();
 

If your app only needs to be notified about changes to a particular file or folder your app can watch just those files rather than the entire change feed.

If you are interested in using this new feature, please refer to the documentation at developers.google.com. You can see push notifications in action with the Push Notifications Playground and view the source at Github.



Steven Bazyl   profile | twitter

Steve is a Developer Advocate for Google Drive and enjoys helping developers build better apps.

Many developers have come to prefer JSON for data serialization, but we recognize that good ol' XML is still an important format for many Apps Script users. Our existing XML service is good at parsing XML, but has limited ability to create or alter existing documents. In order to provide a more complete and consistent experience, we have created a new XML service, which launches today. The new service is accessed using XmlService, in contrast to the old service which was simply called Xml.

Let's take a look at how you can use the new service to create an XML representation of the emails in your Gmail inbox.

function createXml() {
  var root = XmlService.createElement('threads');
  var threads = GmailApp.getInboxThreads();
  for (var i = 0; i < threads.length; i++) {
    var child = XmlService.createElement('thread')
        .setAttribute('messageCount', threads[i].getMessageCount())
        .setAttribute('isUnread', threads[i].isUnread())
        .setText(threads[i].getFirstMessageSubject());
    root.addContent(child);
  }
  var document = XmlService.createDocument(root);
  var xml = XmlService.getPrettyFormat().format(document);
  Logger.log(xml);
}

The code above logs XML that looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<threads>
  <thread messageCount="1" isUnread="true">
    Can't wait for the new XML service!
  </thread>
  <thread messageCount="1" isUnread="true">
    50% off all widgets through Friday
  </thread>
  <thread messageCount="3" isUnread="false">
    Don't forget about the picnic on Saturday
  </thread>
</threads>

The new XML service has some notable advantages over the old service:

  • The ability to alter parsed XML content and save it back to a string.
  • Access to all entity types in the XML document (CDATA sections, Comments, etc.)
  • More control over the formatting of the XML string.

With the launch of this new service, we are deprecating some of our older XML tools in Apps Script, specifically the old XML service, the SOAP service, and the JavaScript feature E4X. Calls to these services will continue to work, but we encourage you to start migrating your code to the new XML service for better long-term support. On February 1, 2014, these old services will no longer appear in auto-complete or in our documentation, per the Apps Script sunset schedule.