Author Archives: Google Developers

Inviting educators to the Google Developers India Faculty Summit on 23rd April, 2021

Posted by Harsh Dattani, Community Manager

University Professor's have a large impact by educating the next generation of developers and engineers. Google Developers wants to enable university faculty with the best curriculum on Android development and programs. Earlier this year we announced the launch of our new faculty-led curriculum for Android Development with Kotlin in India. The curriculum is based on classroom learning (virtual or in-person) with an instructor delivering lectures on important Android concepts and students receiving hands-on practice through interactive pathways.

The Google Developers India Faculty Summit 2021 will kick things off on April 23rd. The Faculty Development Training program provides professors or faculty from different universities or skilling partners in India with resources designed by a team at Google.

Current partners in India include: Shivaji University, I. K. Gujral Punjab Technical University, Chandigarh University, Ganpat University, Telangana Academy for Skill and Knowledge (TASK), Learn 4 Grow, Teerthanker Mahaveer University and Information, and Communication Technology Academy of Kerala. These organizations will be the first to learn an offer this curriculum to their students with more universities to follow in upcoming semesters

Leading scholars and educational influencers from computer-science faculties at Indian universities will be in attendance, giving attendees the perfect chance to network with other professionals in Android development

Chief guest for the event is Professor Anil D. Sahasrabudhe, Chairman, All India Council for Technical Education (AICTE). As he describes the upcoming summit,

"Google India Faculty Summit 2021 is a great opportunity for faculties of technical institutes to understand & assimilate nuances of Android Application Development using Kotlin and in turn disseminate the same to students, challenge them to create new applications, innovative solutions and make them entrepreneurs/employable engineers."

Register today for the summit here and see you on April 23rd at 10 AM IST.

SignAll SDK: Sign language interface using MediaPipe is now available for developers

A guest post by the Engineering team at SignAll | Twitter handle | MediaPipe team

Please note that the information, uses, and applications expressed in the below post are solely those of our guest author, SignAll.

SignAll SDK: Sign language interface using MediaPipe is now available for developers

When Google published the first versions of its on-device hand tracking technology in MediaPipe, the work could serve as a basis for developers to build sign language recognition solutions into their own apps. Later updates to this hand tracking solution have further improved its accuracy where other technologies have fallen short (Figure 1).

Illustrating MediaPipe’s improvement over time: hand skeleton tracking output of an older version (2020.02.10) and the latest version (2020.12.16).

Figure 1. Illustrating MediaPipe’s improvement over time: hand skeleton tracking output of an older version (2020.02.10) and the latest version (2020.12.16). This handshape is used in sign language frequently, but often missed because of the lack of representation in training datasets.
Watch the full video

SignAll is a startup working on sign language translation technology. Its mission is to make sign language interpretation universally available, both through communication between Deaf and hearing parties, and between Deaf individuals and computers. The SignAll’s products, which are used nationwide in the US for both communications and education, employ a complex multi-camera setup and gloves with colored markers. While sign languages’ complexity goes far beyond handshapes (facial features, body, grammar, etc.), it is true that the accurate tracking of the hands has been a huge obstacle in the first layer of processing – computer vision. MediaPipe unlocked the possibility to offer SignAll’s solutions not only glove free, but also by using a single camera. SignAll has just announced the availability of the first SDK of its kind, so developers can now enable sign language input in their apps.

The company recently published an interactive educational app in the App Store, that lets the user practice signing with immediate feedback, this app also serves as a demonstration of the possibilities with the SDK.

SignAll with MediaPipe Hands

Our system uses several layers for sign recognition, and each one uses more and more abstract data. The low-level layer extracts crucial hand, body, and face data from 2D and 3D cameras. In our first implementation, this layer detects the colors of the gloves and creates 3D hand data. Replacing this with MediaPipe Hands (supplemented by the MediaPipe Pose and MediaPipe Face Mesh) has been a game changer for using our system without gloves or special lighting.

Demo of our SignAll SDK developed using MediaPipe asking how are you
Demo greeting of our SignAll SDK developed using MediaPipe

Figure 2. Demo of our SignAll SDK developed using MediaPipe

As mentioned earlier, we use multiple cameras with depth sensors which are calibrated in the real world. This allows for a more accurate 3D world space than that of a local camera or tensor spaces, but requires the use of hand landmark detection for each camera. The cameras are placed distinctly to each other in position and orientation so the hands are visible more frequently, as one hand might cover the other from one camera but not necessarily from the others.

