New ways to connect your app to the Cloud using Android Studio and Google Cloud Platform

Posted by Manfred Zabarauskas, Product Manager on Google Cloud Platform

Many Android developers like Snapchat or Pulse build and host their app backends on the Google Cloud Platform, and enjoy automatic management, with simple expansion to support millions of users.

To quickly add a Google Cloud Platform backend to your Android app, you can now use a number of built-in features in Android Studio 0.6.1+.

Google App Engine backend module templates

Google App Engine enables you to run your backend applications on Google's infrastructure, without ever requiring you to maintain any servers.

To simplify the process of adding an App Engine backend to your app, Android Studio now provides three App Engine backend module templates which you can add to your app. You can find them under "New → Module" menu:

1. App Engine Java Servlet Module provides a simple App Engine Java backend servlet with minimal boilerplate code,


2. App Engine Java Endpoints Module template leverages Google Cloud Endpoints for your backend, and includes automated object marshalling/unmarshalling, generation of strongly-typed Java client libraries and so on,


3. App Engine Backend with Google Cloud Messaging includes both Google Cloud Endpoints and Google Cloud Messaging integration, which enables additional features like push notifications.

When you choose one of these template types, a new Gradle module with your specified module/package name will be added to your project containing your new App Engine backend. All of the required dependencies/permissions will be automatically set up for you.

