Google Developers Blog

Developer Student Clubs: A Walk That Changed Healthcare

Wednesday, August 21, 2019

Posted by Erica Hanson, Program Manager ARUA, UGANDA - Samuel Mugisha is a 23 year old university student with a laugh that echoes off every wall and a mind determined to make change. Recently he heard from a healthcare worker that many children at a local clinic were missing vaccinations, so he decided to take a walk. He toured his community, neighbor to neighbor, and asked one simple question: “Can I see your vaccination card?” In response he was given dirt stained, wrinkled, torn pieces of paper, holding life or death information - all written in scribble. He squinted, held the cards to the light, rubbed them on his pant leg, but for no use. They were impossible to read. As Samuel put it, “They were broken.” From the few cards he could read, Samuel noted children who had missed several vaccinations - they were unknowingly playing the odds, waiting to see if disease would find them. “Looking through the cards, you could tell these kids had missed several vaccinations.” Without hesitation, Samuel got right to work, determined to fix the healthcare system with technology. He first brought together his closest friends from Developer Student Clubs (DSC), a program supporting students impacting their communities through tech. He asked them: “Why can’t technology solve our problem?”

This newly formed team, including Samuel, Joshwa Benkya and Norman Acidri, came up with a twofold plan:

Create a mobile app to replace the broken cards, so healthcare workers can clearly track which vaccines their young patients have received.

Create a notification to alert healthcare workers when a child is due for a new vaccination.

The idea came together right as Developer Student Clubs launched its first Solution Challenge, an open call for all members to submit projects they recently imagined. These young developers had to give it a shot. They created a model, filled out an application, and pitched the idea. After waiting a month, they heard back - their team won the competition! Their idea was selected from a pool of 170 applicants across India, Africa, and Indonesia. In other words, everything was about to change. In a country where talent can go unnoticed and problems often go unsolved, this new team had pushed through the odds. Developer Student Clubs is a platform for these types of bold thinkers. Students who view the issues of their region not simply as obstacles to overcome, but chances to mend their home, build a better life for themselves, and transform the experiences of their people. The goal of the Solution Challenge, and all other DSC programs, is to educate young developers early and equip them with the right skills to make an impact in their community. In this case, office space in Uganda was expensive and hard to find. Samuel’s team previously had few chances to all work under the same roof. After winning the challenge, Developer Student Clubs helped them find a physical space of their own to come together and collaborate - a simple tool, but one that led to a turning point. As Samuel described it, “Developer Student Clubs helped us not be alone and apart from each other while trying to solve this problem. They gave us the space to come together and learn. We could all be in the same room, thinking together.”

With this new space to work, DSC then brought some of Africa’s best Google Developer Group Leads directly to the young developers. In these meetings, the students were given high-level insights on how to best leverage Android, Firebase, and Presto to propel their product forward. As Samuel put it: “If we wanted to learn something, they gave us the best expert.” As a result, the team realized that with the scarcity of internet in Uganda, Firebase was the perfect technology to build with - allowing healthcare workers to use the app offline but “check in” and receive updates when they were able to find internet. Although the app has made impressive strides since winning the competition, this young team knows they can make it even better. They want to improve its usability by implementing more visuals and are working to create a version for parents, so families can track the status of their child’s vaccination on their own. While there is plenty of work ahead, with these gifted students and Developer Student Clubs taking each step forward together, any challenge seems solvable. What has the team been up to recently? From August 5th-9th they attended the Startup Africa Roadtrip, an intensive training week on how best to refine a startup business model.

The Speed Benefit of AMP Prerendering

Wednesday, August 14, 2019

Posted By Eric Steinlauf, Software Engineer, Google Today we want to walk through some updated analysis on the benefit that prerendering can provide on load times. AMP is designed to reduce page load time, and one of the most important ways Google Search reduces page load time is through privacy-preserving-prerendering AMP documents before a link is clicked. First Viewport Ready The AMP framework has been designed to understand the layout of all page content and the loading status of all resources, so it can determine the time when all "above the fold" content has loaded. It also knows when the document is prerendered and when it is displayed. Thus, the AMP framework can compute the time from click until the above the fold content is displayed. AMP measures page load speed with a custom metric called First Viewport Ready (FVR). This is defined as the point in time "when non-ad resources above the fold fired their load event measured from the time the user clicks (So takes pre-rendering into account)". If an AMP document is fully prerendered this metric will be 0. If prerendering was not complete at the time of click or if the document was not prerendered at all, then the metric will be greater than 0. Google Search prerenders some AMP documents and not others so we are able to see the impact that prerendering has on FVR. The chart below shows percentiles for FVR with and without prerendering. FVR is 0 when the AMP framework successfully completes prerendering before the document is displayed.