Corrected 3D hand shape based on three cameras. Due to the unique orientation, the detection from the front camera is wrong, but the side camera can correct the result.

Figure 3. Corrected 3D hand shape based on three cameras. Due to the unique orientation, the detection from the front camera is wrong, but the side camera can correct the result.

The next step is to filter and smooth the data to replicate the precise measurements offered by our colored glove markers. Although SignAll’s markers are different from the landmarks given by MediaPipe, we used our hand model to generate colored markers from landmarks. Therefore, the new mocap data is fully compatible with the previous one.

Although we are focused mainly on the hands, we also integrated MediaPipe Pose and MediaPipe Face Mesh. The pose landmarks provide accurate hand position information, even when touching or close to each other.

While the two versions of mocap are compatible, the nature of the artifacts is different: direct measure of each marker and simulated markers from a globally detected hand. Due to this discrepancy, we had to refine the parameters on higher levels. On the other hand, we could still use our huge sign database for the gloveless configuration. By replacing the low-level data and refining our higher-level data, we could test our system without gloves. Going gloveless can be a huge step for using our sign recognition technology easily worldwide.

Demonstration of compatible mocap from different low-level trackings.

Figure 4. Demonstration of compatible mocap from different low-level trackings. The right side is without gloves; the left side is with gloves. This compatibility enables the usage of SignAll’s meticulously labeled dataset of 300,000+ sign language videos to be used for the training of recognition models based on different low-level data. Watch the full video

The SignAll system using MediaPipe framework

After integrating MediaPipe Hands into our system, we also wanted to take advantage of the customization and scaling opportunities provided by the MediaPipe framework on multiple platforms. This allowed us to not only prototype our research state methods in Python, but also deliver our end-user solutions for Windows, iOS, Android, and even the Web. Thanks to the similarities between our module graph system and the calculator graph of MediaPipe, our existing processing units can be reused in this new framework with minor modifications. With that said, the extended platform set also comes with other challenges, like using only a single 2D camera in most cases instead of a calibrated multi-camera system.

The models, algorithms and techniques we have used were mostly developed to work on our mocap data interpreted in the 3D global world. The data extracted from a single-camera setup, of course, cannot be as detailed. That is the reason we had to make some adjustments to our implementations, fine-tune the algorithms and add some extra logic (e.g., dynamically adapting to the changes of space resulted by the hand-held camera use-case). Luckily, the MediaPipe framework enables us to implement the core processing units in C++, so we can still benefit from the runtime-optimized core solutions we previously developed.

Some higher-level models trained on 3D data also needed to be re-trained in order to perform better on the data originating from a single 2D source. The MediaPipe landmarks are defined by 3D coordinates, which makes it possible to reuse the existing training methods and concepts. On the other hand, the 2D information is more directly extracted and therefore more stable than the third coordinate, which was taken into consideration while designing the training modifications.

Luckily, it is not necessary to make an entirely new data recording for this purpose. We can still use our huge video database annotated in great detail. The preprocessed mocap data we can extract from our recordings and interpreted in the 3D world can be used to simulate hand, skeleton, or face landmark detections in any virtual camera view.

Among the data on virtual camera views, we also use traditional 2D recordings in sufficient proportion to cover the unique noise characteristics of the landmark detections. Thanks to having most of these types of data in advance, we can focus on the most exciting part - trying the latest techniques and training new models.

Summary

The advancement made possible by MediaPipe enabled SignAll to change its model. In addition to offering all-in-one products for sign language education and translation, SignAll is now starting to offer an SDK for developers. The capabilities of this SDK depend on the type of the camera or cameras being used and the available computational capacity. The possible functions enabled by using the SDK vary from launching video calls by signing the contact’s name (watch a demo here), adding addresses into navigation by signing (as a counterpart to speech input), or ordering food on a fast-food restaurant’s kiosk or drive-thru. With its mission to make sign language an alternative everywhere that voice can be used, SignAll is excited to see more and more apps implementing this feature.

We are eager to try future updates of MediaPipe, which could bring us closer to our ultimate goal of having our solutions available for everyone on any device. The most awaited update is the ability to build custom MediaPipe graphs and add our own calculators for web-based solutions aided by the WebAssembly technology, so websites will be able to use a new level of accessibility features for Deaf visitors.

Google Developer Student Club 2021 Lead applications are open!

Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

Hey, student developers! If you’re passionate about programming and are ready to use your technology skills to help your community, then you should become a Google Developer Student Clubs Lead!

Application forms for the upcoming 2021-2022 academic year are NOW OPEN. Get started at goo.gle/gdsc-leads.

Want to know more? Learn more about the program below.

What are Google Developer Student Clubs?

Google Developer Student Clubs are university based community groups for students interested in Google developer technologies. With clubs hosted in 106 countries around the world, students from undergraduate and graduate programs with an interest in leading a community are welcome. Together, students learn the latest in Android App Development, Google Cloud Platform, Flutter, and so much more.

By joining a GDSC, students grow their knowledge in a peer-to-peer learning environment and put theory to practice by building solutions for local businesses and their community.

How will I improve my skills?

As a Google Developer Student Club Lead you will have the chance to…

  • Gain mentorship from Google.
  • Join a global community of leaders.
  • Practice by sharing your skills.
  • Help students grow.
  • Build solutions for real life problems.

How can I find a Google Developer Student Club near me?

Google Developer Student Clubs are now in 106 countries with 1250+ groups. Find a club near you or learn how to start your own, here.

When do I need to submit the Application form?

We encourage students to submit their forms as soon as possible. You can learn more about your region’s application deadline, here. Make sure to learn more about our program criteria.

Get Started

From working to solve the United Nations Sustainable Development Goals to helping local communities make informed voting decisions, Google Developer Student Club leads are learning valuable coding skills while making a true difference. As a lead from a Club in Kuala Lumpur, Malaysia put it,

“The secret to our club’s success was that we were able to cultivate a heart of service and a culture of open mentorship.”

We can’t wait to see what our next group of Google Developer Student Club leads will accomplish this year. Join the fun and get started, here.



*Google Developer Student Clubs are student-led independent organizations, and their presence does not indicate a relationship between Google and the students' universities.

Modernizing your Google App Engine applications

Posted by Wesley Chun, Developer Advocate, Google Cloud

Modernizing your Google App Engine applications header

Next generation service

Since its initial launch in 2008 as the first product from Google Cloud, Google App Engine, our fully-managed serverless app-hosting platform, has been used by many developers worldwide. Since then, the product team has continued to innovate on the platform: introducing new services, extending quotas, supporting new languages, and adding a Flexible environment to support more runtimes, including the ability to serve containerized applications.

With many original App Engine services maturing to become their own standalone Cloud products along with users' desire for a more open cloud, the next generation App Engine launched in 2018 without those bundled proprietary services, but coupled with desired language support such as Python 3 and PHP 7 as well as introducing Node.js 8. As a result, users have more options, and their apps are more portable.

With the sunset of Python 2, Java 8, PHP 5, and Go 1.11, by their respective communities, Google Cloud has assured users by expressing continued long-term support of these legacy runtimes, including maintaining the Python 2 runtime. So while there is no requirement for users to migrate, developers themselves are expressing interest in updating their applications to the latest language releases.

Google Cloud has created a set of migration guides for users modernizing from Python 2 to 3, Java 8 to 11, PHP 5 to 7, and Go 1.11 to 1.12+ as well as a summary of what is available in both first and second generation runtimes. However, moving from bundled to unbundled services may not be intuitive to developers, so today we're introducing additional resources to help users in this endeavor: App Engine "migration modules" with hands-on "codelab" tutorials and code examples, starting with Python.

Migration modules

Each module represents a single modernization technique. Some are strongly recommended, others less so, and, at the other end of the spectrum, some are quite optional. We will guide you as far as which ones are more important. Similarly, there's no real order of modules to look at since it depends on which bundled services your apps use. Yes, some modules must be completed before others, but again, you'll be guided as far as "what's next."

More specifically, modules focus on the code changes that need to be implemented, not changes in new programming language releases as those are not within the domain of Google products. The purpose of these modules is to help reduce the friction developers may encounter when adapting their apps for the next-generation platform.

Central to the migration modules are the codelabs: free, online, self-paced, hands-on tutorials. The purpose of Google codelabs is to teach developers one new skill while giving them hands-on experience, and there are codelabs just for Google Cloud users. The migration codelabs are no exception, teaching developers one specific migration technique.

Developers following the tutorials will make the appropriate updates on a sample app, giving them the "muscle memory" needed to do the same (or similar) with their applications. Each codelab begins with an initial baseline app ("START"), leads users through the necessary steps, then concludes with an ending code repo ("FINISH") they can compare against their completed effort. Here are some of the initial modules being announced today:

  • Web framework migration from webapp2 to Flask
  • Updating from App Engine ndb to Google Cloud NDB client libraries for Datastore access
  • Upgrading from the Google Cloud NDB to Cloud Datastore client libraries
  • Moving from App Engine taskqueue to Google Cloud Tasks
  • Containerizing App Engine applications to execute on Cloud Run

Examples

What should you expect from the migration codelabs? Let's preview a pair, starting with the web framework: below is the main driver for a simple webapp2-based "guestbook" app registering website visits as Datastore entities:

class MainHandler(webapp2.RequestHandler):
'main application (GET) handler'
def get(self):
store_visit(self.request.remote_addr, self.request.user_agent)
visits = fetch_visits(LIMIT)
tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
self.response.out.write(template.render(tmpl, {'visits': visits}))

A "visit" consists of a request's IP address and user agent. After visit registration, the app queries for the latest LIMIT visits to display to the end-user via the app's HTML template. The tutorial leads developers a migration to Flask, a web framework with broader support in the Python community. An Flask equivalent app will use decorated functions rather than webapp2's object model:

@app.route('/')
def root():
'main application (GET) handler'
store_visit(request.remote_addr, request.user_agent)
visits = fetch_visits(LIMIT)
return render_template('index.html', visits=visits)

The framework codelab walks users through this and other required code changes in its sample app. Since Flask is more broadly used, this makes your apps more portable.

The second example pertains to Datastore access. Whether you're using App Engine's ndb or the Cloud NDB client libraries, the code to query the Datastore for the most recent limit visits may look like this:

def fetch_visits(limit):
'get most recent visits'
query = Visit.query()
visits = query.order(-Visit.timestamp).fetch(limit)
return (v.to_dict() for v in visits)

If you decide to switch to the Cloud Datastore client library, that code would be converted to:

def fetch_visits(limit):
'get most recent visits'
query = DS_CLIENT.query(kind='Visit')
query.order = ['-timestamp']
return query.fetch(limit=limit)

The query styles are similar but different. While the sample apps are just that, samples, giving you this kind of hands-on experience is useful when planning your own application upgrades. The goal of the migration modules is to help you separate moving to the next-generation service and making programming language updates so as to avoid doing both sets of changes simultaneously.

As mentioned above, some migrations are more optional than others. For example, moving away from the App Engine bundled ndb library to Cloud NDB is strongly recommended, but because Cloud NDB is available for both Python 2 and 3, it's not necessary for users to migrate further to Cloud Datastore nor Cloud Firestore unless they have specific reasons to do so. Moving to unbundled services is the primary step to giving users more flexibility, choices, and ultimately, makes their apps more portable.

Next steps

For those who are interested in modernizing their apps, a complete table describing each module and links to corresponding codelabs and expected START and FINISH code samples can be found in the migration module repository. We are also working on video content based on these migration modules as well as producing similar content for Java, so stay tuned.

In addition to the migration modules, our team has also setup a separate repo to support community-sourced migration samples. We hope you find all these resources helpful in your quest to modernize your App Engine apps!

Local students team up to help small businesses go online

Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

Recently young developers in Saudi Arabia from Google Developer Student Clubs, a program of university based community groups for students interested in Google technologies, came together to help local small businesses. As more companies across the globe rely on online sales, these students noticed that many of their favorite local stores did not have a presence on the web.

So to help these local shops compete, these up-and-coming developers went into the community and began running workshops to teach local store owners the basics of building a website. Inspired by Google’s fundamentals of digital marketing course, these learning sessions focused on giving small business owners basic front-end skills, while introducing them to easy to use coding tools.

Front-end skills for small business owners

Image of Chrome Devtools

The first goal of these student-run workshops was to teach local store owners the basics of building web interfaces. In particular, they focused on websites that made it easy for customers to make purchases. To do this, the students first taught store owners the basics of HTML, CSS, and JS code. Then, they showed them how to deploy Chrome DevTools, a collection of web developer tools built directly into the Google Chrome browser that allows programmers to inspect and edit HTML, CSS, and JS code to optimize user experience.

Next, the students challenged participants to put their knowledge to use by creating demos of their businesses' new websites. The young developers again used Chrome DevTools to highlight the best practices for testing the demo sites on different devices and screen sizes.

Introduction to coding toolkits

Image of demo created and maintained in workshop.

With the basics of HTML, CSS, JS code, and Chrome DevTools covered, the students also wanted to give the store owners tools to help maintain their new websites. To do this, they introduced the small businesses to three toolkits:

  1. Bootstrap, to help templatize future workflow for the websites.
  2. Codepen, to make testing new features and aspects of the websites easier.
  3. Figma, to assist in the development of initial mockups.

