Friday, December 23, 2011

[Gd] Managing groups using the new Groups Settings API

| More

Google Apps Developer Blog: Managing groups using the new Groups Settings API

The recently launched Groups Settings API allows Google Apps domain administrators to write client applications for managing groups in their domain. Once you have created the groups and added members using the Provisioning API, you can use the Groups Settings API to perform actions like:

  • manage access to the group
  • configure discussion archiving
  • configure message moderation
  • edit a group's description, display format and custom fields

Let’s have a look at how you can make authorized calls to the Groups Settings API from your client application.

Getting Started

You must enable the Provisioning API to make requests to the Groups Settings API.You can do so by enabling the Provisioning API checkbox in the Domain settings tab of your Google Apps control panel.

Next, ensure that the Google Groups for Business and Email services are added to your domain by going to the Dashboard. If these services are not listed, add them by going to Add more services link next to the Service settings heading.

Now you are set to write client applications. Let's discuss the steps to write an application using the Python client library. You need to install the google-api-python-client library first.

You can register a new project or use an existing one from the APIs console to obtain credentials to use in your application. The credentials (client_id, client_secret) are used to obtain OAuth tokens for authorization of the API requests.

Authorization using OAuth 2.0

The Groups Settings API supports various authorization mechanisms, including OAuth 2.0. Please see the wiki for more information on using the library’s support for OAuth 2.0 to create a httplib2.Http object. This object is used by the Groups Settings service to make authorized requests.

Make API requests with GroupSettings service

The Python client library uses the Discovery API to build the Groups Settings service from discovery. The method build is defined in the library and can be imported to build the service. The service can then access resources (‘groups’ in this case) and perform actions on them using methods defined in the discovery metadata.

The following example shows how to retrieve the properties for the group

service = build(“groups”, “v1”, http=http) 
group = service.groups()
g = group.get(groupUniqueId=””).execute()

This method returns a dictionary of property pairs (name/value):

group_name = g['name']
group_isArchived = g['isArchived']
group_whoCanViewGroup = g['whoCanViewGroup']

The update method can be used to set the properties of a group. Let’s have a look at how you can set the access permissions for a group:

body = {'whoCanInvite': ALL_MANAGERS_CAN_INVITE,
'whoCanJoin': ‘INVITED_CAN_JOIN’,
'whoCanPostMessage': ‘ALL_MEMBERS_CAN_POST’,
'whoCanViewGroup': ‘ALL_IN_DOMAIN_CAN_VIEW’

# Update the properties of group
g1 = group.update(groupUniqueId=groupId, body=body).execute()

Additional valid values for these properties, as well as the complete list of properties, are documented in the reference guide. We have recently added a sample in the Python client library that you can refer to when developing your own application. We would be glad to hear your feedback or any queries you have on the forum.

Shraddha Gupta   profile

Shraddha is a Developer Programs Engineer for Google Apps. She has her MTech in Computer Science and Engineering from IIT Delhi, India.


[Gd] Fridaygram: goodbye to 2011

| More

The official Google Code blog: Fridaygram: goodbye to 2011

Author Photo
By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.


[Gd] Download search queries data using Python

| More

Official Google Webmaster Central Blog: Download search queries data using Python

Webmaster level: Advanced

For all the developers who have expressed interest in getting programmatic access to the search queries data for their sites in Webmaster Tools, we've got some good news. You can now get access to your search queries data in CSV format using a open source Python script from the webmaster-tools-downloads project. Search queries data is not currently available via the Webmaster Tools API, which has been a common API user request that we're considering for the next API update. For those of you who need access to search queries data right now, let's look at an example of how the search queries downloader Python script can be used to download your search queries data and upload it to a Google Spreadsheet in Google Docs.

Example usage of the search queries downloader Python script
1) If Python is not already installed on your machine, download and install Python.
2) Download and install the Google Data APIs Python Client Library.
3) Create a folder and add the script to the newly created folder.
4) Copy the script to the same folder as and edit it to replace the example values for “website,” “email” and “password” with valid values for your Webmaster Tools verified site.
5) Open a Terminal window and run the script by entering "python" at the Terminal window command line:
6) Visit Google Docs to see a new spreadsheet containing your search queries data.

If you just want to download your search queries data in a .csv file without uploading the data to a Google spreadsheet use instead of in the example above.

You could easily configure these scripts to be run daily or monthly to archive and view your search queries data across larger date ranges than the current one month of data that is available in Webmaster Tools, for example, by setting up a cron job or using Windows Task Scheduler.

An important point to note is that this script example includes user name and password credentials within the script itself. If you plan to run this in a production environment you should follow security best practices like using encrypted user credentials retrieved from a secure data storage source. The script itself uses HTTPS to communicate with the API to protect these credentials.

Take a look at the search queries downloader script and start using search queries data in your own scripts or tools. Let us know if you have questions or feedback in the Webmaster Help Forum.

Written by Jonathan Simon, Webmaster Trends Analyst

[Gd] Getting to know the Android Developer Challenge finalists

| More

The official Google Code blog: Getting to know the Android Developer Challenge finalists

Author Photo
By Chukwuemeka Afigbo, Program Manager, Sub-Saharan Africa

Cross-posted from the Google Africa Blog

Last month, the five finalists of the Android Developer Challenge came together to share their experiences with the world via Google+ Hangouts. 

Selected from a group of more than 200 submissions and 30 semi-finalists, the five finalists were Chike Maduegbuna, Bobola Oniwura and Tope Omotunde of AfriNolly (Nigeria); David Lemayian of Olalashe (Kenya); Gerald Kibugi of Shopper’s Delight (Kenya); Herko Lategan of Rainbow Racer (South Africa); and Richard Marsh of Wedding Plandroid (South Africa). 

The interview was hosted by CP Africa, a popular African blog and Gbenga Sesan, Nigerian tech evangelist, who conducted the interview while sitting in the departure lounge of the Murtala Mohammed International Airport in Lagos as he waited to board his flight to Addis Ababa.

Thanks to the power of the internet and Google+, the interview was held simultaneously in Nigeria, Kenya and South Africa, in collaboration with three developer hubs: Umbono (Cape Town, South Africa), Co Creation Hub (Lagos, Nigeria) and iHub (Nairobi, Kenya). The finalists answered live questions and questions from people around the world including Ghana, Italy, Malaysia, Mali, Nigeria and Uganda using Google Moderator

The top-voted question was on how to prioritize features when building an application, while another participant wanted to know what kind of changes the finalists hoped to create in Africa with their applications. 

To learn more about the finalists for the Android Developer Challenge and their applications, please visit the new case studies section of the Google Africa Developers website. If you create solutions using Google services for developers (Google Apps, Chrome extensions, Android, App Engine, etc.) and want to share your story with the world, let us know!

Chukwuemeka Afigbo is a Program Manager in the Sub-Saharan Africa Outreach Team. He is an avid football (soccer) fan.

Posted by Scott Knaster, Editor

[Gd] Google Prediction API: faster, easier to use, and more accurate

| More

The official Google Code blog: Google Prediction API: faster, easier to use, and more accurate

Author Photo
By Marc Cohen, Developer Relations

This holiday season, the Google Prediction API Team is bringing you four presents and, thanks to the joys of cloud computing, no reindeer are required for delivery. Here’s what you’ve already received:
  • Faster on-ramp: We’ve made it easier to get started by enabling you to create an empty model (by sending a trainedmodels.insert request with no storageDataLocation specified) and add training data using the trainedmodels.update method. This change allows you to submit your model contents without needing to stage the data in Google Cloud Storage.
  • Improved updates: The algorithms used to implement model updates (adding additional data to existing models) have been modified to work faster than ever.
  • More classification algorithms: We’ve increased the number of classification algorithms used to build predictive models, resulting in across-the-board improvements in accuracy.
  • Integration with Google Apps Script: Prediction services are now available as part of Google Apps Script, which means you can integrate prediction services with Google Docs, Google Maps, Gmail, and other great Google products.
All of the above enhancements are supported by the current Prediction API version 1.4 so you can enjoy these features using the existing client libraries.

Happy Holidays from the Google Prediction API Team. We’re looking forward to bringing you more exciting features in 2012!

Marc Cohen is a member of Google’s Developer Relations Team in Seattle. When not teaching Python programming and listening to indie rock music, he enjoys using the Google Prediction API to peer into the future.

Posted by Scott Knaster, Editor

Thursday, December 22, 2011

[Gd] Building a Meeting Scheduler for Android using the new Calendar API

| More

Google Apps Developer Blog: Building a Meeting Scheduler for Android using the new Calendar API

Though developers are quite comfortable thinking in abstractions, we still find a lot of value in code examples and fully developed sample applications. Judging by the volume of comments, tweets, and git checkouts of the Au-to-do sample code we released a few weeks ago, our readers agree.

For Google Apps API developers who want to get started writing mobile apps, here’s a great new resource: a sample application that integrates Google Calendar API v3 with Android and illustrates best practices for OAuth 2.0. This meeting scheduler app built by Alain Vongsouvanh gets the user’s contact list, lets users select attendees, and matches free/busy times to suggest available meeting times. It provides a simple Android UI for user actions such as attendee selection:

The sample code for Meeting Scheduler demonstrates many key aspects of developing with Google Apps APIs. After authorizing all required access using OAuth 2.0, the Meeting Scheduler makes requests to the Calendar API. For example, the class FreeBusyTimesRetriever queries the free/busy endpoint to find available meeting times:

FreeBusyRequest request = new FreeBusyRequest();

request.setTimeMin(getDateTime(startDate, 0));
request.setTimeMax(getDateTime(startDate, timeSpan));

for (String attendee : attendees) {
requestItems.add(new FreeBusyRequestItem().setId(attendee));

FreeBusyResponse busyTimes;
try {
Freebusy.Query query = service.freebusy().query(request);
// Use partial GET to retrieve only needed fields.
busyTimes = query.execute();
// ...
} catch (IOException e) {
// ...

In this snippet above, note the use of a partial GET request. Calendar API v3, along with many other new Google APIs, provides partial response with GET and PATCH to retrieve or update only the data fields you need for a given request. Using these methods can help you streamline your code and conserve system resources.

For the full context of all calls that Meeting Scheduler makes, including OAuth 2.0 flow and the handling of expired access tokens, see Getting Started with the Calendar API v3 and OAuth 2.0 on Android. The project site provides all the source code and other resources, and there’s a related wiki page with important configuration details.

We hope you’ll have a look at the sample and let us know what you think in the Google Apps Calendar API forum. You’re welcome to create a clone of the source code and do some Meeting Scheduler development of your own. If you find a bug or have an idea for a feature, don’t hesitate to file it for evaluation.

Eric Gilmore  

Eric is a technical writer working with the Developer Relations group. Previously dedicated to Google Enterprise documentation, he is now busy writing about various Google Apps APIs, including Contacts, Calendar, and Provisioning.


[Gd] Optimizing bandwidth usage with gzip compression

| More

Google Apps Developer Blog: Optimizing bandwidth usage with gzip compression

All developers agree that saving bandwidth is a critical factor for the success of a mobile application. Less data usage means faster response times and also lower costs for the users as the vast majority of mobile data plans are limited or billed on a per-usage basis.

When using any of the Google Data APIs in your application, you can reduce the amount of data to be transferred by requesting gzip-encoded responses. On average, the size of a page of users returned by the Provisioning API (100 accounts) is about 100 Kb, while the same data, gzip-encoded, is about 5 Kb -- 20 times smaller! When you can reduce data sizes at this dramatic scale, the benefits of compression will often outweigh any costs in client-side processing for decompression.

Enabling gzip-encoding in your application requires two steps. You have to edit the User-Agent string to contain the value gzip and you must also include an Accept-Encoding header with the same value. For example:

User-Agent: my application - gzip
Accept-Encoding: gzip

Client libraries for the various supported programming languages make enabling gzip-encoded responses even easier. For instance, in the .NET client library it is as easy as setting the boolean UseGZip flag of the RequestFactory object:

service.RequestFactory.UseGZip = true;

For any questions, please get in touch with us in the respective forum for the API you’re using.

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Website user research and testing on the cheap

| More

Official Google Webmaster Central Blog: Website user research and testing on the cheap

Webmaster level: Intermediate

As the team responsible for tens of thousands of Google’s informational web pages, the Webmaster Team is here to offer tips and advice based on their experiences as hands-on webmasters.

If you’ve never tested or analyzed usage of your website, ask yourself if you really know whether your site is useful for your target audience. If you’re unsure, why not find out? For example, did you know that on average users scroll down 5.9 times as often as they scroll up, meaning that often once page content is scrolled past, it is “lost?” (See Jakob Nielsen’s findings on scrolling, where he advises that users don’t mind scrolling, but within limits.)

Also, check your analytics—are you curious about high bounce rates from any of your pages, or very short time-on-page metrics?

First, think about your user

The start of a web project—whether it’s completely new or a revamp of an existing site—is a great time to ask questions like:

  • How might users access your site—home, office, on-the-go?
  • How tech-savvy are your visitors?
  • How familiar are users with the subject matter of your website?

The answers to some of these questions can be valuable when making initial design decisions.

For instance, if the user is likely to be on the road, they might be short on time to find the information they need from your site, or be in a distracting environment and have a slow data connection—so a simple layout with single purpose would work best. Additionally, if you’re providing content for a less technical audience, make sure it’s not too difficult to access content—animation might provide a “wow” factor, but only if your user appreciates it and it’s not too difficult to get to the content.

Even without testing, building a basic user profile (or “persona”) can help shape your designs for the benefit of the user—this doesn’t have to be an exhaustive biography, but just some basic considerations of your user’s behavior patterns.

Simple testing

Testing doesn’t have to be a costly operation – friends and family can be a great resource. Some pointers:

  • Sample size: Just five people can be a large enough number of users to find common problems in your layouts and navigation (see Jakob Nielsen’s article on why using a small sample size is sufficient).
  • Choosing your testers: A range of different technical ability can be useful, but be sure to only focus on trends—for example, if more than 50% of your testers have the same usability issue, it’s likely a real problem—rather than individual issues encountered.
  • Testing location: If possible, visit the user in their home and watch how they use the site—observe how he/she normally navigates the web when relaxed and in their natural environment. Remote testing is also a possibility if you can’t make it in person—we’ve heard that Google+ hangouts can be used effectively for this (find out more about using Google+ hangouts).
  • How to test: Based on your site’s goals, define 4 or 5 simple tasks to do on your website, and let the user try to complete the tasks. Ask your testers to speak aloud so you can better understand their experiences and thought processes.
  • What to test: Basic prototypes in clickable image or document format (for example, PDF) or HTML can be used to test the basic interactions, without having to build out a full site for testing. This way, you can test out different options for navigation and layouts to see how they perform before implementing them.
  • What not to test: Focus on functionality rather than graphic design elements; viewpoints are often subjective. You would only get useful feedback on design from quantitative testing with large (200+) numbers of users (unless, for example, the colors you use on your site make the content unreadable, which would be good feedback!). One format for getting some useful feedback on the design can be to offer 5-6 descriptive keywords and ask your user to choose the most representative ones.
Overall, basic testing is most useful for seeing how your website’s functionality is working—the ease of finding information and common site interactions.

Lessons learned

In case you’re still wondering whether it’s really worth research and testing, here are a few simple things we confirmed from actual users that we wouldn’t have known if we hadn’t sat with actual users and watched them use our pages, or analyzed our web traffic.

  • Take care when using layouts that hide/show content: We found when using scripts to expand and collapse long text passages, the user often didn’t realize the extra content was available—effectively “hiding” the JavaScript-rendered content when the user searches within the page (for example, using Control + F, which we’ve seen often).

    Wireframe of layout tested, showing “zipped”
    content on the bottom left

    Final page design showing anchor links in the top
    and content laid out in the main body of the page

  • Check your language: Headings, link and button text are what catches the user’s eye the most when scanning the page. Avoid using “Learn more…” in link text—users seem averse to clicking on a link which implies they will need to learn something. Instead, just try to use a literal description of what content the user will get behind the link—and make sure link text makes sense and is easy to understand out of context, because that is often how it will be scanned. Be mindful about language and try to make button text descriptive, inviting and interesting.
  • Test pages on a slower connection: Try out your pages using different networks (for example, try browsing your website using the wifi at your local coffee shop or a friend’s house), especially if your target users are likely to be viewing your pages from a home connection that’s not as fast as your office network. We found a considerable improvement in CTR and time-on-site metrics in some cases when we made scripted animations much simpler and faster (hint: use Google’s Page Speed Online to check performance if you don’t have access to a slower Internet connection).
So if you’re caught up in a seemingly never-ending redevelopment cycle, save yourself some time in the future by investing a little up front through user profiling and basic testing, so that you’re more likely to choose the right approach for your site layout and architecture.

We’d love to hear from you in the comments: have you tried out website usability testing? If so, how did you get on, and what are your favorite simple and low-cost tricks to get the most out of it?

Tuesday, December 20, 2011

[Gd] Speed metrics in Google Analytics

| More

The official Google Code blog: Speed metrics in Google Analytics

Author Photo
By Satish Kambala, Staff Software Engineer

At Google we believe that speed matters and a faster web is better for everyone. That’s why we started the Make The Web Faster initiative. To improve the speed of a website, we need to measure how fast web pages load. The Site Speed report, which is now available by default to all users of Google Analytics, provides just that: it enables website owners to measure page load time for their web pages.

You can use the Site Speed report to correlate speed with other metrics in Google Analytics, such as page views and conversions. This enables website owners to identify and optimize those pages that drive these metrics. Page load times can be analyzed by browser type or user location to understand if specific optimizations are required. Recently, we enhanced the Site Speed report by adding a new section called Technical (see screenshot below) which displays network and server time components of page load time.

site speed report screen shot

You can learn more about the Site Speed report here. This report, along with powerful page speed analysis tools such as Page Speed Online, will help website owners delight their users by building fast and responsive websites.

Have ideas on how to make your website faster or ways to speed up the entire Web? Send us your thoughts.

Satish Kambala works at Google on stuff that helps in making the web faster. In his free time, apart from watching cricket and movies, Satish likes exploring places with his wife.

Posted by Scott Knaster, Editor

[Gd] Announcing the Archive Feed of the Documents List API

| More

Google Apps Developer Blog: Announcing the Archive Feed of the Documents List API

Users of the Google Documents List API have traditionally had to perform individual export operations in order to export their documents. This is quite inefficient, both in terms of time and bandwidth for these operations.

To improve latency for these operations, we have added the Archive Feed to the API. Archives allow users to export a large number of items at once, in single ZIP archives. This feature provides a useful optimization for users, greatly increasing the efficiency of export operations. Additionally, users can receive emails about archives, and choose to download them from a link provided in the email.

This feature had a soft release earlier this year, and we think it’s now ready for prime time. For more information, please see the Archive Feed documentation.

Vic Fryzel profile | twitter | blog

Vic is a Google engineer and open source software developer in the United States. His interests are generally in the artificial intelligence domain, specifically regarding neural networks and machine learning. He's an amateur robotics and embedded systems engineer, and also maintains a significant interest in the security of software systems and engineering processes behind large software projects.

[Gd] Doodles for your Google Apps domain

| More

Google Apps Developer Blog: Doodles for your Google Apps domain

Since 1998, when the first doodle was released, they have been one of the most loved features of the Google home page. There have been doodles to celebrate all kinds of events, including national holidays, birthdays of artists and scientists, sports competitions, scientific discoveries and even video games! Also, doodles have evolved from simple static images to complex applications, such as the interactive electric guitar used to celebrate the birthday of Les Paul.

Want your company logo to change for selected events or holidays, just like doodles? The Admin Settings API allows domain administrators to write scripts to programmatically change the logo of their Google Apps domain, and Google App Engine offers the ability to configure regularly scheduled tasks, so that those scripts can run automatically every day.

With these two pieces combined, it is pretty easy to implement a complete solution to change the domain logo on a daily basis (assuming the graphic designers have prepared a doodle for each day), as in the following screenshot:

Let’s start with a Python App Engine script called

import gdata.apps.adminsettings.service
from google.appengine.ext import webapp
from google.appengine.ext.webapp import util
from datetime import date

class DoodleHandler(webapp.RequestHandler):
# list of available doodles
'1-1': 'images/newyearsday.jpg',
'2-14': 'images/valentinesday.jpg',
'10-31': 'images/halloween.jpg',
'12-25': 'images/christmas.jpg'

# returns the path to the doodle corresponding to the date
# or None if no doodle is available
def getHolidayDoodle(self, date):
key = '%s-%s' % (date.month,
if key not in self.DOODLES:
return None

return self.DOODLES[key]

# handles HTTP requests by setting today’s doodle
def get(self):
doodle = self.getHolidayDoodle(

if doodle:
service = gdata.apps.adminsettings.service.AdminSettingsService()
// replace domain, email and password with your credentials
// or change the authorization mechanism to use OAuth
service.domain = 'MYDOMAIN.COM' = 'ADMIN@MYDOMAIN.COM'
service.password = 'MYPASSWORD'
service.source = 'DoodleApps'

# reads the doodle image and update the domain logo
doodle_bytes = open(doodle, "rb").read()

# webapp initialization
def main():
application = webapp.WSGIApplication([('/', DoodleHandler)],

if __name__ == '__main__':

The script uses a set of predefined doodles which can be edited to match your list of images or replaced with more sophisticated logic, such as using the Google Calendar API to get the list of holidays in your country.

Every time the script is triggered by an incoming HTTP request, it will check whether a doodle for the date is available and, if there is one, update the domain logo using the Admin Settings API.

In order for this script to be deployed on App Engine, you need to to configure the application by defining a app.yaml file with the following content:

application: doodleapps
version: 1
runtime: python
api_version: 1

- url: .*

We want the script to run automatically every 24 hours, without the need for the administrator to send a request, so we also have to define another configuration file called cron.yaml:

- description: daily doodle update
url: /
schedule: every 24 hours

Once the application is deployed on App Engine, it will run the script on a daily basis and update the logo.

The holiday season is upon us. Could there be a better time for your company to start using doodles?

Happy Holidays!

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Domain user management with Apps Script

| More

Google Apps Developer Blog: Domain user management with Apps Script

Managing the user accounts in a Google Apps domain can be a daunting task when you have hundreds or thousands of them and you have no tools to automate the process. The Google Apps Provisioning API allows developers to write user management applications in the programming language of their choice, but many system administrators prefer a script-based solution instead. The recently launched UserManager Apps Script service fills the gap, providing Google Apps domain administrators an easy way to automate tasks such as batch user creation or update.

With the new Apps Script service, creating a user will be as easy as writing a single line of code:

var user = UserManager.createUser("newuser", "John", "Smith", "mypassword");

The UserManager service also makes it easy to perform the same task on each account in the domain. The following sample shows how you can force all users to change their passwords at the next login:

var users = UserManager.getAllUsers();
for (var i in users) {

Calls to the UserManager service can also be scheduled to run hourly or daily, or in response to certain events thanks to Apps Script Triggers.

Interested in what else you can do with the UserManager service? Please check the documentation and get in touch with us on the the forum for any questions about its usage or to share more info about your project with the community.

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Watch out for XmlPullParser.nextText()

| More

Android Developers Blog: Watch out for XmlPullParser.nextText()

Jesse Wilson

[This post is by Jesse Wilson from the Dalvik team. —Tim Bray]

Using XmlPullParser is an efficient and maintainable way to parse XML on Android. Historically Android has had two implementations of this interface:

The implementation from Xml.newPullParser() had a bug where calls to nextText() didn’t always advance to the END_TAG as the documentation promised it would. As a consequence, some apps may be working around the bug with extra calls to next() or nextTag():

    public void parseXml(Reader reader)
throws XmlPullParserException, IOException {
XmlPullParser parser = Xml.newPullParser();

parser.require(XmlPullParser.START_TAG, null, "menu");
while (parser.nextTag() == XmlPullParser.START_TAG) {
parser.require(XmlPullParser.START_TAG, null, "item");
String itemText = parser.nextText();
parser.nextTag(); // this call shouldn’t be necessary!
parser.require(XmlPullParser.END_TAG, null, "item");
System.out.println("menu option: " + itemText);
parser.require(XmlPullParser.END_TAG, null, "menu");

public static void main(String[] args) throws Exception {
new Menu().parseXml(new StringReader("<?xml version='1.0'?>"
+ "<menu>"
+ " <item>Waffles</item>"
+ " <item>Coffee</item>"
+ "</menu>"));

In Ice Cream Sandwich we changed Xml.newPullParser() to return a KxmlParser and deleted our ExpatPullParser class. This fixes the nextTag() bug. Unfortunately, apps that currently work around the bug may crash under Ice Cream Sandwich:

org.xmlpull.v1.XmlPullParserException: expected: END_TAG {null}item (position:START_TAG <item>@1:37 in 
at com.publicobject.waffles.Menu.parseXml(
at com.publicobject.waffles.Menu.main(

The fix is to call nextTag() after a call to nextText() only if the current position is not an END_TAG:

  while (parser.nextTag() == XmlPullParser.START_TAG) {
parser.require(XmlPullParser.START_TAG, null, "item");
String itemText = parser.nextText();
if (parser.getEventType() != XmlPullParser.END_TAG) {
parser.require(XmlPullParser.END_TAG, null, "item");
System.out.println("menu option: " + itemText);

The code above will parse XML correctly on all releases. If your application uses nextText() extensively, use this helper method in place of calls to nextText():

  private String safeNextText(XmlPullParser parser)
throws XmlPullParserException, IOException {
String result = parser.nextText();
if (parser.getEventType() != XmlPullParser.END_TAG) {
return result;

Moving to a single XmlPullParser simplifies maintenance and allows us to spend more energy on improving system performance.


Monday, December 19, 2011

[Gd] Simple development of App Engine apps using Cloud SQL - Introducing Google Plugin for Eclipse 2.5

| More

Google App Engine Blog: Simple development of App Engine apps using Cloud SQL - Introducing Google Plugin for Eclipse 2.5

Since we added SQL support to App Engine in the form of Google Cloud SQL, the Google Plugin for Eclipse (GPE) team has been working hard on improving the developer experience for developing App Engine apps that can use a Cloud SQL instance as the backing database.

We are pleased to announce the availability of Google Plugin for Eclipse 2.5. GPE 2.5 simplifies app development by eliminating the need for manual tasks like copying Cloud JDBC drivers, setting classpaths, typing in JDBC URLs or filling in JVM arguments for connecting to local/remote database instances.

GPE 2.5 provides support for:

  • Configuring Cloud SQL/MySQL instances

  • Auto-completion for JDBC URLs

  • Creating database connections in Eclipse database development perspective

  • OAuth 2.0 for authentication.

Configuring Cloud SQL/MySQL instances
App Engine provides a local development environment in which you can develop and test your application before deploying to App Engine. With GPE 2.5, you now have the ability to configure your local development server to use a local MySQL instance or a Cloud SQL instance for testing. When you choose to deploy your app, it will use the configured Cloud SQL instance for App Engine.

Auto-completion for JDBC URLs
GPE 2.5 supports auto-completion for JDBC URLs, and quick-fix suggestions for incorrect JDBC URLs.

Creating database connections in Eclipse database development perspective
The Eclipse database development perspective can be used to configure database connections, browse the schema and execute SQL statements on your database.

Using GPE 2.5, database connections are automatically configured in the Eclipse database development perspective for the Development SQL instance and the App Engine SQL instance.

You can also choose to manually create a new database connection for a Cloud SQL instance. In GPE 2.5, we have added a new connection profile for Cloud SQL.

GPE 2.5 now uses OAuth 2.0 (earlier versions were using OAuth 1.0)  to securely access Google services (including Cloud SQL) from GPE. OAuth 2.0 is the latest version of the OAuth protocol focussing on simplicity of client development.

Can’t wait to get started?
Download GPE here and write your first App Engine and Cloud SQL application using GPE by following the instructions here.

We hope GPE 2.5 will make cloud application development using App Engine and Cloud SQL a breeze. We always love to hear your feedback and the GPE group is a great place to share your thoughts.

Posted on behalf of the Google Plugin for Eclipse Team


Sunday, December 18, 2011

[Gd] Android 4.0.3 Platform and Updated SDK tools

| More

Android Developers Blog: Android 4.0.3 Platform and Updated SDK tools

Today we are announcing Android 4.0.3, an incremental release of the Android 4.0 (Ice Cream Sandwich) platform. The new release includes a variety of optimizations and bug fixes for phones and tablets, as well as a small number of new APIs for developers. The new API level is 15.

Some of the new APIs in Android 4.0.3 include:

Social stream API in Contacts provider: Applications that use social stream data such as status updates and check-ins can now sync that data with each of the user’s contacts, providing items in a stream along with photos for each. This new API lets apps show users what the people they know are doing or saying, in addition to their photos and contact information.

Calendar provider enhancements. Apps can now add color to events, for easier tracking, and new attendee types and states are now available.

New camera capabilities. Apps can now check and manage video stabilization and use QVGA resolution profiles where needed.

Accessibility refinements. Improved content access for screen readers and new status and error reporting for text-to-speech engines.

Incremental improvements in graphics, database, spell-checking, Bluetooth, and more.

For a complete overview of what’s new in the platform, see the Android 4.0.3 API Overview.

Going forward, we’ll be focusing our partners on Android 4.0.3 as the base version of Ice Cream Sandwich. The new platform will be rolling out to production phones and tablets in the weeks ahead, so we strongly encourage you to test your applications on Android 4.0.3 as soon as possible.

We would also like to remind developers that we recently released new version of the SDK Tools (r16) and of the Eclipse plug-in (ADT 16.0.1). We have also updated the NDK to r7.

Visit the Android Developers site for more information about Android 4.0.3 and other platform versions. To get started developing or testing on the new platform, you can download it into your SDK using the Android SDK Manager.


[Gd] Google Groups and Google Apps Script

| More

Google Apps Developer Blog: Google Groups and Google Apps Script

Google Groups is a great way to foster communication over email and on the web, connecting people and allowing them to participate in and read archived discussions. Today, we are introducing the Google Groups Service in Google Apps Script. Groups Service will allow a script to check if a user belongs to a certain group, or to enumerate the members of a particular group. The Google Groups Service works with groups created through the Google Groups web interface as well as groups created by enterprise customers with their own domain using the control panel and the Google Apps Provisioning API.

This opens a wide range of possibilities, such as allowing a script with Ui Services to show additional buttons to the members of a particular group - for example teachers or managers - and sending customized emails to all the members of a group.

Here are a few sample scripts to help you get started with the new API. To try out these samples, select Create > New Spreadsheet and then Tools > Script Editor from the menu. You can then copy the code into the script editor. The scripts’ output will appear back in the spreadsheet.

List Your Google Groups

The Groups Services can be used to fetch a list of the Google Groups of which you’re a member.

Below is a function which returns all the groups of which you’re a member. Copy and paste it into the script editor and run it. The editor will prompt you to grant READ access to the Google Groups Service before the script can run successfully.

If you receive a message stating that you’re not a member of any group, open up Google Groups and join any of the thousands of groups there.

function showMyGroups() {
var groups = GroupsApp.getGroups();
var s;
if (groups.length > 0) {
s = "You belong to " + groups.length + " groups: ";
for (var i = 0; i < groups.length; i++) {
var group = groups[i];
if (i > 0) {
s += ", ";
s += group.getEmail();
} else {
s = "You are not a member of any group!";

Test Group Membership

Brendan plays trumpet in a band. He also runs the band’s website and updates its Google+ page. He’s created a web application with Google Apps Script and now he wants to add to it some additional features for members of the band. Being a model Google user, he’s already subscribed each band member to a Google Group. Although building a complete UI with Google Apps Script is beyond the scope of this article, Brendan could adapt the following function to help make additional features available only to members of that Google Group.

Of course, this is not just useful for tech-savvy trumpet players: schools may wish to make certain features available just to teachers or others just to students; businesses may need to offer certain functionality to people managers or simply to show on a page or in a UI operations of interest to those in a particular department. Before running this example yourself, replace with the email address of any group of which you’re a member.

Note: the group’s member list must be visible to the user running the script. Generally, this means you must yourself be a member of a group to successfully test if another user is a member of that same group. Additionally, group owners and managers can restrict member list access to group owners and managers. For such groups, you must be an owner or manager of the group to query membership.

function testGroupMembership() {
var groupEmail = "";
var group = GroupsApp.getGroupByName(groupEmail);
if (group.hasUser(Session.getActiveUser().getEmail())) {
Browser.msgBox("You are a member of " + groupEmail);
} else {
Browser.msgBox("You are not a member of " + groupEmail);

Get a List of Group Members

Sending an email to the group’s email address forwards that message to all the members of the group. Specifically, that message is forwarded to all those members who subscribe by email. Indeed, for many users, discussion over email is the principal feature of Google Groups.

Suppose, however, that you want to send a customised message to those same people. Provided you have permission to view a group’s member list, the Google Groups Service can be used to fetch the usernames of all the members of a group. The following script demonstrates how to fetch this list and then send an email to each member.

Before running this script, consider if you actually want to send a very silly message to all the members of the group. It may be advisable just to examine how the script works!

function sendCustomizedEmail() {
var groupEmail = "";
var group = GroupsApp.getGroupByEmail(groupEmail);
var users = group.getUsers();
for (var i = 0; i < users.length; i++) {
var user = users[i];
MailApp.sendEmail(user.getEmail(), "Thank you!",
"Hello " + user.getEmail() + ", thank you for joining this group!");

Find Group Managers

The Google Groups Service lets you query a user’s role within a group. One possible role is MANAGER (the other roles are described in detail in the Google Groups Service’s documentation): these users can perform administrative tasks on the group, such as renaming the group and accepting membership requests. Any user’s Role can be queried with the help of the Group class’ getRole() method.

This sample function may be used to fetch a list of a group’s managers. Once again, you must have access to the group’s member list for this function to run successfully:

function getGroupOwners(group) {
var users = group.getUsers();
var managers = [];
for (var i = 0; i < users.length; i++) {
var user = users[i];
if (group.getRole(user) == GroupsApp.Role.MANAGER) {
return managers;

Let us know what you end up building, or if you have any questions about this new functionality, by posting in the Apps Script forum.

Trevor Johnston  

Trevor is a software engineer at Google. Before joining the Google Apps Script team in New York, he developed travel products in Switzerland and supported Google’s help centers in Dublin. Prior to joining Google, he worked on Lotus branded products at IBM’s Dublin Software Lab.


[Gd] Introducing AdSense Management Services in Apps Script

| More

Google Apps Developer Blog: Introducing AdSense Management Services in Apps Script

Editor's note: this announcement is cross-posted from the Google Ads Developer Blog, which caters to AdWords, AdSense, DoubleClick and AdMob developers. We hope you enjoy this latest addition to Google Apps Script — Ryan Boyd

Starting today, the AdSense Management API is available as part of AdSense Services in Google Apps Script. This means that you’ll be able to do things like:

  • Create AdSense performance reports for your AdSense accounts in a Google spreadsheet
  • Create a chart based on your AdSense reporting data and display it in a Google Spreadsheet
  • Embed your scripts in a Google Sites page, for instance to import a chart
  • Use triggers to schedule the execution of your scripts, for instance to periodically update the chart imported in the Google Sites page

Accessing the API from Google Apps Scripts is very easy. The following snippet of code shows how to generate a report and populate columns of a spreadsheet with the data retrieved:

function generateReport() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var sheet = ss.getSheetByName('Reports');
var startDate = Browser.inputBox(
"Enter a start date (format: 'yyyy-mm-dd')");
var endDate = Browser.inputBox(
"Enter an end date (format: 'yyyy-mm-dd')");
var args = {
'dimension': ['MONTH']};
var report = AdSense.Reports.generate(startDate, endDate, args).getRows();
for (var i=0; i<report.length; i++) {
var row = report[i];
sheet.getRange('A' + String(i+2)).setValue(row[0]);
sheet.getRange('B' + String(i+2)).setValue(row[1]);
sheet.getRange('C' + String(i+2)).setValue(row[2]);
sheet.getRange('D' + String(i+2)).setValue(row[3]);
sheet.getRange('E' + String(i+2)).setValue(row[4]);
If you want to generate a chart from your data instead of populating the spreadsheet, that’s very easy as well:
function generateLineChart() {
var doc = SpreadsheetApp.getActiveSpreadsheet();
var startDate = Browser.inputBox(
"Enter a start date (format: 'yyyy-mm-dd')");
var endDate = Browser.inputBox(
"Enter an end date (format: 'yyyy-mm-dd')");
var adClientId = Browser.inputBox("Enter an ad client id");
var args = {
'filter': ['AD_CLIENT_ID==' + adClientId],
'dimension': ['MONTH']};
var report = AdSense.Reports.generate(startDate, endDate, args).getRows();
var data = Charts.newDataTable()
.addColumn(Charts.ColumnType.STRING, "Month")
.addColumn(Charts.ColumnType.NUMBER, "Page views")
.addColumn(Charts.ColumnType.NUMBER, "Ad requests")
.addColumn(Charts.ColumnType.NUMBER, "Matched ad requests")
.addColumn(Charts.ColumnType.NUMBER, "Individual ad impressions");

// Convert the metrics to numeric values.
for (var i=0; i<report.length; i++) {
var row = report[i];

var chart = Charts.newLineChart()
.setTitle("Performances per Month")

var app = UiApp.createApplication().setTitle("Performances");
var panel = app.createVerticalPanel()
A shiny line chart will be displayed in your spreadsheet, as shown in the following picture:

You can start using the service by checking out the reference documentation, that contains also some sample scripts, and this tutorial that implements the use cases mentioned above.

Happy Google Apps Scripting with the AdSense Management API!

Silvano Luciani   profile

Silvano Luciani joined Google's London office in 2011 to make the AdSense API developers happier people. Before that, he has worked in Finland, Italy, Spain and the UK, writing web based configuration management tools for ISPs, social networks, web based training materials, e-commerce apps and more. He has recently discovered that he loves charts, and has finally started to play the drums in the London’s office music room. If you can call what he does "playing the drums".


[Gd] YouTube Direct Keeps Growing

| More

YouTube API Blog: YouTube Direct Keeps Growing

YouTube Direct, our open source platform for obtaining and moderating user-generated videos (and photos!), was first announced over two years ago. Since that time, the project has continued to grow, and we’re happy to announce the latest round of additional features.

Most notably, we’ve released a completely rewritten YouTube Direct upload client for iOS devices (seen below). You can find it in its own open source project, and it complements the existing upload client for Android devices. As with the Android client, we see the iOS code as a reference implementation and a starting point for developers who want to build their own branded applications that submit video or photos that could be moderated using YouTube Direct.

The biggest change in the 3.0 release of the YouTube Direct server code has to do with multitenancy. As explained in this guide, YouTube Direct administrators can now deploy their code to App Engine once, and have App Engine serve many different logical instances of YouTube Direct, each with their own submission queues and moderators. While not every YouTube Direct deployment will benefit from this new functionality, we see it being particularly useful for agencies and other organizations that might have multiple individual clients, each interested in keeping track of their own YouTube Direct submissions.

YouTube Direct powers a wide variety of video submission initiatives: sites as diverse as the New York Times’ Reflections on 9/11 project,’s “You are not alone” and Google Developers
own “Share your story” page are running by YouTube Direct behind the scenes.

As always, please let us know about any specific issues you encounter with YouTube Direct or either of the mobile clients in the issue trackers associated with each open source project. If you have any general questions about YouTube Direct, we’d be happy to answer them in our YouTube API developer’s forum.

—Jeff Posnick, YouTube API Team