Chart showing percentiles for FVR with and without prerendering

First Contentful Paint First Contentful Paint (FCP) is a page load speed metric that is measured by the browser. It is available for all documents, not just AMP documents. FCP is the point in time when the first bit of content from the DOM is rendered. A high value for FCP indicates that a page is definitely slow, but a low value for FCP does not necessarily mean that a page loads quickly since the first bit may not be important content. This is useful, but since AMP has a better understanding of what content is visible, FVR gives a better understanding of when content becomes visible. FCP is not aware of prerendering so AMP computes a prerender sensitive derivative metric, Prerender-adjusted First Contentful Paint (PFCP), that subtracts out the time before click. When not prerendered, PFCP = FCP. FCP also decreases with prerendering, but the difference is less dramatic than FVR.

It may be surprising that median prerendered PFCP is higher than median prerendered FVR. This happens because the browser has to draw the content to the screen after the click. PFCP includes that time, while FVR does not. Conclusion Prerendering AMP documents leads to substantial improvements in page load times. Page load time can be measured in different ways, but they consistently show that prerendering lets users see the content they want faster. For now, only AMP can provide the privacy preserving prerendering needed for this speed benefit. In the future, new web platform features, such as Signed Exchanges, will bring privacy-preserving instant loading to non-AMP documents too.

Coral summer updates: Post-training quant support, TF Lite delegate, and new models!

Tuesday, August 6, 2019

Posted by Vikram Tank (Product Manager), Coral Team

Coral’s had a busy summer working with customers, expanding distribution, and building new features — and of course taking some time for R&R. We’re excited to share updates, early work, and new models for our platform for local AI with you. The compiler has been updated to version 2.0, adding support for models built using post-training quantization—only when using full integer quantization (previously, we required quantization-aware training)—and fixing a few bugs. As the Tensorflow team mentions in their Medium post “post-training integer quantization enables users to take an already-trained floating-point model and fully quantize it to only use 8-bit signed integers (i.e. `int8`).” In addition to reducing the model size, models that are quantized with this method can now be accelerated by the Edge TPU found in Coral products. We've also updated the Edge TPU Python library to version 2.11.1 to include new APIs for transfer learning on Coral products. The new on-device back propagation API allows you to perform transfer learning on the last layer of an image classification model. The last layer of a model is removed before compilation and implemented on-device to run on the CPU. It allows for near-real time transfer learning and doesn’t require you to recompile the model. Our previously released imprinting API, has been updated to allow you to quickly retrain existing classes or add new ones while leaving other classes alone. You can now even keep the classes from the pre-trained base model. Learn more about both options for on-device transfer learning. Until now, accelerating your model with the Edge TPU required that you write code using either our Edge TPU Python API or in C++. But now you can accelerate your model on the Edge TPU when using the TensorFlow Lite interpreter API, because we've released a TensorFlow Lite delegate for the Edge TPU. The TensorFlow Lite Delegate API is an experimental feature in TensorFlow Lite that allows for the TensorFlow Lite interpreter to delegate part or all of graph execution to another executor—in this case, the other executor is the Edge TPU. Learn more about the TensorFlow Lite delegate for Edge TPU. Coral has also been working with Edge TPU and AutoML teams to release EfficientNet-EdgeTPU: a family of image classification models customized to run efficiently on the Edge TPU. The models are based upon the EfficientNet architecture to achieve the image classification accuracy of a server-side model in a compact size that's optimized for low latency on the Edge TPU. You can read more about the models’ development and performance on the Google AI Blog, and download trained and compiled versions on the Coral Models page. And, as summer comes to an end we also want to share that Arrow offers a student teacher discount for those looking to experiment with the boards in class or the lab this year. We're excited to keep evolving the Coral platform, please keep sending us feedback at coral-support@google.com.

Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints

Wednesday, July 31, 2019