You can then run it locally (on http://localhost:8080) by selecting the run configuration with your backend's module name, as shown in the image below.

For more information about these backend templates, including their deployment live to App Engine and code examples which show how to connect your Android app to these backends, see their documentation on GitHub. (Also, the code for these templates lives in the same GitHub repository, so do not hesitate to submit a pull request if you have any suggestions!)

Built-in rich editing support for Google Cloud Endpoints

Once you have added the backend module to your Android application, you can use Google Cloud Endpoints to streamline the communication between your backend and your Android app. Cloud Endpoints automatically generate strongly-typed client libraries from simple Java server-side API annotations, automate Java object marshalling to and from JSON, provide built-in OAuth 2.0 support and so on.

As a concrete example, "App Engine Java Endpoints Module" contains a simple annotated Endpoints API at <backend-name>/src/main/java/<package-name>/MyEndpoint.java file (shown below):

import javax.inject.Named;

@Api(name = "myApi",
     version = "v1",
     namespace = @ApiNamespace(ownerDomain = "<package-name>",
                               ownerName = "<package-name>",
                               packagePath=""))
public class MyEndpoint {
    @ApiMethod(name = "sayHi")
    public MyBean sayHi(@Named("name") String name) {
        MyBean response = new MyBean();
        response.setData("Hi, " + name);
        return response;
    }
}

On deployment, this annotated Endpoints API definition class generates a RESTful API. You can explore this generated API (and even make calls to it) by navigating to Endpoints API explorer as shown in the image below:

Google APIs explorer is available at http://localhost:8080/_ah/api/explorer once you deploy your app. Color overlays in this screenshot match the colors in the API snippet above (MyEndpoint.java).

To simplify calling this generated API from your Android app, Android Studio will automatically set up your project to automatically include all compile dependencies and permissions required to consume Cloud Endpoints, and will re-generate strongly-typed client libraries if your backend changes. This means that you can start calling the client libraries from your Android app immediately after defining the server-side Endpoints API:

Code completion for automatically generated, strongly-typed client libraries. Color overlays match the colors in the API snipped above (MyEndpoint.java)

As server-side Endpoints API definitions have to conform to a number of syntactic rules, Android Studio also includes a number of Endpoints-specific inspections and quick-fixes, which help you to avoid mistakes when writing Endpoints APIs.

For example, "@Named" annotation is required for all non-entity type parameters passed to server-side methods. If you forget to add this annotation when modifying sayHi method in MyEndpoint.java file, Android Studio will underline the problematic statement as-you-type:

Furthermore, to help you easily fix the problems with Cloud Endpoints, Android Studio will provide quick-fixes for the most common Cloud Endpoints development mistakes. To see these quick-fix suggestions, press Alt + Enter if you're running on Linux/Windows or ⌥ + Enter if you're running on Mac:

As expected, choosing the first quick-fix ("Add @Named") will automatically add "@Named" annotation to method's parameter, solving this problem in two key presses.

The underlying work-horses: Gradle, and Gradle plug-in for App Engine

Under the hood, Gradle is used to build both your app and your App Engine backend. In fact, when you add an App Engine backend to your Android app, an open-source App Engine plug-in for Gradle is automatically downloaded by Android Studio, and common App Engine tasks become available as Gradle targets. This allows you to use the same build system across your IDE, command-line or continuous integration environments.

For example, to deploy your backend to App Engine from Android Studio, you can launch the "appengineUpdate" task from the "Gradle tasks" tool window:

Similarly, if you want to integrate your backend's deployment into your command-line scripts, simply launch "./gradlew backend:appengineUpdate" command from your project's root directory.

Try out a codelab, or see these features live at Google I/O 2014!

If you want to give these features a spin in a more guided environment, try out our Cloud Endpoints codelab for Android. We will also be demonstrating some of these features live at Less Code, More Services, Better Android Apps session in Google I/O 2014 (as well as some of the new and even more exciting stuff), so don't forget to tune in!

We look forward to your questions or feedback, and learning about the amazing applications you have built using Android Studio and Google Cloud Platform. You can find us lurking on StackOverflow's App Engine and Cloud Endpoints forums!

Join the discussion on



+Android Developers

FlatBuffers: A Memory-Efficient Serialization Library

By Wouter van Oortmerssen, Fun Propulsion Labs at Google

Game developers, we've just released FlatBuffers, a C++ serialization library that allows you to read data without unpacking or allocating additional memory, as an open source project.

FlatBuffers stores serialized data in buffers in a cross-platform way, supporting format evolution that is fully forwards and backwards compatible through a schema. These buffers can be stored in files or sent across the network as-is, and accessed in-place without parsing overhead.

The FlatBuffers schema compiler and runtime is written in platform independent C++ with no library dependencies outside the STL, which makes it possible to use on any platform that has a C++ compiler. We have provided methods to build the FlatBuffers library, example applications, and unit tests for Android, Linux, OSX and Windows.
The schema compiler can generate code to read and write FlatBuffers binary files for C++ and Java. It can additionally parse JSON-formatted data into type-safe binaries.

Game developers can use this library to store game data with less overhead than alternative solutions (e.g. Protocol Buffers or JSON). We’re excited about the possibilities, and want to hear from you about how we can make this even better!

Download the latest release from the FlatBuffers page in GitHub and join our discussion list!

Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

An Android Wear Design Story

By Roman Nurik and Timothy Jordan, Design and Developer Advocates on Android Wear

A few weeks ago, Timothy and I were chatting about designing apps for wearables to validate some of the content we’re planning for Google I/O 2014¹. We talked a lot about how these devices require scrutiny to preserve user attention while exposing some unique new surface areas for developers. We also discussed user context and how the apps we make should be opportunistic, presenting themselves in contexts where they’re useful; it’s more important than ever to think of apps on wearable devices not as icons on a grid but rather as functional overlays on the operating system itself.

But while I’d designed a number of touch UIs for Android in the past and Timothy had a ton of experience with Glass, neither of us had really gone through the exercise of actually designing an app for Android Wear. So we set out to put our ideas in practice and see what designing for this new platform is like.

Before we got started, we needed an idea. Last year, I participated in an informal Glass design sprint in NYC run by Nadya Direkova, and my sprint team came up with a walking tour app. The idea was you’d choose from a set of nearby tours, walk between the stops, and at each stop on the tour, learn about the destination.

My rough mocks of a walking tour app from a Glass design sprint.

While the design sprint ended at rough mocks, the idea stuck around in my mind, and came up again during this exercise. It seemed like a perfect example of a contextually aware app that could enhance your Android Wear experience.

Designing a walking tour app for Android Wear

We started fleshing out the idea by thinking through the app’s entry points: how will users “launch” this app? While exposing a “start XYZ walking tours app” voice command is pretty standard, it’d be interesting to also suggest nearby walking tours as you go about your day by presenting notifications in the user’s context stream. These notifications would be “low priority,” so you’d only see them after addressing the more important stuff like text messages from friends. And with today’s geofencing and location functionality in Google Play services, this type of contextual awareness is possible in a battery-friendly way.

At this point we were pretty excited and decided to begin mocking up the UI. Rather than starting from scratch, we used Taylor Ling’s excellent Android Wear 0.1 design template as a baseline, which includes templates for both square and round devices. We started with square since we were most familiar with rectangle UI design:

Idea: You get a notification in the context stream when a walking tour is available nearby.

I’ve got to admit, it was pretty thrilling designing in such a constrained environment. 140x140 dp (280x280 px @ XHDPI) isn’t a lot of space to work with, so you need to make some tough choices about when and how to present information. But these are exactly the types of problems that make design really, really fun. You end up spending more time thinking and less time actually pushing pixels around in Photoshop or Sketch.

We pretty quickly fleshed out the rest of the app for square devices. They included just a handful of additional screens: a dynamic notification showing the distance to your next stop, and a 4-page detail screen when you arrive at the tour stop, where you can spend a few moments reading about where you’re standing.

A notification guiding you to your next stop, and a multi-page stop detail screen for learning about the stop when you get there.

Seeing our design in real life

Here’s the thing—there’s only so much you can do in Photoshop. To truly understand a platform as a designer, you really need to use (and ideally live with) a real device, and see your work on that device. Only then can you fully evaluate the complexity of your flows, the size of your touch targets, or the legibility of your text.

Luckily, Timothy and I both had test devices—I sported an LG G Watch prototype and Timothy carried a Moto 360 prototype. We then needed a way to quickly send screens to our devices so we could iterate on the design. A few years ago I’d published the Android Design Preview tool that lets you mirror a part of your screen to a connected Android device. Much to our delight, the tool worked great with Android Wear! After seeing our mocks show up on my LG G Watch, we made a few small tweaks and felt much more confident that the overall idea “felt right” on the wrist.

Android Design Preview mirrors a part of your computer screen to an Android device. It’s especially awesome seeing your UI running on an LG G Watch prototype.

Designing for round devices

We’d never designed round UIs before, so we weren’t sure what this new adventure would be like. Quite frankly, it ended up being unbelievably easy: tweaking all 8 of our screen mocks for round took under an hour. When you’re only showing the most important 2 or 3 pieces of information on screen at a time, that’s only 2 or 3 pieces of information you need to optimize for round devices. All in all, there were only a few types of minor tweaks we made:

• Scaled up backgrounds to 160x160 dp (320x320 px @ XHDPI)


• Bumped up content margins from 12dp on square to 26dp on round; this means content was 116x116 dp on square and only a little smaller at 108x108 dp on round


• Pushed down circular actions like “Continue tour” to better vertically center with the watch frame


• Center-aligned certain short snippets of text on round devices as opposed to left-aligning on square


• Dropped the side padding for context stream cards (the platform automatically does this for notifications, so there isn’t any actual work to do here)

These weren’t completely different layouts—rather, the same layout with slightly tweaked metrics.

It’s hard to articulate the excitement we felt when we mirrored the mocks to Timothy’s Moto 360 prototype with Android Design Preview. To put it lightly, our minds were blown.

There’s something special and awe-inspiring about seeing one of your UIs running on a round screen..

And that was it—with round and square mocks complete, and mirrored on our devices, we’d gotten our first glimpse at designing apps for this exciting new platform. Below are our completed mocks for the tour discovery and engagement flows, not a grid of app icons in sight. You can download the full PSDs here.

An eye-opening experience

Designing for Android Wear is pretty different from designing for the desktop, phones or tablets. Just like with Glass, you really need to think carefully about the information and actions you present to the user, and even more so about the contexts in which your app will come to the surface.

As a designer, that’s the fun part—working with constraints involving scarce resources like device size and user attention means it’s more important than ever to think deeply about your ideas and iterate on them early and often. The actual pixel-pushing part of the process is far, far easier.

So there we were, putting our ideas into practice, on real actual device prototypes that we could’ve only dreamed about only a few years ago. It was the most fun I’ve had designing UIs in a long time. Remember that feeling when you first dreamed up an app, mocked or even coded it up, and ran it on your Android phone? It was that same feeling all over again, but amplified, because you were actually wearing your app. I can’t wait for you all to experience it!

¹ Have we mentioned #io14 will have tons of great content around both design and wearable computing? Make sure to tune in June 25th and 26th!

Join the discussion on



+Android Developers

New Demographic Stats in Google Play Games Services

By Ben Frenkel, Google Play Games team

Hey game developers, back in March you may remember we added new game statistics in the Google Play Developer Console for those of you who had implemented Google Play Games: our cross-platform game services for Android, iOS and the web.

Starting today, we're providing more insights into how your games are being used by adding country, age, and gender dimensions to the existing set of reports available in the Developer console. You’ll see demographics integrated into Overview stats as well as the Players reports for New and Active users.

In the Overview stats you can now see highlights of activity by age group, most active countries, and gender.

With a better understanding of your users’ demographic composition, you'll be able to make more effective decisions to improve retention and monetization. Here a few ways you could imagine using these new stats:

• You just launched your new game globally, and expected it do particularly well in Germany. Using country demographic data, you see that Germany is much less active than expected. After some digging, you realize that your tutorial was not properly translated to German. Based on this insight, you immediately roll out a fix to see if you can improve active users in Germany.

In the Players stats section the new metrics reveal trends in how your app is doing across age groups, countries, and gender.

• After Looking at your new demographics report you realize that your game is really popular with women in their mid-20s. Your in-app purchase data corroborates this, showing that the one female hero character is the most popular purchase. Empowered by this data, you race to add female hero characters to your game.

Additionally, if you're already using Google Play game services, there's no extra integration needed! By logging in to the Google Play Developer Console you can start using demographics to better inform your decisions today.

Join the discussion on



+Android Developers