With these basic coding skills, access to intuitive toolkits, and completed website demos, the local businesses owners now had everything they needed to launch their sites to the public - all thanks to a few dedicated students.

Ready to join a Google Developer Student Club near you?

All over the world, students are coming together to learn programming and make a difference in their community as members of local Google Developer Student Clubs. Learn more on how to get involved in projects like this one, here.

Local students team up to help small businesses go online

Posted by Erica Hanson, Global Program Manager, Google Developer Student Clubs

Recently young developers in Saudi Arabia from Google Developer Student Clubs, a program of university based community groups for students interested in Google technologies, came together to help local small businesses. As more companies across the globe rely on online sales, these students noticed that many of their favorite local stores did not have a presence on the web.

So to help these local shops compete, these up-and-coming developers went into the community and began running workshops to teach local store owners the basics of building a website. Inspired by Google’s fundamentals of digital marketing course, these learning sessions focused on giving small business owners basic front-end skills, while introducing them to easy to use coding tools.

Front-end skills for small business owners

Image of Chrome Devtools

The first goal of these student-run workshops was to teach local store owners the basics of building web interfaces. In particular, they focused on websites that made it easy for customers to make purchases. To do this, the students first taught store owners the basics of HTML, CSS, and JS code. Then, they showed them how to deploy Chrome DevTools, a collection of web developer tools built directly into the Google Chrome browser that allows programmers to inspect and edit HTML, CSS, and JS code to optimize user experience.

Next, the students challenged participants to put their knowledge to use by creating demos of their businesses' new websites. The young developers again used Chrome DevTools to highlight the best practices for testing the demo sites on different devices and screen sizes.

Introduction to coding toolkits

Image of demo created and maintained in workshop.

With the basics of HTML, CSS, JS code, and Chrome DevTools covered, the students also wanted to give the store owners tools to help maintain their new websites. To do this, they introduced the small businesses to three toolkits:

  1. Bootstrap, to help templatize future workflow for the websites.
  2. Codepen, to make testing new features and aspects of the websites easier.
  3. Figma, to assist in the development of initial mockups.

With these basic coding skills, access to intuitive toolkits, and completed website demos, the local businesses owners now had everything they needed to launch their sites to the public - all thanks to a few dedicated students.

Ready to join a Google Developer Student Club near you?

All over the world, students are coming together to learn programming and make a difference in their community as members of local Google Developer Student Clubs. Learn more on how to get involved in projects like this one, here.

India’s Google Developer Groups meet up to ace their Google Cloud Certifications

Posted by Biswajeet Mallik, Program Manager, Google Developers India.

Image from Cloud Community Days India

Earlier this year, ten Google Developer Groups in India came together to host Google Cloud Community Days India, a two day event helping developers study for their upcoming Cloud Certification exams. To address the rising demand for professional certifications, the virtual event hosted over 63,000 developers, covered four main exam areas, and welcomed nine speakers. This was the second edition to the event series which started in 2019 in India.

By providing expert learning materials and mentorship, the event uniquely prepared developers for the Associate Cloud Engineer, Professional Data Engineer, Professional Cloud Machine Learning Engineer, and Professional Cloud Architect exams. Learn more below.

Acing the four key certifications

The Cloud Community Days event focused on helping developers study for four milestone certifications, tailored to engineers at four different stages of their career. The goal: help Google Developer Group members obtain the right credentials to improve their job prospects.

The event broke participants into breakout sessions based on which exam they were preparing to take. Since the certifications targeted professionals of all skill levels, study groups ranged from early career associates to late career executives. The learning groups were organized around the following certifications:

  1. Associate Cloud Engineer:

    This learning session was created to help early career developers complete the first stepping stone exam. In particular, learning materials and speakers were curated to guide participants who had no prior experience, or very little, working on the Google Cloud Platform.

    Workshops were mainly dedicated to assisting programmers who were familiar with building different applications but wished to show employers that they could deploy them on Google Cloud Platform.

    Watch more from: Day 1, here. And day 2, here.

  2. Professional Data Engineers:

    The next group brought together were data practitioners with special interests in data visualization and decision making. Workshops and learning activities helped these developers hone their large scale data and data driven decision making abilities.

    Improving these skills are essential for passing the Professional Data Engineers certification and growing a programmer’s early career.

    Watch more from: Day 1, here. And day 2, here.

  3. Professional Cloud Machine Learning Engineer:

    For these sessions, the Google Developer Group Cloud community paired experienced programmers with a significant interest in ML to form their study groups. The main driver in these learning activities was to help seasoned developers gain a deeper understanding of how to utilize Google Cloud ML services.

    With significant emphasis being placed on machine learning in the ecosystem right now, Google Developer Group community leaders felt this certification could help developers make the leap into new leadership roles.

    Watch more from: Day 1, here. And day 2, here.

  4. Professional Cloud Architect:

    Lastly, this event paired experienced Cloud executives and professionals working in leading capacities for their organizations. For these sessions, speakers and activities had a specific scope: help high level professions be at the forefront of Google Cloud Platforms innovative capabilities.

    Specifically, the Professional Cloud Architect Certification was created to help senior software engineers better design, scale and develop highly secure and robust applications.

    Day 1, here. And day 2, here.

Reactions from the community

Overall, the community put together these resources to help developers feel more confident in their abilities, obtain tangible credentials, and in turn increase access to better job opportunities. As two participants recalled the event,

“The session on Qwiklabs was so helpful, and taught me how to anticipate problems and then solve them. Cloud Community Days inspired me to take the next step with DevOps and Google Cloud.”

“This was the first time I attended the Google Developer Group event! It is an awesome package for learning in one place. All the fun activities were engaging and the panelist discussion was also very insightful. I feel proud to be a part of this grand GDG event.”

Start learning with Google Developer Groups

With Google Developer Groups, find a space to learn alongside a group of curious developers, all coming together to advance their careers from withinside a caring community of peers.

Want to know more about what Cloud Community days were like? Then watch their live recording below.

Ready to find a community event near you? Then get started at gdg.community.dev

Evolving Google Workspace Add-ons with Alternate Runtimes

Posted by Charles Maxson, Developer Advocate

Google Workspace Add-ons offer developers a simplified, structured, and safe way of integrating your solutions right within the Google Workspace user experience, allowing you to bring the logic and data of your application right within the reach of billions of Google Workspace users. So whether your goal is to help users avoid switching context from their inbox to your application, or to easily bring in data from your solution to Google Sheets, developing your own Google Workspace Add-ons makes a lot of sense to keep users productive, engaged and focused.

While the concept of Add-ons for Google Workspace isn’t new per se, building add-ons for Google Workspace has come a long way since they were first introduced some years back. Originally designed to allow solution developers to extend our collaboration apps: Google Docs, Sheets, Forms and Slides, it’s now possible to create a single add-on project for Google Workspace that spans the entire suite, including Gmail, Drive and Calendar.

The original design created for our collaboration apps also required you to use HTML, CSS and Google Apps Script to ‘hand roll’ elements like the user interface and events, requiring a bit more do-it-yourself effort (aka code) for developers, resulting in more inconsistency across the add-on market. That has evolved as Google Workspace Add-ons adopted Card-based interfaces more recently, allowing developers to simplify and standardize add-on building by leveraging just their knowledge of Google Apps Script.

Introducing Alternate Runtimes for Google Workspace Add-ons

Today we are pleased to announce that building Google Workspace Add-ons has evolved once again, this time to offer developers an alternative to using Apps Script for building add-ons with the general availability of Alternate Runtimes for Google Workspace Add-ons. Announced via an early access program mid last year, the release of Alternate Runtimes is a major breakthrough for Google Workspace developers who want to use their own development stack: hosting, tools, languages, packages, processes, etc.

While Alternate Runtimes enables the same functionality that Apps Script does for building add-ons, the flexibility and the freedom to choose your dev environment plus the opportunity to decouple from Apps Script will likely yield greater developer productivity and performance gains for future projects. This commonly requested feature by Google Workspace solution developers has finally become a reality.

Technically, there’s a little more effort in using the Alternate Runtimes method, as Apps Script does mask much of the complexity from the developer, but it's essentially swapping in JSON for Apps Script in rendering the Cards service-based interfaces needed to drive Google Workspace Add-ons. Learn more about getting started with Alternate Runtimes here or try the five minute Quickstart for Alternate Runtimes to see it in action.

Also note, whether you are just getting started or you are an experienced add-on builder, we have recently released the GWAO Card Builder tool that allows you to visually design the user interfaces for your Google Workspace Add-ons projects. It is a must-have for add-on developers using either Apps Script or Alternate Runtimes, enabling you to prototype and design Card UIs super fast without hassle and errors of hand coding JSON or Apps Script on your own.

Google Workspace Card Builder Design Tool

Further Introducing the Google Workspace Add-ons Cloud API

Included with this launch of Alternate Runtimes for general availability is also the debut of the Google Workspace Add-ons Cloud API, which allows you to completely forgo using Apps Script for managing Google Workspace Add-on deployments using Alternate Runtimes. Unlike using Alternate Runtimes during the beta program where you still needed to create an Apps Script project to stub out your project endpoints via the manifest file, the Google Workspace Add-ons Cloud API allows you to create and manage your add-on deployment lifecycle with a series of command line instructions.

With the Google Workspace Add-ons Cloud API you can create a deployment, install or delete a deployment, get a list of deployments, manage permissions and more. These are straightforward to use from a CLI like gcloud, which will help simplify developing and deploying Google Workspace Add-ons built via Alternate Runtimes. For documentation on how to use the new Add-ons Cloud API, refer back to the Quickstart: Create an add-on in a different coding language example.

Showcase: Alternate Runtimes in Action

While Alternate Runtimes for Google Workspace Add-ons is officially generally available as of today, a number of Google Cloud partner teams have already been working with the technology via our early adopter program. One of those Google Cloud partners, Zzapps based out of the Netherlands, has already been creating solutions using Alternate Runtimes in their work building Add-ons for customers.

We asked Riël Notermans, owner of Zzapps (and Google Developer Expert), whose teams have been developing on Google Workspace for over a decade, to share his team’s key takeaways on Alternate Runtimes. He offered not only his insights, but added a few screenshots of one of their recent projects to illustrate as well. In Riël’s own words: “Now that we can use Alternate Runtimes for Add-ons, it changes how we approach projects from start to finish. Prototyping with GSAO makes it possible for us to quickly draft an add-on’s functionality, creating trust and clearness about what we will deliver. Alternate Runtimes makes it possible to tap into our existing applications with almost no effort. We only need to create a JSON response to push a card to interact with add-ons. Our developers are able to work in their own environment, keeping our own tools and development flow. Here’s an example below using a Node.js Express server project that we used to set email signatures, adding a few routes for the card but using our existing logic. The add-on is used to control the functionality.”

Routing Add-on requests to existing logic

“Being able to update your deployment for local development for live testing, without having to create new versions constantly, drastically improves the development experience.”

Introduces advantage of instant testing of add-ons

“Because the Add-on runtimes has built-in authorization and tokens, it is really easy to safely interact with the users data without building complex backend authentication.”


Maximizing use of existing UI with Add-ons

“In the end, we still offer our users solutions for a great experience with a Google Workspace Add-on, while our developers get to use the tools and processes that make them more productive, capable and accomplished”

Creating Add-ons with Alternate Runtimes allows flexible, fast UI design

For More Information

If you want to learn more about using Alternate Runtimes for building Google Workspace Add-ons, here are some essential links for Google Workspace Add-on resources to get you started:

Google People API now supports batch mutates and searches of Contacts

Posted by Ting Huang, Software Engineer

Some time ago, we announced that the Google Contacts API was being deprecated in favor of the People API, and it is scheduled for sunset on June 15, 2021. To aid in the process of migrating from Contacts API, we are pleased to announce that we have added two sets of new endpoints for working with contacts via the People API.

First, we now have new write endpoints that allow developers to create, delete, and update multiple contacts at once. In addition, we also have new read endpoints that allow developers to search a user’s contacts using a prefix query. Both will greatly improve working with the People API, so let’s take a quick look at how you can leverage these new endpoints today.

Getting Started with the People API

Applications need to be authorized to access the API, so to get started you will need to create a project on the Google Developers Console with the People API enabled to get access to the service. If you are new to the Google APIs, you can follow the steps here to begin accessing People API.

Google profile image

Working with Batch Mutate Endpoints

Once you’re authorized, you can simply create new contacts like this (using the Google APIs Client Library for Java):

Person person = new Person();
person.setNames(ImmutableList.of(new
Name().setGivenName("John").setFamilyName("Doe")));
ContactToCreate contactToCreate = new ContactToCreate();
contactToCreate.setContactPerson(person);

BatchCreateContactsRequest request = new BatchCreateContactsRequest();
request.setContacts(ImmutableList.of(contactToCreate)).setReadMask("names");

BatchCreateContactsResponse response =
peopleService.people().batchCreateContacts(request).execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts. Full documentation on the people.batchCreateContacts method is available here.

Similarly, you can update existing contacts like this:

String resourceName = "people/c12345"; // existing contact resource name
Person contactToUpdate =
peopleService
.people()
.get(resourceName)
.setPersonFields("names,emailAddresses")
.execute();
contactToUpdate.setNames(
ImmutableList.of(new Name().setGivenName("John").setFamilyName("Doe")));

BatchUpdateContactsRequest request = new BatchUpdateContactsRequest();
ImmutableMap<String, Person> map =
ImmutableMap.of(contactToUpdate.getResourceName(), contactToUpdate);
request.setContacts(map).setUpdateMask("names")
.setReadMask("names,emailAddresses");

BatchUpdateContactsResponse response =
peopleService.people().batchUpdateContacts(request).execute();

Full documentation on the people.batchUpdateContacts method is available here.

Working with Search Endpoints

You can search through the authenticated user’s contacts like this:

SearchResponse response = peopleService.people().searchContacts()
.setQuery("query")
.setReadMask("names,emailAddresses")
.execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts or https://www.googleapis.com/auth/contacts.readonly. Full documentation on the people.searchContacts method is available here.

You can also search through the authenticated user’s “other contacts” like this:

SearchResponse response = peopleService.otherContacts().search()
.setQuery("query")
.setReadMask("names,emailAddresses")
.execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts.other.readonly. Full documentation on the otherContacts.search method is available here.

Next Steps

We hope that these newly added features inspire you to create the next generation of cool web and mobile apps that delight your users and those in their circles of influence. To learn more about the People API, check out the official documentation here.

Google People API now supports batch mutates and searches of Contacts

Posted by Ting Huang, Software Engineer

Some time ago, we announced that the Google Contacts API was being deprecated in favor of the People API, and it is scheduled for sunset on June 15, 2021. To aid in the process of migrating from Contacts API, we are pleased to announce that we have added two sets of new endpoints for working with contacts via the People API.

First, we now have new write endpoints that allow developers to create, delete, and update multiple contacts at once. In addition, we also have new read endpoints that allow developers to search a user’s contacts using a prefix query. Both will greatly improve working with the People API, so let’s take a quick look at how you can leverage these new endpoints today.

Getting Started with the People API

Applications need to be authorized to access the API, so to get started you will need to create a project on the Google Developers Console with the People API enabled to get access to the service. If you are new to the Google APIs, you can follow the steps here to begin accessing People API.

Google profile image

Working with Batch Mutate Endpoints

Once you’re authorized, you can simply create new contacts like this (using the Google APIs Client Library for Java):

Person person = new Person();
person.setNames(ImmutableList.of(new
Name().setGivenName("John").setFamilyName("Doe")));
ContactToCreate contactToCreate = new ContactToCreate();
contactToCreate.setContactPerson(person);

BatchCreateContactsRequest request = new BatchCreateContactsRequest();
request.setContacts(ImmutableList.of(contactToCreate)).setReadMask("names");

BatchCreateContactsResponse response =
peopleService.people().batchCreateContacts(request).execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts. Full documentation on the people.batchCreateContacts method is available here.

Similarly, you can update existing contacts like this:

String resourceName = "people/c12345"; // existing contact resource name
Person contactToUpdate =
peopleService
.people()
.get(resourceName)
.setPersonFields("names,emailAddresses")
.execute();
contactToUpdate.setNames(
ImmutableList.of(new Name().setGivenName("John").setFamilyName("Doe")));

BatchUpdateContactsRequest request = new BatchUpdateContactsRequest();
ImmutableMap<String, Person> map =
ImmutableMap.of(contactToUpdate.getResourceName(), contactToUpdate);
request.setContacts(map).setUpdateMask("names")
.setReadMask("names,emailAddresses");

BatchUpdateContactsResponse response =
peopleService.people().batchUpdateContacts(request).execute();

Full documentation on the people.batchUpdateContacts method is available here.

Working with Search Endpoints

You can search through the authenticated user’s contacts like this:

SearchResponse response = peopleService.people().searchContacts()
.setQuery("query")
.setReadMask("names,emailAddresses")
.execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts or https://www.googleapis.com/auth/contacts.readonly. Full documentation on the people.searchContacts method is available here.

You can also search through the authenticated user’s “other contacts” like this:

SearchResponse response = peopleService.otherContacts().search()
.setQuery("query")
.setReadMask("names,emailAddresses")
.execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts.other.readonly. Full documentation on the otherContacts.search method is available here.

Next Steps

We hope that these newly added features inspire you to create the next generation of cool web and mobile apps that delight your users and those in their circles of influence. To learn more about the People API, check out the official documentation here.