Updated by Shilpa Kamalakar, Technical Program Manager We have invested heavily in our API and service infrastructure to improve performance and security and to add features developers need to build world-class APIs. As we make changes we must address features that are no longer compatible with the latest architecture and business requirements. The JSON-RPC protocol (http://www.jsonrpc.org/specification) and Global HTTP Batch (example) are two such features. Our support for these features was based on an architecture using a single shared proxy to receive requests for all APIs. As we move towards a more distributed, high performance architecture where requests go directly to the appropriate API server we can no longer support these global endpoints. We had originally planned to decommission these features by Mar 25, 2019. However, it came to our attention that few highly impacted customers might not have received the earlier notification. As a result, we are extending the deprecation timeline to Aug 12, 2020, when we will discontinue support for both these features. Starting February 2020 and running through August 2020, we will periodically inject errors for short windows of time. Closer to February 2020, we will provide exact details and schedule of these error injection windows. We know that these changes have customer impact and have worked to make the transition steps as clear as possible. Please see the guidance below which will help ease the transition. How do I know if I should migrate ?JSON-RPC To identify whether you use JSON-RPC, you can check whether you send requests to "https://www.googleapis.com/rpc" or "https://content.googleapis.com/rpc". If you do, you should migrate. HTTP batch A batch request is homogenous if the inner requests are addressed to the same API, even if addressed to different methods of the same API. Homogenous batching will still be supported but through API specific batch endpoints. If you are currently forming homogeneous batch requests, using Google API Client Libraries or using non-Google API client libraries or no client library (i.e making raw HTTP requests), you should migrate. A batch request is heterogeneous if the inner requests go to different APIs. Heterogeneous batching will not be supported after the turn down of the Global HTTP batch endpoint. If you are currently forming heterogeneous batch requests, change your client code to send only homogenous batch requests, i.e you should migrate. What do you need to do to migrate ? Clients will need to make the changes outlined below to migrate. JSON-RPCUsing Client Libraries If you are using JSON-RPC client libraries (either the Google published libraries or other libraries), switch to REST client libraries and modify your application to work with REST client libraries. Example code for Javascript
Before
// json-rpc request for the list method gapi.client.rpcRequest('zoo.animals.list', 'v2', {name:'giraffe'}).execute(x=>console.log(x)) After
// json-rest request for the list method gapi.client.zoo.animals.list({name:'giraffe'}).then(x=>console.log(x)) Not Using Client Libraries i.e making raw HTTP requests If you are not using client libraries (i.e. making raw HTTP requests):

Use the REST URLs, and

Change how you form the request and parse the response.

Example code

Before

// Request URL (JSON-RPC)
POST https://content.googleapis.com/rpc?alt=json&key=xxx
// Request Body (JSON-RPC)
[{
  "jsonrpc":"2.0",
  "id":"gapiRpc",
  "method":"zoo.animals.list",
  "apiVersion":"v2",
  "params":{"name":"giraffe"}
}]

After

// Request URL (JSON-REST)
GET 
https://content.googleapis.com/zoo/v2/animals?name=giraffe&key=xxx

HTTP batch Heterogeneous batch requests If you are currently forming heterogeneous batch requests, change your client code to send only homogenous batch requests. Example code
The example demonstrates how we can split a heterogeneous batch request for 2 apis (urlshortener and zoo) into 2 homogeneous batch requests. Before// heterogeneous batch request example. // Notice that the outer batch request contains inner API requests // for two different APIs. // Request to urlshortener API request1 = gapi.client.urlshortener.url.get({"shortUrl": "http://goo.gl/fbsS"}); // Request to zoo API request2 = gapi.client.zoo.animals.list(); // Request to urlshortener API request3 = gapi.client.urlshortener.url.get({"shortUrl": "https://goo.gl/XYFuPH"}); // Request to zoo API request4 = gapi.client.zoo.animal().get({"name": "giraffe"}); // Creating single heterogeneous batch request object heterogeneousBatchRequest = gapi.client.newBatch(); // adding the 4 batch requests heterogeneousBatchRequest.add(request1); heterogeneousBatchRequest.add(request2); heterogeneousBatchRequest.add(request3); heterogeneousBatchRequest.add(request4); // print the heterogeneous batch request heterogeneousBatchRequest.then(x=>console.log(x)); After// Split heterogeneous batch request into two homogenous batch requests // Request to urlshortener API request1 = gapi.client.urlshortener.url.get({"shortUrl": "http://goo.gl/fbsS"}); // Request to zoo API request2 = gapi.client.zoo.animals.list(); // Request to urlshortener API request3 = gapi.client.urlshortener.url.get({"shortUrl": "http://goo.gl/fbsS"}) // Request to zoo API request4 = gapi.client.zoo.animals.list(); // Creating homogenous batch request object for urlshorterner homogenousBatchUrlshortener = gapi.client.newBatch(); // adding the 2 batch requests for urlshorterner homogenousBatchUrlshortener.add(request1); homogenousBatchUrlshortener.add(request3); // Creating homogenous batch request object for zoo homogenousBatchZoo = gapi.client.newBatch(); // adding the 2 batch requests for zoo homogenousBatchZoo.add(request2); homogenousBatchZoo.add(request4); // print the 2 homogenous batch request Promise.all([homogenousBatchUrlshortener,homogenousBatchZoo]) .then(x=>console.log(x)); Homogeneous batch requests Google API client libraries If you are using Google API Client Libraries, these libraries have been regenerated to no longer make requests to the global HTTP batch endpoint. Recommendation for clients using these libraries is to upgrade to the latest version if possible. Please see the language specific guidance below for minimum Google API Client Library to upgrade to. 1. Java

Minimum Google Client Library Version supported is 1.23.1.
Consumer Steps
1. Update all Google API Service packages (`com.google.apis`) to a version where the supporting library version is 1.23.1 or higher. For example, upgrade `com.google.apis:google-api-services-drive` from version `v3-rev159-1.22.0` to `v3-rev20190620-1.30.1`.
2. Please ensure you are creating your BatchRequest (i.e) com.google.api.client.googleapis.batch.BatchRequest instance via your service client. The BatchRequest constructor is now deprecated and will not work in the future. Instead, use your service client’s batch() method to create a new BatchRequest using below example
3. For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
4. Rebuild

2. Python

Minimum Google Client Library Version supported is 1.6.6.

Consumer Steps

Update to version 1.6.6 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

Please note, a warning is included if users try to construct a request with the legacy batch endpoint. See Release notes for reference.

3. PHP

Minimum Google Client Library Version supported is 0.86.

Consumer Steps

Update to version 0.86 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

4. .NET

Minimum Google Client Library Version supported is 1.32.2.

Consumer Steps

Update to version 1.32.2 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

5. Javascript

If you are using Javascript client lib, please reach out to us with your questions and we will do our best to support

6. Objective-C

Minimum Google Client Library Version supported is 1.3.0.

Consumer Steps

Update to version 1.3.0 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

7. Dart

The Google API Dart Client Library does not support these features.

8. Ruby

Minimum Google Client Library Version supported is 0.11.0.

Consumer Steps

Update to version 0.11.0 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

9. Node.js

Minimum Google Client Library Version supported is 1.0.

Consumer Steps

Update to version 1.0 or higher
For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
Rebuild

10. Go

The Google API Go Client Library does not support these features.

11. C++

The Google C++ API Client Library has been deprecated due to unrelated reasons. However, should you need to use the C++ client with batching in the short term, see consumer steps below.

Consumer Steps

Change app code to explicitly pass the non-global batch URL to the C++ client library i.e pass the API-version specific endpoint (example “/batch/library/v1") to the overload method that takes the batch endpoint as an explicit parameter; merely updating the C++ client library to the latest version will not help.
Example code
Before
```
HttpRequestBatch batch(service->transport());
```
After
```
HttpRequestBatch batch(service->transport(), 
service->batch_url());
```
Link, rebuild and redeploy

Non-Google API client libraries or no client library

Change the endpoint from www.googleapis.com/batch to www.googleapis.com/batch/<api>/<version>.

Or, simply read the value of 'batchPath' from the API's discovery doc and use that value.

We’re here to help For help on migration, consult the API documentation or tag Stack Overflow questions with the 'google-api' tag.

Women Techmakers Summit Europe: Supporting Diversity & Inclusion in Tech

Wednesday, July 31, 2019

Posted By Franziska HauckKatharina Lindenthal , Google Developer Relations Europe Once a year, we invite community organizers and influencers from developer groups that support diversity and inclusion in their local tech ecosystem to the Women Techmakers Summit Europe. The Women Techmakers Summit is designed to provide training opportunities, share best practices, show success stories and build meaningful relationships. The fourth edition of the WTM Summit in Europe took place in Warsaw, one of Europe’s most innovative tech and startup ecosystems.

Such positive energy! All 120 attendees of the WTM Summit Europe 2019 Expertise from the Community for the Community The Women Techmakers Summit hosted 120 people, all women and men that are leading tech communities across Europe. With more than half of the sessions being delivered by community influencers, the group came together to share their best practices, learn from each other and discuss all things related to diversity & inclusion. “A fantastic opportunity to meet other community organizers across Europe and learn from each other.” We also invited role models to draw inspiration and motivation from. Head of Google for Startups, Agnieszka Hryniewicz-Bieniek, and Cloud Engineer, Ewa Maciaś, demonstrated that stepping out of our comfort zone is something we should do more and more. No one has the right answers from the start but by trying out new ways, we can carve our individual paths. Fear of failure is real. It should not keep us from experimenting, though. Google’s Natalie Villalobos, head of the Women Techmakers program, and Emma Haruka Iwao, record breaker for calculating the most accurate value of Pi with Google Cloud, gave a glimpse into their personal stories. Their insights? Sometimes we need to go through hard times. They equipped us with the right mindset to push through, become your boss and succeed. This left the attendees with the right motivation to get back to their communities: “This was my first WTM Summit, and it was an incredible experience. I met some amazing ladies and role models, and will be happy to share the inspiration I got with my local community.”

Googler Emma Haruka Iwao sharing her journey to break the world record for calculating the most accurate value of Pi Building the Basis for Diversity and Inclusion “Being at the WTM Summit felt like being inside a family. I felt really included like at no conference before." To make everyone feel welcome, a code of conduct was visible for all attendees, and prayers and parents spaces were provided for all attendees. The itself needed to become the inspiration for community organizers and influencers to carry the learnings back to the communities.

Organizers working together to develop best practices to foster diversity and inclusion in their tech communities Women Techmakers: Changing the Narrative One of the core elements of Women Techmakers is creating and providing community for women in tech. Women Techmakers Ambassadors thrive diversity and inclusion initiatives in their local tech community to help to bring more women into the industry. In Europe, more than 150 WTM Ambassadors from 25 countries support their local tech communities to close the gap between the number of women and men in the industry. Meetup organizers and community advocates who want to achieve parity can join the Women Techmakers program. As members, they are given the tools and opportunities to change the narrative. If you are interested in joining the WTM Ambassadors Program, reach out to WTM-Europe@google.com

International Women's Day'19 featuring Actions on Google

Thursday, July 11, 2019

Posted by Marisa Pareti, Rubi Martinez & Jessica Earley-Cha In celebration of International Women’s Day, Women Techmakers hosted its sixth annual summit series to acknowledge and celebrate women in the tech industry, and to create a space for attendees to build community, hear from industry leaders, and learn new skills. The series featured 19 summits and 305 meetups across 87 countries. This year, Women Techmakers partnered with the Actions on Google team to host technical workshops at these events so attendees could learn the fundamental concepts to develop Actions for the Google Assistant.Together, we created hundreds of new Actions for the Assistant. Check out some of the highlights of this year’s summit in the video below: Technical Workshop Details If you couldn’t attend any of our meetups this past year, we’ll cover our technical workshops now so you can start building for the Assistant from home. The technical workshop kicked off by introducing Actions on Google — the platform that enables developers to build Actions for the Google Assistant. Participants got hands-on experience building their first Action with the following features:

Users can start a conversation by explicitly calling the Action by name, which then responds with a greeting message.

Once in conversation, users are prompted to provide their favorite color. The Action parses the user’s input to extract the information it needs (namely, the color parameter).

If a color is provided, the Action processes the color parameter to auto-generate a “lucky number” to send back to the user and the conversation ends.

If no color is provided, the Action sends the user additional prompts until the parameter is extracted.

Users can explicitly leave the conversation at any time.

During Codelab level 1, participants learned how to parse the user’s input by using Dialogflow, a tool that uses Machine Learning and acted as their Natural Language Processor (NLP). Dialogflow processes what the user says and extracts important information from that input to identify how to fulfill the user’s request. Participants configured Dialogflow and connected it to their code’s back-end using Dialogflow’s inline editor. In the editor, participants added their code and tested their Action in the Action Simulator. In Codelab level 2, participants continued building on their Action, adding features such as:

Supports deep links to directly launch the user into certain points of dialog

Uses utilities provided by the Actions on Google platform to fetch the user’s name and address them personally

Responds with follow-up questions to further the conversation

Presents users with a rich visual response complete with sound effects

Instead of using Dialogflow’s inline editor, participants set up a Cloud Functions for Firebase as their server. You can learn more about developing your own Actions here. To support developers’ efforts in building great Actions for the Google Assistant, the team also has a developer community program. Alex Eremia, a workshop attendee, reflected, “I think voice applications will have a huge impact on society both today and in the future. It will become a natural way we interact with the items around us.” From keynotes, fireside chats, and interactive workshops, the Women Techmakers summit attendees enjoyed a mixture of technical and inspirational content. If you’re interested in learning more and getting involved, follow us WTM on twitter, check out our website and sign up to become a member. To learn more Actions on Google and how to build for the Google Assistant, be sure to follow us on Twitter, and join our Reddit community!

Developer Preview of Local Home SDK

Tuesday, July 9, 2019

Posted by Toni Klopfenstein Recently at Google I/O, we gave you a sneak peek at our new Local Home SDK, a suite of local technologies to enhance your smart home integrations. Today, the SDK is live as a developer preview. We've been working hard testing the platform with our partners, including GE, LIFX, Philips Hue, TP-Link, and Wemo, and are excited to bring you these additional technologies for connecting smart devices to the Google Assistant.

Figure 1: The local execution path This SDK enables developers to more deeply integrate their smart devices into the Assistant by building upon the existing Smart Home platform to create a local execution path via Google Home smart speakers and Nest smart displays. Developers can now run their business logic to control new and existing smart devices in JavaScript that executes on the smart speakers and displays, benefitting users with reduced latency and higher reliability. How it works: The SDK introduces two new intents, IDENTIFY and REACHABLE_DEVICES. The local home platform scans the user's home network via mDNS, UDP, or UPnP to discover any smart devices connected to the Assistant, and triggers IDENTIFY to verify that the device IDs match those returned from the familiar Smart Home API SYNC intent. If the detected device is a hub or bridge, REACHABLE_DEVICES is triggered and treats the hub as the proxy device for communicating locally. Once the local execution path from Google Home to a device is established, the device properties are updated in Home Graph.

Figure 2: The intents used for each execution path When a user triggers a smart home Action that has a local execution path, the Assistant sends the EXECUTE intent to the Google Nest device rather than the developer's cloud fulfillment. The developer's JavaScript app is invoked, which then triggers the Local Home SDK to send control commands to the smart device over TCP, UDP socket, or HTTP/HTTPS requests. By defaulting to local execution rather than the cloud, users experience faster fulfillment of their requests. The execution requests can still be sent to the cloud path in case local execution fails. This redundancy minimizes the possibility of a failed request, and improves the overall user experience. Additional features of the Local Home platform include:

Support for all Wi-Fi-enabled device types and device traits without two-factor authentication enabled.

No user action required to deploy Local Home benefits to all devices.

Easily configure discovery protocols and the hosted JavaScript app URL through the Actions console.

Figure 3: Local Home configuration tool in the Actions console JavaScript apps can be tested on-device, allowing developers to employ familiar tools like Chrome Developer Console for debugging. Because the Local Home SDK works with the existing smart home framework, you can self-certify new apps through the Test suite for smart home as well. Get started To learn more about the Local Home platform, check out the API reference, and get started adding local execution with the developer guide and samples. For general information covering how you can connect smart devices to the Google Assistant, visit the Smart Home documentation, or check out the Local Technologies for the Smart Home talk from Google I/O this year. You can send us any feedback you have through the bug tracker, or engage with the community at /r/GoogleAssistantDev. You can tag your posts with the flair local-home-sdk to help organize discussion.

Google Pay and PayPal expand their integration to give merchants more ways to accept payments online

Thursday, June 20, 2019

Posted by Jose Ugia, Google Developers Engineer We’re thrilled to announce we’ve expanded our collaboration with PayPal to make payments easy and seamless no matter how or where your customers like to shop. Now, you’ll be able to accept PayPal with Google Pay on your app or website in all 24 countries where your customers can link their PayPal account to Google Pay. Here are 5 ways this integration can add value to your business: 1. Reach more customers already set up to pay Hundreds of millions of users already have their payment methods saved to their Google Account. And as of 2018, customers who use their PayPal account to make a purchase on a Google app or service like Google Play and YouTube can automatically choose that PayPal account when they pay with Google Pay—no new setup required. When you enable PayPal as a payment method on your Google Pay integration, all of these customers will be able to seamlessly check out on your website or app.

Users will be able to choose PayPal—or any other payment method—right from the Google Pay payment sheet. 2. Deliver a faster checkout experience with more customer benefits Once users link their PayPal account, they won’t need to sign in to PayPal when they use it with Google Pay. This means they’ll enjoy fewer steps at checkout, which often leads to higher conversion rates. In addition, your customers will get all the advantages that come with their PayPal account—like Purchase Protection and Return Shipping—along with Google Pay’s fast, simple checkout experience and increased security. 3. Give customers more choices at checkout Google Pay lets customers keep all of their payment methods in one place. They’ll easily be able to switch between debit cards, credit cards, their PayPal account, and more just by choosing Google Pay at checkout. 4. Keep the benefits PayPal merchants who enable the acceptance of PayPal through Google Pay can continue to get the PayPal benefits they already enjoy. This includes the ability to receive payments directly to their PayPal Business Account within minutes, no minimum processing requirements, and seller protection on eligible transactions. 5. Integrate with ease If you’ve already implemented Google Pay, enabling PayPal is as easy as adding it to your list of allowed payment methods in the body of your requests: const payPalPaymentMethod = { type: "PAYPAL", parameters: { purchase_context: { purchase_units: [{ payee: { merchant_id: "<YOUR_PAYPAL_ACCOUNT_ID>" } }] } }, tokenizationSpecification: { type: "DIRECT" } }; paymentRequest.allowedPaymentMethods = [payPalPaymentMethod, cardPaymentMethod]; Once you’ve done that, you’ll receive a token you can send to your servers as soon as your customers confirm their transaction. You’ll use this token to issue a call against PayPal’s payment service—see PayPal’s documentation for more details and best practices. If you haven’t implemented Google Pay yet, check out our online API introduction video or our step-by-step guided codelabs for Android and Web to learn more about it. If you prefer to explore on your own, read our documentation. We’re excited to offer developers the best of both worlds with Google Pay and PayPal, all while making payments simpler for customers and businesses around the world. Stay tuned for more updates.

Mail merge with the Google Docs API

Wednesday, June 5, 2019

Posted by Wesley Chun, Developer Advocate, Google Cloud Students and working professionals use Google Docs every day to help enhance their productivity and collaboration. The ability to easily share a document and simultaneously edit it together are some of our users' favorite product features. However, many small businesses, corporations, and educational institutions often find themselves needing to automatically generate a wide variety of documents, ranging from form letters to customer invoices, legal paperwork, news feeds, data processing error logs, and internally-generated documents for the corporate CMS (content management system). Mail merge is the process of taking a master template document along with a data source and "merging" them together. This process makes multiple copies of the master template file and customizes each copy with corresponding data of distinct records from the source. These copies can then be "mailed," whether by postal service or electronically. Using mail merge to produce these copies at volume without human labor has long been a killer app since word processors and databases were invented, and now, you can do it in the cloud with G Suite APIs! While the Document Service in Google Apps Script has enabled the creation of Google Docs scripts and Docs Add-ons like GFormit (for Google Forms automation), use of Document Service requires developers to operate within the Apps Script ecosystem, possibly a non-starter for more custom development environments. Programmatic access to Google Docs via an HTTP-based REST API wasn't possible until the launch of the Google Docs API earlier this year. This release has now made building custom mail merge applications easier than ever! Today's technical overview video walks developers through the concept and flow of mail merge operations using the Docs, Sheets, Drive, and Gmail APIs. Armed with this knowledge, developers can dig deeper and access a fully-working sample application (Python), or just skip it and go straight to its open source repo. We invite you to check out the Docs API documentation as well as the API overview page for more information including Quickstart samples in a variety of languages. We hope these resources enable you to develop your own custom mail merge solution in no time!

Google Pay launches new, dynamic features for Online Payments and Passes APIs

Tuesday, June 4, 2019

Posted by Stephen McDonald, Google Developers Engineer and Jose Ugia, Google Developers Engineer At Google I/O 2019, we shared some of the new features we’re adding to Google Pay and discussed how you can use them to add value to your customers—whether you accept payments on your app or website or engage with customers beyond payments through loyalty cards, offers, event tickets, and boarding passes. Read on for a summary of what we covered during the event. If you want to hear the full story, check out the recordings of our sessions: Building Powerful Checkout Experiences with Google Pay and Engaging Customers Beyond Payments: Tickets, Transit, and Boarding Passes. Making online payments even more seamless Better checkout experiences are more likely to increase your conversions. Here’s a look at some of the ways Google Pay can help you improve your checkout process from start to finish. Dynamic updates for faster checkout In an effort to bring customers more detail and transparency, we’ve made some changes to the Google Pay API. Going forward, the Google Pay payment sheet will display pricing information, so customers can double-check their order before they confirm their purchase. We’re also adding modifiers based on transaction conditions (like shipping options), so customers can see all relevant purchase details quickly, without going back to the merchant site, leading to a faster checkout experience.

Users paying online can see the price of the order dynamically before they initiate the transaction. More payment button options Along with these improvements to the payment sheet, we’re offering creative new button and onboarding options to encourage customers to choose Google Pay for faster checkout. To start, we launched the createButton API for web developers. This enables a dynamic purchase button that uses the right styling and colors and is localized to your user’s device or browser settings. We’ve also been experimenting with personalized buttons that display important information before users enter the checkout flow. For instance, we can show customers exactly what card they’ll be paying with or let them know if they need to sign in or set up Google Pay – and this information is displayed right on the button. As the button is hosted and rendered by Google Pay, all of this happens without you having to make any changes.

createButton API allows to display card information directly on the checkout button Delivering extra value with Google Pay Passes The Google Pay API for Passes lets you connect your business to millions of Android users by linking your loyalty programs, gift cards, offers, boarding passes, and event tickets to their Google Accounts. This year, we’re launching new capabilities and integrations that will help you engage customers at more times and places. High priority notifications for boarding passes Your passengers can add their boarding pass to Google Pay for a seamless check-in experience. Google Pay sends the passengers a high priority notification with their boarding pass just a few hours before their flight so they can easily access it when needed. They’ll also receive notifications with important dynamic information like gate changes or flight delays. These notifications are high priority and will stay prominent on passengers’ phones until they dismiss it or their flight takes off. Integration with the Google Assistant Google’s ecosystem can help create complete user journeys across multiple touchpoints. Earlier this year, we announced the ability to check-in to flights directly from the Google Assistant. Once a flight is ready for check-in, your passenger will receive a notification that takes them directly to the Assistant to complete the process. At the end of this flow, the user is issued a boarding pass that can be accessed from the Assistant or from Google Pay. This is built on top of the Passes API, which means that as an airline, if you already added support for boarding passes, you can just add the check-in with the Assistant integration on top of it.

From left to right: new high priority notifications, integration of Myki card inside of Google Maps, new transit tickets and automatic Gmail import. An open API for transit, with support for dynamic barcodes We’re excited to announce we’re making transit an open API. This means if you’re a transit provider and currently offer barcode tickets for your transportation services, you can now utilize the Passes API to get your tickets digitized in Google Pay. We’ll also be enhancing this API to support dynamic barcodes. The barcodes on customers’ transit tickets or passes will update every few seconds – even if their device is offline. This allows you to increase security -- since your QR codes are changing all the time, it makes it harder to duplicate the ticket.Loyalty Integration with Gmail Now you can also give customers the opportunity to import your loyalty cards to Google Pay right from Gmail—just by adding some markup to your emails. When customers open the Google Pay app, they’ll be shown any loyalty cards from Gmail they haven’t added to Google Pay. With just a tap, they can add them all automatically so they can access them at any time. This feature is currently only available with loyalty programs, but we’ll be expanding to other types of passes in the future. What’s next We’re working on making Passes available to your users on Google even if they haven’t installed the Google Pay app. We are starting with boarding passes and transit tickets, then plan to extend the same functionality to the other Passes. Stay tuned for more. Resources To learn more about Google Pay, visit our developer resources: