Posted:
Over the past few years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new APIs offered developers several improvements over older versions of the API. With each of these introductions, we also announced the deprecation of a set of corresponding APIs.

The deprecation period for these APIs is coming to an end. As of April 20, 2015, we will discontinue these deprecated APIs. Calls to these APIs and any features in your application that depend on them will not work after April 20th.

Discontinued APIReplacement API
Documents List API Drive API
Admin Audit Admin SDK Reports API
Google Apps Profiles Admin SDK Directory API
Provisioning Admin SDK Directory API
Reporting Admin SDK Reports API
Email Migration API v1 Email Migration API v2
Reporting Visualization No replacement available

When updating, we also recommend that you use the opportunity to switch to OAuth2 for authorization. Older protocols, such as ClientLogin, AuthSub, and OpenID 2.0, have also been deprecated and are scheduled to shut down.

For help on migration, consult the documentation for the APIs or ask questions about the Drive API or Admin SDK on StackOverflow.

Posted by Steven Bazyl, Developer Advocate

Posted:
Thorsten Schaeff has been studying Computer Science and Media at the Media University in Stuttgart and the Institute of Art, Design and Technology in Dublin. For the past six months he’s been interning with the Maps for Work Team in London, researching best practice architectures for working with big geo data in the cloud.

Google’s Cloud Platform offers a great set of tools for creating easily scalable applications in the cloud. In this post, I’ll explore some of the special challenges of working with geospatial data in a cloud environment, and how Google’s Cloud can help. I’ve found that there aren’t many options to do this, especially when dealing with complicated operations like geofencing with multiple complex polygons. You can find the complete code for my approach on GitHub.

Geofencing is the procedure of identifying if a location lies within a certain fence, e.g. neighborhood boundaries, school attendance zones or even the outline of a shop in a mall. It’s particularly useful in mobile applications that need to apply this extra context to someone’s exact location. This process isn’t actually as straight forward as you’d hope and, depending on the complexity of your fences, can include some intense calculations and if your app gets a lot of use, you need to make sure this doesn’t impact performance.

In order to simplify this problem this blogpost outlines the process of creating a scalable but affordable geofencing API on Google’s App Engine.

And the best part? It’s completely free to start playing around.
geofencing_API_example.PNG
Geofencing a route through NYC against 342 different polygons that resulted from converting the NYC neighbourhood tabulation areas into single-part polygons.

Getting started

To kick things off you can work through the Java Backend API Tutorial. This uses Apache Maven to manage and build the project.

If you want to dive right in you can download the finished geofencing API from my GitHub account.

The Architecture

The requirements are:

  • Storing complex fences (represented as polygons) and some metadata like a name and a description. For this I use Cloud Datastore, a scalable, fully managed, schemaless database for storing non-relational data. You can even use this to store and serve GeoJSON to your frontend.
  • Indexing these polygons for fast querying in a spatial index. I use an STR-Tree (part of JTS) which I store as a Java Object in memcache for fast access.
  • Serving results to multiple platforms through HTTP requests. To achieve this I use Google Cloud Endpoints, a set of tools and libraries that allow you to generate APIs and client libraries.

That’s all you need to get started - so let’s start cooking!

Creating the Project

To set up the project simply use Apache Maven and follow the instructions here. This creates the correct folder structure, sets up the routing in the web.xml file for use with Google’s API Explorer and creates a Java file with a sample endpoint.

Adding additional Libraries

I’m using the Java Topology Suite to find out which polygon a certain latitude-longitude-pair is in. JTS is an open source library that offers a nice set of geometric functions.

To include this library into your build path you simply add the JTS Maven dependency to the pom.xml file in your project’s root directory.

In addition I’m using the GSON library to handle JSON within the Java backend. You can basically use any JSON library you want to. If you want to use GSON import this dependency.

Writing your Endpoints

Adding Fences to Cloud Datastore

For the sake of convenience you’re only storing the fences’ vertices and some metadata. To send and receive data through the endpoints you need an object model which you need to create in a little Java Bean called MyFence.java.


Now you need to create an endpoint called add. This endpoint expects a string for the group name, a boolean indicating whether to rebuild the spatial index, and a JSON object representing the fence’s object model. From this App Engine creates a new fence and writes it to Cloud Datastore.

Retrieving a List of our Fences

For some use cases it makes sense to fetch all the fences at once in the beginning, therefore you want to have an endpoint to list all fences from a certain group.

Cloud Datastore uses internal indexes to speed up queries. If you deploy the API directly to App Engine you’re probably going to get an error message, saying that the Datastore query you’re using needs an index. The App Engine Development server can auto-generate the indexes, therefore I’d recommend testing all your endpoints on the development server before pushing it to App Engine.

Getting a Fence’s Metadata by its ID

When querying the fences you only return the ids of the fences in the result, therefore you need an endpoint to retrieve the metadata that corresponds to a fence’s id.

Building the Spatial Index

To speed up the geofencing queries you put the fences in an STR tree. The JTS library does most of the heavy lifting here, so you only need to fetch all your fences from the Datastore, create a polygon object for each one and add the polygon’s bounding box to the index.

You then build the index and write it to memcache for fast read access.

Testing a point

You want to have an endpoint to test any latitude-longitude-pair against all your fences. This is the actual geofencing part. That’s so you will be able to know, if the point falls into any of your fences and if so, it should return the ids of the fences the point is in.

For this you first need to retrieve the index from memcache. Then query the index with the bounding box of the point which returns a list of polygons. Since the index only tests against the bounding boxes of the polygons, you need to iterate through the list and test if the point actually lies within the polygon.


Querying for a Polylines or Polygons

The process of testing for a point can easily be adapted to test the fences against polylines and polygons. In the case of polylines you query the index with the polyline’s bounding box and then test if the polyline actually crosses the returned fences.


When testing for a polygon you want to get back all fences that are either completely or partly contained in the polygon. Therefore you test if the returned fences are within the polygon or are not disjoint. For some use cases you only want to return fences that are completely contained within the polygon. In that case you want to delete the not disjoint test in the if clause.

Testing & Deploying to App Engine

To test or deploy your API simply follow the steps in the ‘Using Apache Maven’ tutorial.

Scalability & Pricing

The beauty of this is, since it’s running on App Engine, Google’s platform as a service offering, it scales automatically and you only pay for what you use.

If you want to insure best performance and great scalability you should consider to switch from the free and shared memcache to a dedicated memcache for your application. This guarantees enough capacity for your spatial index and therefore ensures enough space even for a large amount of complex fences.

That’s it - that’s all you need to create a fast and scalable geofencing API.
Preview: Processing Big Spatial Data in the Cloud with Dataflow
In my next post I will show you how I geofenced more than 340 million NYC Taxi locations in the cloud using Google’s new Big Data tool called Cloud Dataflow.

Posted:
As simple as they are, cardboard boxes are pretty great. Maybe you transformed one into a fort or castle growing up. Or maybe your kids took last week’s package delivery and turned the box into a puppet theater. The best part about cardboard is that it can become anything—all you need is your imagination.

It’s this same spirit that inspired our team to turn a smartphone, and some cardboard, into a virtual reality (VR) viewer earlier this year. Suddenly, exploring the Palace of Versailles was as easy as opening an app. And the response was kind of delightful.

We’ve been working to improve Google Cardboard ever since. And today—with more than half a million Cardboard viewers in people’s hands—we've got a fresh round of updates for users, developers, and makers.
cardboard-500k.png
For users: more apps to enjoy, and more places to buy

There are now dozens of Cardboard-compatible apps on Google Play, and starting today we’re dedicating a new collection page to some of our favorites. These VR experiences range from test drives to live concerts to fully-immersive games, and they all have something amazing to offer. So give ‘em a try today, and download the new Cardboard app to watch the collection grow over time.
cardboard-apps-blog-mock-option2.png
Example apps for Cardboard (clockwise, from top left):
Paul McCartney concert, Volvo Reality test drive, Proton Pulse 3D game

If you don’t have a Cardboard viewer yet, you can now pick one up from DODOcase, I Am Cardboard, Knoxlabs, and Unofficial Cardboard. And of course you can always build your own (with new specs below!).

For developers: SDKs for Android and Unity

If you’ve ever tried creating a VR application, then you’ve probably wrestled with issues like lens distortion correction, head tracking, and side-by-side rendering. It’s important to get these things right, but they can suck up all your time—time you’d rather spend on gameplay or graphics.

We want to give you that time back, so today we’re introducing Cardboard SDKs for Android and Unity. The SDKs simplify common VR development tasks so you can focus on your awesome, immersive app. And with both Android and Unity support, you can use the tools you already know and love. Download the SDKs today, and check out apps like Caaaaardboard! and Tilt Brush Gallery to see what’s already possible.

For makers: tool-specific specs, and custom viewer calibration

To help bring VR experiences to everyone, we open sourced a Cardboard viewer specification earlier this year. Since then we’ve seen all sorts of viewers from all sorts of makers, and today we’re investing in this community even further.

For starters, we’re publishing new building specs with specific cutting tools in mind. So whether you’re laser- or die-cutting your Cardboard viewers in high quantities, or carving single units with a blade, we’ve got you covered.

Once you’ve got your custom viewer, we also want to help you tailor the viewing experience to its unique optical layout. So early next year we’ll be adding a viewer calibration tool to the Cardboard SDK. You’ll be able to define your viewer’s base and focal length, for example, then have every Cardboard app adjust accordingly.

For the future: watch this space, and we’re hiring

The growth of mobile, and the acceleration of open platforms like Android make it an especially exciting time for VR. There are more devices, and more enthusiastic developers than ever before, and we can’t wait to see what’s next! We’re also working on a few projects ourselves, so if you’re passionate about VR, you should know we’re hiring.

Here’s to the cardboard box, and all the awesome it brings.

by Andrew Nartker, Product Manager, Google Cardboard

Posted:
App deep links are the new kid on the block in Search results, and they’re picking up speed faster than you can say “Schema.org ViewAction”! For signed-in users, 15% of Google searches on Android now return deep links to apps through App Indexing. And over just the past quarter, we've seen the number of clicks on app deep links jump by 10x.

Based on feedback from developers since we launched publicly App Indexing back in June, we’d like to share with you four key steps to monitor app performance and drive user engagement:

1. Make sure you get access to Webmaster Tools


App indexing is a team effort between you (as an app developer) and your website management team. We recommend working with your webmaster to get access to Webmaster Tools to carefully track app-related issues. Here’s what’s available right now:
  • Errors in indexed pages within apps
  • Weekly clicks and impressions from app deep link via Google search
  • Stats on your sitemap (if that’s how you implemented the app deep links)
...and we plan to add a lot more in the coming months!

Any verified site owner can add a new user. Pick restricted or full permissions, depending on the level of access you’d like. Screen Shot 2014-11-13 at 22.30.47.png

2. Understand how your app is doing in search results


How are users engaging with your app from search results? We’ve introduced two new ways for you to track performance for your app deep links:
  • We now send a weekly clicks and impressions update to the Message center in your Webmaster Tools account.
  • You can now track how much traffic app deep links drive to your app using referrer information - specifically, the referrer extra in the ACTION_VIEW intent. We're working to integrate this information with Google Analytics for even easier access. Learn how to track referrer information on our Developer site.

3. Make sure key app resources can be crawled


Blocked resources are one of the top reasons for the “content mismatch” errors you see in Webmaster Tools’ Crawl Error report. We need access to all the resources necessary to render your app page. This allows us to assess whether your associated web page has the same content as your app page.

To help you find and fix these issues, we’ll now show you the specific resources we can’t access that are critical for rendering your app page. If you see a content mismatch error for your app, look out for the list of blocked resources in “Step 5” of the details dialog: apps roboted content (1).png

4. Watch out for Android App errors


To help you identify errors when indexing your app, we’ll send you messages for all app errors we detect, and will also display most of them in the “Android apps” tab of the Crawl errors report.

In addition to the currently available “Content mismatch” and “Intent URI not supported” error alerts, we’re introducing three new error types:
  • APK not found: we can’t find the package corresponding to the app
  • No first-click free: the link to your app does not lead directly to the content, but requires login to access
  • Back button violation: after following the link to your app, the back button did not return to Search results.

In our experience, the majority of errors are usually caused by a general setting in your app (e.g. a blocked resource, or a region picker that pops up when the user tries to open the app from Search results). Taking care of that generally resolves it for all involved URIs.

Be sure to visit our codelab to learn how to get your Android app indexed by Google Search. As always, if you have questions, feel free to drop by Stack Overflow or the Webmaster help forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Posted:
The Google Apps Marketplace brings together hundreds of third-party applications that integrate and enhance Google Drive, part of Google Apps for Work, our suite of collaboration and productivity tools for businesses. To improve discoverability and increase adoption, it’s important to make your Google Drive app integration available on the marketplace.

Today, we want to share with you four easy steps to get listed immediately and enable admins to install your application for all users in their domain. For more details, check out the Google Apps Marketplace documentation.

Step 1: Open your Drive project on Google Cloud console. Turn on “Google Apps Marketplace SDK” for your project. Screen Shot 2014-08-20 at 11.50.10 PM.png

Step 2: Click the gear icon to configure “Google Apps Marketplace SDK”. Refer to Google Apps Marketplace documentation for details. In the scopes section, be sure to request the same scopes as your Google Drive application, and check the “Enable Drive extension” checkbox.

Step 3: Go to the Chrome Web Store developer console and select your published Drive application.

Step 4: Update the following line in your Drive application’s Chrome Web Store manifest, upload and publish.

"container":"GOOGLE_DRIVE"
with
“container”: [”GOOGLE_DRIVE”, ”DOMAIN_INSTALLABLE”]


You’re done! You application is now available to all Google Apps for Work customers to install on a domain-wide basis through the Google Apps Marketplace. Refer to Publishing your app documentation for details. You can access Google Apps Marketplace inside Google Admin Console and verify your newly listed application.

Please subscribe to the Google Apps Marketplace G+ community for the latest updates.
Posted by Hiranmoy Saha, Software Engine, Google Apps Marketplace

Posted:

Posted by Lucia Fedorova, Tech Lead, Google Calendar API

At Google we like to make 10x rather than 10% improvements. In this spirit, we are increasing the default quota for the Calendar API v3 by a factor of ten, to 1 million requests per day. That means your application can support ten times as many users without any need to apply for more quota.

And if you need even more free quota, you can apply for it in the developer console under APIs -> Calendar API -> Quota -> “Apply for higher quota.” We have also streamlined the process of quota handling to make sure you receive your quota as quickly as possible.

A few tips to work efficiently with your quota:

  • Use push notifications instead of polling.
  • If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
  • Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
  • Increase page size to retrieve more data at once by using the maxResults parameter.
  • Update events when they change, avoid re-creating all the events on every sync.
  • Use exponential backoff for error retries.

Posted:
We currently provide a robust array of content and resources online, including documentation, SDKs, and videos, that empower developers to create awesome apps and services on a variety of Google platforms. However, due to the challenge of limited Internet access in many parts of the world, many developers are not able to easily search through our vast library of content.

Today, we’re going to make a select number of resources available for download through a kit, while offline, as part of a pilot to solve the broadband challenge. As an example, you will no longer have to worry about needing to download and install the SDK over a slow or non-existent internet connection when running a code lab, or spending 30 minutes to watch a 10 minute video tutorial on the latest API due to constant buffering.

So far, we distributed more than 2,000 kits through Google Developer Groups in Sub-Saharan Africa, India and Bangladesh. Developers now have offline access to many Google SDKs, developer videos, and documentation when they need them.
devkitcds
The current pilot kit contains:
Check out this document to find out more about the offline developer kit and the many ways you can put it to use, If you are interested in piloting one of these developer kits, please get in touch with a Google Developer Group near you or follow these instructions if you are an organisation like a school, tech hub or incubator.

Posted by Chukwuemeka Afigbo, Program Manager, Developer Ecosystems

Posted:

Code-in 2014 logo

We believe that the key to getting students excited about computer science is to give them opportunities at ever younger ages to explore their creativity with computer science. That’s why we’re running the Google Code-in contest again this year, and today’s the day students can go to the contest site, register and start looking for tasks that interest them.


Ignacio Rodriguez was just 10 years old when he became curious about Sugar, the open source learning platform introduced nationally to students in Uruguay when he was in elementary school. With the encouragement of his teacher, Ignacio started asking questions of the developers writing and maintaining the code and he started playing around with things, a great way to learn to code. When he turned 14 he entered the Google Code-in contest completing tasks that included writing two new web services for Sugar and he created four new Sugar activities. He even continued to mentor other students throughout the contest period.  His enthusiasm for coding and making the software even better for future users earned him a spot as a 2013 Grand Prize Winner.


Ignacio is one of the 1,575 students from 78 countries that have participated in Google Code-in since 2010. We are encouraging 13-17 year old students to explore the many varied ways they can contribute to open source software development through the Google Code-in contest. Because open source is a collaborative effort, the contest is designed as a streamlined entry point for students into software development by having mentors assigned to each task that a student works on during the contest. Students don’t have to be coders to participate; as with any software project, there are many ways to contribute to the project.  Students will be able to choose from documentation, outreach, research, training, user interface and quality assurance tasks in addition to coding tasks.


This year, students can choose tasks created by 12 open source organizations working on
disaster relief, content management, desktop environments, gaming, medical record systems for developing countries, 3D solid modeling computer-aided design and operating systems to name a few.  


For more information on the contest, please visit the contest site where you can find the timeline, Frequently Asked Questions and information on each of the open source projects students can work with during the seven week contest.


Good luck students!

By Stephanie Taylor, Open Source Programs

Posted:
As a member of the Google Analytics Developer Relations team, I often hear from our community that they want to do more with GA but don't always know how. They know the basics but want to see full examples and demos that show how things should be built.

Well, we've been listening, and today I'm proud to announce the launch of Google Analytics Demos & Tools, a new website geared toward helping Google Analytics developers tackle the challenges they face most often.

The site aims to make experienced developers more productive (we use it internally all the time) and to show new users what's possible and inspire them to leverage the platform to improve their business through advanced measurement and analysis.

Google Analytics Developers Image
Some highlights of the site include a full-featured Enhanced Ecommerce demo with code samples for both Google Analytics and Google Tag Manager, a new Account Explorer tool to help you quickly find the IDs you need for various Google Analytics services and 3rd party integrations, several examples of easy-to-build custom dashboards, and some old favorites like the Query Explorer.

Google Analytics Demos & Tools not only shows off Google Analytics technologies, it also uses them under the hood. All pages that require authorization use the Embed API to log users in, and usage statistics, including outbound link clicks, authorization status, client-side exceptions, and numerous other user interaction events are measured using analytics.js.

Every page that makes use of a Google Analytics technology lists that information in the footer, making it easy for developers to see how all the pieces fit together. In addition, the entire site is open sourced and available on Github, so you can dive in and see exactly how everything works.

Feedback is welcome and appreciated!

Posted By Philip Walton, Developer Programs Engineer

Posted:
Google APIs give you the power to build rich integrations with our most popular applications, including Google Maps, YouTube, Gmail, Google Drive and more. If you are new to our developer features, we want to give you a quick jumpstart on how to use them effectively and build amazing things.

As you saw last week, we’re excited to partner with the Startup Launch team to create the “Launchpad Online”, a new video series for a global audience that joins their cadre which already includes the established “Root Access” and “How I:” series, as well as a “Global Spotlight” series on some of the startups that have benefitted from the Startup Launch program. This new series focuses on developers who are beginners to one or more Google APIs. Each episode helps get new users off the ground with the basics, shows experienced developers more advanced techniques, or introduces new API features, all in as few lines of code as possible.

The series assumes you have some experience developing software and are comfortable using languages like Javascript and Python. Be inspired by a short working example that you can drop into your own app and customize as desired, letting you “take off” with that great idea. Hopefully you had a chance to view our intro video last week and are ready for more!

Once you’ve got your developers ready to get started, learn how to use the Google Developers Console to set up a project (see video to the right), and walk through common security code required for your app to access Google APIs. When you’ve got this “foundation” under your belt, you’ll be ready to build your first app… listing your files on Google Drive. You’ll learn something new and see some code that makes it happen in each future episode… we look forward to having you join us soon on Launchpad Online!

Posted by Wesley Chun, Developer Advocate, Google

+Wesley Chun (@wescpy) is an engineer, author of the bestselling Core Python books, and a Developer Advocate at Google, specializing in Google Drive, Google Apps Script, Gmail, Google Apps, cloud computing, developer training, and academia. He loves traveling worldwide to meet Google users everywhere, whether at a developers conference, user group meeting, or on a university campus!