Google I/O 2012 – Building Android Applications that Use Web APIs with Yaniv Inbar and Sriram Saroop


YANIV INBAR: So how do you
like your new Nexus 7? [APPLAUSE] YANIV INBAR: All right, so
hopefully now that you got a Nexus 7 to develop against and
you’re ready to build Android applications using
your Nexus 7. And hopefully, your next step,
once you’ve got an Android application, is to design
it to work with the web. And we’ll talk about everything
you need to know to be able to accomplish that both
working with Google’s Web APIs as well as being able to
take advantage of Google’s Cloud platform, the Google App
Engine, to backend your Android data on the Cloud. So let me introduce ourselves. My name is Yaniv Inbar. I’ve worked at Google for about
five and 1/2 years. I’m a senior software
engineer. I’m the tech lead of the team
that develops open source client libraries for
Google APIs. And I’m the lead developer of
the Android client library. SRIRAM SAROOP: Hey, guys. I’m Sriram. I’m the product manager in
the Cloud platform team. So here I’ll be talking about
Cloud Endpoints, how you can use App Engine to build great
mobile backends for your Android applications. YANIV INBAR: So I’m
really excited. Because we’re going to the
previewing some new technology. So stay tuned just a moment. And I’ll start by talking
about Google’s Web APIs. So about two years ago, I
demoed, we talked about how at Google we built this whole new
API infrastructure that was supposed to run all of
Google’s new APIs. And I’m really excited that
by today I think we have something like over
30 Google APIs. That includes Google+ and
a variety of others. So I’ll talk a little
about some of the ones that are available. But the good news is that
we’ve been able to take advantage of the same API
infrastructure and allow you to build your own backend for
your Android application on Google App Engine. So any API that you build on App
Engine will work exactly the same way. And as I said, Sriram will
talk more about that. So stay tuned for that. But the goal of this session is
to allow you to be able to build your Android
application. First of all, to take advantage
of Google’s Web APIs, so this is a sample of
some of the APIs that are available to you to use. Google+ is an example. You can get profile information
about the user, their name, the email address,
of course, with their permission, maybe a list of the
activities that they’ve done Google+. Google Calendar, you’re probably
very familiar with that web application. There’s a very similar
API interface to it. They’re often JSON formatted. And it’s very easy
to work with. Google Drive just launched
recently. That’s pretty exciting. You can upload and download
documents. YouTube just announced today
their new API based on this API infrastructure. So I think this is pretty
exciting for us. So about a year ago, I presented
a session at Google I/O talking about best practices
of working with Google’s Web APIs and announced
the beta release of the Java client library. So I’m very happy. A lot of developments
have gone through. We’ve added a lot more
useful features. And one of the things that
surprised me is that a lot of you developers were using it,
not just to access Google’s Web APIs, but really
API on the web. And that actually
was my dream. I was hoping that you’d be able
to take advantage of the same HTTP infrastructure, OAuth,
these are all common web standards that any API on
the web that implements it, say Twitter API, for example,
you should be able to use this same library. So what we’ve done was actually split into three projects. The first project is
the HTTP library. It implements the RFCs
of HTTP be able to access any resource. And it really goes beyond just
your basic HTTP library. It does exponential back
off, a variety of other great features. And on top of that we built
the OAuth library. That adds an OAuth 2.0 as well
OAuth 1.0 implementation on top of the HTTP library, again,
work with any web service that implements
the specification. And finally, there’s the
Google API libraries. This is useful for working
with Google libraries. So let’s talk about some of
the features in there. The HTTP library supports any
Java 5 language platform such as Android as well as
Google App Engine. We support the JSON wire format,
the XML wire format, protocol buffers even. As I mentioned, the OAuth
project, that adds OAuth 2.0 as well as OAuth 1.0
implementation on top of it. It makes it very easy to work
within OAuth service. And there’s the Base Library
that all the Google API libraries share. It implements sophisticated
functionality, such as batching HTTP requests into a
single HTTP request, media upload, media download. I won’t be demonstrating
that today. But there’s lots of great
documentation about how to do that. How to process errors from the
Google API servers, how do reduce the size of JSON, I’ll
show you an example of that in a moment. And then the server specific
libraries so you’re working with Calendar, Google+. They make it incredibly
easy to use. They’re very simple methods. And I’ll show you in just a
minute what it looks like. And I’m pretty happy with
how well that’s evolved. We have an automated
infrastructure. Every time a new API gets
released, say the YouTube API announced this morning, we
simply rearm the generator. And we publish new libraries. And I’ll show you exactly
where to get them. So there’s some references
for you. The Google APIs is Getting
Started webinar, we just published on YouTube. It’s about 30 minutes long. It talks about all the great
tools that are available, not necessarily specific the Java
library but the API’s Council, the API’s Explorer, really
great convenient tools. And then if you’re a more
advanced developer and you’re trying to get the most efficient
Android application possible, you want to advantage
of batching requests or partial response, partial
update, this is a really great resource. There was a Google
I/O session. And you’re welcome
to check it out. So let’s talk about OAuth 2.0. And it has just recently
been finalized. I mean all the Google APIs
support OAuth 2.0 for access of protected resources. So it’s really important
to understand. And this is really the blocker a
lot of times when developers tell us, I’m getting blocked. It’s usually related
to authorization. So let me step you through
a typical OAuth 2.0 flow. That’s a picturE OF me. It’s a little old. But that’s me using an
Android application. So I really want to get value
out of the OAuth application. Now, we don’t want just any
application grabbing your protected resource from
the Google servers. We want to make sure there’s
a very strong and secure permissions model. So the Android application, what
it does conceptually is it goes to Google Authorization
server and says, hey, I want to be able
to access data on behalf of the user. So the Authorization server
says, well, I’m not sure. Let me ask the user, is it OK
to grant permission for this application? And presumably I say,
yes, of course. I’m I trust this developer. I trust this Android
application. So I say yes to the
Auth server. The Auth server returns
back an access token. So this access token is much
like a key that has access to data that’s locked in
Google servers. With that access token, every
time you make an HTTP request to the Google Web API servers,
you include an access token. This is in the form of an
authorization header where you simply say authorization
colon bearer and then the access token. And then the Google API server
has to ask the Authorization server, is it OK? Is this access token valid? Has it expired and since they
often expire after an hour for the most secure application? And assuming that that’s OK,
it’ll go back to the Android application with the data
that I requested. Hopefully, that made sense. I’ll drill down a little
bit into the permission model on OAuth. Every Google API publishes
a set of scopes of working with that API. Kill Calendar has two of them,
one for read-only access and one for editing, updating, or
creating new calendars. This is what it looks like. And I’ll mention, too, a great
reference for OAuth 2.0. The first is a Google I/O
session by Ryan Boyd. He literally wrote a book
about the subject. So he can give you a great
overview of OAuth 2.0. And as well as our general
documentation, there’s a bunch of different flows on there
if you’re interested. Now, why don’t you see more
applications on the web on Android using OAuth 2.0? And when I talk to a lot of
developers, I get a very common complaint. It’s complicated. Yes. So there’s a number of reasons
why it’s complicated. And part of it is we just
haven’t done a good job of getting the message out
how to do it properly. But there’s another
good reason. And I’ll show you the next
screen of what the current authorization screen
looks like. Now, if you Ice Cream Sandwich
or a later device that represents about I think about
7% of the market Android devices, it looked better. But on Froyo and most of the
devices on the web, you’ll see an Android. It will look like this. And I don’t know if
you can see this. But is this a readable
permission? Would you be able to explain
it to a loved one what this means and exactly what
permission you’re granting in this application? I’m not sure. So I’ll show you the next slide
of what’s launching really soon and probably
in the order of a couple of weeks. I’m really excited about this. It’s been a long journey
to get to this point. And we’re almost there. So I want to see some applause
if you like it. [APPLAUSE] YANIV INBAR: Oh, good. Yes. So I’m really excited about this
and, like I said, in just a couple of weeks. Now, what I’m showing is what
it looks like in Froyo. Of course, it will look
a lot better on one of these Nexus 7’s. But already on Froyo,
it looks very nice. I think it’s pretty clear. It says it’s going to manage
your calendars. Great, I know what to do. I’m going to click Allow. I’m going to trust my app
a little bit better now. And this is going to come with
Google Play services. And if you use Google Play
service, it comes with a really handy tool called
AccountPicker. It’s just a little UI that shows
you all the accounts that are on the device. Yes, you’ll select which one
you want, add an account if you want to use a
different one. It’s just super handy. I find it really convenient. So some of the details, Google
Play services is actually an essential component
of Google Play. But they’re built in a way
that allows all you developers to use it. So this is really great the
way that they’ve built it. That means that it’s going to
be an all users’ devices all the way down Froyo. I think that represents
somewhere around 94% of the market of Android devices. So you can be sure that you
can be able to use it. The permission is a
lot more readable. You get AccountPicker. And the nicest thing about
it is it’s more secure. It actually uses the signature,
the way that you signed your application, it is
able to use that and is able to use that signature with the
Google Authorization server. So you never have to specify
an API key, which is really easy to steal. And you can be sure that your
application is the only one that’s going to be able to
have access to that data. It also does token caching. So these tokens expire
within the hour. And it takes care of refreshing
them for you. You just basically don’t have
to deal with expired tokens. It’s really handy. It’s really great. The documentation is live. But we’re not yet providing
you the ability to build applications in it yet. This will come in a couple
weeks hopefully. But I’m supposed to tell
you it’s coming soon. We’ll see, hopefully
very shortly. So we’re done with slides. Now we’re just going to show
you how to build an application, all the tools that
you’re going to need. I’m going to demo for you some
applications, some pretty simple ones. And I’ll show you the
code behind it. I’ll show you also a
few of the tools. So let’s start with the tools. The first, as I promised, that
I will show you where you can grab the Java library so this
is the open source project. And I’m just going to click
on Libraries and Samples. I’m interested in a
Google Calendar. So I’m going to click
on a calendar API. And there’s a couple things here
that are pretty useful. You can download the library. It has the jars that you need,
sources, documentation, a link to the Java.doc, Calendar API
Documentation, Developer’s Guide, and a couple other useful
things as well as I’m going to highlight Calendar
Preview Android Sample. This is the source code to the
sample I’m going to show you. It uses Google Play services. You won’t be able
to run it yet. Because we haven’t made
it available yet. But I will show you here
just because you’re attending my session. I’ll give you a sneak peek
at what it looks like with real code. And now I’m going to go to
the API’s Explorer, a pretty handy tool. It lists all the APIs that
are in Google’s API infrastructure. Here I’m going to look
at the list method. I’m going to first sign
in using OAuth 2.0. Here are the scopes. I mentioned that earlier. I’m just going to accept
all the scopes. And I’m going to execute it. Where is the Execute button? Great. So this gives you a really
concrete sense of what’s actually going on
under the hood. Here’s that authorization header
I mentioned earlier. And here’s the JSON response. I know, Sriram. This is not very readable. SRIRAM SAROOP: Sorry, Yan. YANIV INBAR: Can I make it
a little bit smaller? What do you think? SRIRAM SAROOP: [INAUDIBLE] attributes. YANIV INBAR: Let’s use
the fields editor. I’m only interested in the ID of
the calendar and a summary of the calendar. That’s just the title. Let’s take a look. Whoops, what just
happened here? Let’s try that again. Click Execute again. I think I forgot to
click Execute. There you go. It’s a lot more readable. But more importantly, it
also reduces the size of your HTTP response. So it is a lot more efficient. So you’re welcome to
play with this. This is a great tool. The next thing I’m going to do
is I’m going to go to the API’s council. I’m going to start from scratch
here, one second. OK, create a new project. This allows you to register your
Android application with its signature. The first thing I have to do,
and please don’t forget this step, is you have to
enable the API that you’re interested in. There we go. I enabled Google Calendar. It may ask you to sign the terms
of service is usually pretty standard. Create a client ID. I’ll give it a name,
My Android App. This is an Android
application. Now, you have to give
it two things. The first is the package name. I’ll grab that from over here,
the manifest file. There we go. And the second is the
SHA1 certificate. You can read the documentation
about where to get it. Here I’m using the one that
comes with Android. And here’s the command. The password is android,
really secure. Don’t tell anybody. Great. Let’s create the client ID. And I’m going to cheat here. Because I’ve already
registered it. So I’m going to give
it a new name. And there you go. So I wanted to show
you this because this is really important. This is where you get
your client ID from. You’re not going to need it for
the Android sample also. But you’ll need it for
Sriram’s sample. I’ve got the redirect
here I can ignore. And the rest is the package
name and the fingerprint. Now, again, I won’t go into the
details about what this means exactly. But I just wanted to show
you how it works once. In this case, I was using
the debug certificate. If you’re doing a release built,
you want to use your release certificate as well. So you want to register that. Great. So now let’s do a demo before
I go into the code. Let’s switch to– now, the wifi’s been giving
me some issues. So I got it hooked up through
the ethernet. Hopefully, that will
work better. First, I’m going to select
the account. Here’s that AccountPicker
I was talking about. I’m going to use this account. It’s going to go to the
Google Auth server. And the Auth array is going to
say, hey, you know what? This person hasn’t given
permission to the app yet. So let’s give it permission. Here’s that screen I
showed you earlier. I’m going to click on that. Go ahead and applause
if you want to. [APPLAUSE] YANIV INBAR: All right. Now, you know what? Can you put on that screen,
can you show, can you put my laptop? SRIRAM SAROOP: Sure. YANIV INBAR: I’m going to sign
into Google Calendar on my laptop just to show you
that I’m not cheating. This is the real Google
Calendar. There you go. Standard web interface and I’m
going to add a new calendar. Let’s call it Google. And by the way, HTTP requests
can take a long time. There we go. And it’s showing up on here? Yes. It’s over there. Why don’t we make
a copy of that? In fact, I’m going to
use batch here. I’m going to make three copies
of that calendar. And that’s running in
the background. There we go. OK. Let’s see if I’ve just created
a whole lot of calendars. Oh, not yet. I’m not sure why that’s
not showing up yet. Let’s delete this calendar. Why not? Let’s edit this calendar. Let’s give it another name. And everything is happening
in the background all asynchronously. OK. And I’m not sure why that’s
not showing up yet. But that’s all right. Cool, so that pretty simple
application, just making requests, inserting calendars,
deleting calendars. Let me show you the code. Now, I’m going to assume you’re
a fairly experienced Android programmer. You’re familiar with the
activities and how they work. So I’ll highlight sort of the
things that I think are most interesting. The first is I made a
calendar info class. In this case, I’ve
oversimplified a little bit. I’m just storing the title
of the calendar. Obviously, you’ll want a more
sophisticated model. It’s a plain old Java object. It’s got an ID and a summary. A summary is just the title
of the calendar. And I’ve got a calendar
model class. Here I’ve got a map from the
ID of the calendar to the calendar information and some
standard add, remove, and get methods on it. So here is the activity class. Oh, let’s project. Here we go. So this is the uncreate
method. The first thing I’m going to
highlight here is logging. This is a really handy
debugging tool. It shows you the content of
every HTTP request and HTTP response that you make, and
including the JSON content, all the HTTP headers. It’s a really handy tool. The second thing I’m going to
highlight here is Google Account Credential
using OAuth 2.0. I’ll go into that code
in just a second. But I wanted to highlight
the calendar scopes of that calendar. That’s that manager
calendar scope. This is as easy as it is. If you want to store the account
name, this is the currently selected account. It’s a good thing to store in
your shared preferences. This is the Calendar
Client Object. You pass it the HP transport
and the JSON factor. You know want these are? Since Library has a completely
plugable HTTP transport, you can use HTTP URL connection. You can use Apache HTTPclient. There’s lots of great
information about which one to use at which Android
SDK level. And also for the JSON
library, that’s completely plugable as well. If you want to use
Jackson or JSON. Or on Honeycomb there’s
actually a built-in JSON parser. So you can use that as well. And finally, a pass at the
OAuth 2.0 credential– Now let’s go to Google
Account Credential. This is where it gets
more interesting. The first method that’s
interesting is using OAuth 2.0. Now in this case, you pass
an array of scopes. Maybe you get a scope for both
Calendar and Blogger. So this access token that you
have enables access to both of those APIs. The other use case is
using Audience. And Sriram is going to explain
to you what that’s about. That’s when using Google
Cloud Endpoints. The next thing here that’s
interesting is the Initializer. Every time I make a request,
I want to use exponential back off. It’s a one liner to add that. The next thing is, this
is my favorite. It shows you how to use
the AccountPicker. You just pass it mostly nulls
parameters to it. And you get a very good
default behavior. It is the one that shows the
screen that allows you to select which account you want. And it gives you
back an intent. You just start that intent. It comes back with
the access token. That’s pretty much all you
need to know when you’re programming it. That’s how easy that is. Next, getting a token, Google
Auth Util as well as AccountPicker, again,
that counts as part of Google Play services. With a get token method, it just
returns a string based on the scopes that you give it. What’s interesting about
this method is how we handle errors. One type of error is Transient
Auth exception. That just means there is a
connection problem or it can’t the server for whatever
reason. The best strategy for that is to
retry the request and using an exponential back off policy,
as I’ve done here, just to make sure not to
overload the server, fairly straightforward. You just copy this code. It will work. Any other kind of Auth exception
I’m just going to wrap in the I/O exception. They handle it somewhere else. I’ll show you that
in a minute. The next one is the actual
request initializer. This gives it the bearer token
for the authorization header. I mentioned that earlier. And the second thing it does is,
if I get a 401 HTTP error code, this is the standard way
of saying your access token has expire. It’s no longer valid for
whatever reason. So what we have to do, we have
to tell Google Play services to remove it from its cache so
that next time you make a request, and this is just going
to automatically retry it, it’s going to get a new
access token from the server. That’s all there is to it. Now, there’s a lot
of code in here. Hopefully, I can get this into
a form of a Java library. You can just use Google Account
Credential directly. That’s something we can
maybe do in the future based on your feedback. I’m going to show
you ASIG task. Now, if you’re an experienced
programmer, you probably are familiar with ASIG task. Any long running operation, you
definitely want to run in a background thread. You never want to run
that in UI thread. So that’s what I’m using here. This does some standard progress
bar stuff but do in background. This is my abstract class
that all my ASIG task classes extend. So you do the HTTP request
in the background. And then you catch User
Recoverable Auth exception. That’s what tells you, hey,
you need to show the permission screen, that really
nice permission screen that I think most of you liked. So it’s two lines of code. You get the intent from that. And you start activity
for result. Good. So let’s show you an example of getting, let’s load Calendars. This is how easy the
Google Library is. And I’ve gotten feedback
about this. This is just too easy. It should be more than
a line of code. So yeah, this is the Library. You just call calendar.calenda
rlist.list.execute. The one thing that I’ve done
here is I actually gave it a partial syntax saying I only
want the ID and the summary. It’s exactly what I did in
API’s Explorer, a good practice in general. It gives you a plain old Java
object Calendar list. You get the items. And you update your model
as simple as that. Now, let me show how simple
batching is with the Library. In this case, you have to create
a batch request object that just stores a collection
of requests to make, which, when you execute, will then
execute all those requests. You have to register a callback method for each request. In this case, I’m inserting
Calendars. The on success method just
updates my model. On failure will show an error. Let’s see. What else is interesting here
is ProGuard configuration. So I wanted to show you, I get
a lot of feedback, hey, this is all great. But it’s a really big library. And oftentimes, when you’re
debugging, it will look like a four-megabyte application. Well, the trick is
to use ProGuard. And this is really important. So I want to show you how large
the application is if you’re using ProGuard. So let me go into
settings, apps. I don’t know if you
can see this. But it says here
332 kilobytes. This is a much smaller
library. So the reason is ProGuard
basically strips out everything you don’t use. It’s absolutely essential if
you’re going to release a real application on the market. You’ll want to do that. You’ll want to minimize the
amount of space you take up on the user’s Android device. Great. And it’s as easy as using the
ProGuard configuration that Eclipse gives you. There’s a properties
file here. You just uncomment the
ProGuard config line. And you want to use– And there’s a couple of things
that you add to the Pro Guard configuration file. And I’ll give you in
the documentation. All right, so let’s get
back to the slides. And I’m going to let Sriram
tell us all about Google Cloud Endpoints. SRIRAM SAROOP: Awesome. That’s a lot of content. You guys want a break? Just kidding. All right, let’s talk about
Google Cloud Endpoints. So show of hands, how many
of you are app engine developers out there? All right, around 10
person, not many. How many of you are Android
developers who have used a mobile backend of some sort. All right, that’s a fair
amount of you. So my aim at the end of this
talk is to ask all of you or rather to get all of you to sign
up for the Trusted Tester program for Google
Cloud Endpoints. So let me quickly show you
how I’m going to do that. So what is Google Cloud
Endpoints all about? So Google Cloud Endpoints is the
ability to easily develop code on a mobile backend, that’s
App Engine, and consume it across multiple platforms,
Android being one of them. You can consume it from
an iOS platform. You can also consume it from
any browser out there. So what is so cool
about App Engine? App Engine automatically
scales according to the incoming load. So you don’t have to worry about
provisioning servers. You don’t have to worry about
configuring them, keeping them updated with patches. And where does App Engine
store all its data? It’s got a variety of options. It’s got a NoSQL, highly
scalable data store, which you can use to store your data. If you’re not a NoSQL junkie,
if you’re a SQL junkie, you can also use Cloud SQL. So the App Engine app that you
write your backend in can make use of the same Web APIs
that Yaniv just showed. And all the functionality in
your backend can be exposed using a simple REST interface,
which we call as Endpoints, and can be consumed using the
same Java client library that’s used to consume
Google APIs. So that means that you
essentially get to develop APIs on Google API
infrastructure that powers your Google+ API, Gmail API,
and all that stuff. And along with that, you get all
the good functionalities, tooling, the API Explorer to
explore your own APIs. And you also have available
Google plug-ins for Eclipse support for actually producing
these APIs and consuming these APIs. So in fact, Google plug-in for
Eclipse version 3.0 with support for Cloud Endpoints
has been released today. So I guess you guys should go
ahead and download that. All right, so you might have
attended a talk on Google Cloud Messaging for Android. So it’s come out of preview. And I’m happy to announce that
Cloud Endpoints also has pretty good support for
Cloud Messaging. So essentially what you want to
do here, you want to store state in the Cloud. So if you want to store state in
the Cloud, you also want to get it synchronized across
multiple devices. And how do go about
doing this? There are couple of ways
in which you can go about doing this. One obvious way is to kind of
implement some kind of a polling logic in which
you poll the server every now and then. But that’s going to suck
out your battery. It’s going to be really bad
for as far as your network bandwidth is concerned. So what is the solution here? So Google Cloud Messaging
works well with Cloud Endpoints in that, when you
define an Endpoint which modifies the state of your data,
you can use Google Cloud Messaging to send a ping back
to all registered devices so that the required devices
actually get the data back. So this really works well for
a case where you want to synchronize data across
multiple devices. So I’ll be showing a cool demo
which demonstrates this. All right, so the use cases that
we spoke about was that you can use App Engine to
centrally write your business logic, perform some kind of
computation in case you’re writing a chess game. Suppose you want to compute the
next best possible move. That can be done
on App Engine. If you want to store the state
of your chessboard, you can do that using the data store. And you can synchronize state
across multiple devices using a combination of Endpoints in
Google Cloud Messaging. Right. So I want you to do this. Go sign up on endpoints-truste
d-tester.appspot.com. So it’s a trusted
tester program. It’s possibly got some
rough edges. So we really want your
feedback here. So give it a shot. All right, so time to get our
hands dirty with a demo. So what am I going
to show you? I’m going to show you a
simple application. If you’d remember this UI, this
is similar to the UI that Yaniv just showed you for
his Calendar app. So it’s called Cloud Notes,
the ability to store your notes in the Cloud and carry
it on your various devices that you have. So the UI is really simple. It’s got an add note
functionality. So here I can say, what
did I want to do? I want to build a rocket. How about that? So what’s happening now is the
build a rocket note is actually being sent over
on the wire in JSON format to App Engine. And it’s securely stored
in the Cloud for you. Right, so that’s cool. Let’s just write another note
to make things more interesting. Let’s take it to the moon. And what do we do there? Let’s go build maps
for the moon. We are Google here so we
build maps everywhere. So just to make sure that I’m
not storing it anywhere else, App Engine provides a cool
interface for administration that’s available both locally as
well as on your App Engine remote Endpoint. So here I’m actually using a
local development server that’s like a local version
of App Engine running for your testing. So I’m going to show you the
data that’s actually stored in the Cloud. So you see an entity kind
here with just Note. I’m using the NoSQL
data store. I’m storing my notes
in a note object. So if I do a list entities over
there, we should be able to see that the two notes that
I built, build a rocket and take it to the moon,
are right there. And they’re automatically tied
to my email address, which means that I’ve already
authenticated using the same OAuth stuff that Yaniv
just showed you. Right? So storing stuff on your Cloud
and getting it from one device is fine. But it’s not cool enough. What do you think? YANIV INBAR: You know what I
think would be really cool? SRIRAM SAROOP: Yeah? YANIV INBAR: If you could
show two devices. SRIRAM SAROOP: Awesome. Let’s do that. So how about that? Let’s take another device. OK, so the other device
automatically has the state. I didn’t have to do anything. So let’s give another demo. So OK, you go to the moon. Let’s go and hang out in the
moon, not literally, actually using Google Hangout. YANIV INBAR: Sergi’s
next project. SRIRAM SAROOP: So once I click
on Save, what should happen is that this note should go
to App Engine, right? And App Engine will use Google
Cloud Messaging to actually ping all devices which
are registered for this particular user. The user is [email protected]
that you saw. So hand in my mouth I’m
going to try this. Let’s hit on Save. How about that? YANIV INBAR: Yeah. [APPLAUSE] SRIRAM SAROOP: Great. Now let’s do a couple of
other things, right? How about an edit? Is that going to still work? Let’s not build maps. Let’s build glasses. OK, I’m going to delete
the whole thing. YANIV INBAR: Perfect. Let’s see it. SRIRAM SAROOP: OK, the
emulator is not very responsive. OK, let’s give it
one more shot. Let’s click on Edit. All right. YANIV INBAR: Just click Save. SRIRAM SAROOP: Let’s
build glasses. OK, what’s going
to happen now? All right, there you go. [APPLAUSE] SRIRAM SAROOP: All right, so
this is an example of an application that shows you how
to use Google Cloud Endpoint and get automatic states
synchronization using Google Cloud Messaging. So I’m going to be a little
adventurous now. And I’m actually going to show
you how to build this application from scratch. So let’s go about doing that. And I’m a product manager. If I can build this application,
I’m sure all of you engineers can do that. So I’m going to start
with building a simple Android project. YANIV INBAR: Where did
you get this tool? SRIRAM SAROOP: Oh, right. Where did I get this tool? So a couple of things you need
to note here so the first thing is that I’ve installed a
Google plug-in for Eclipse, which is a simple utility to
easily help you develop using App Engine. You can do a one click
deploy to App Engine. The font might be a
little small for the guys in the back. So I’ll show that to
you in a minute. So I’ve essentially installed
Google plug-in for Eclipse and your favorite Android
development tools. And these two plug-ins really
work well together. So let’s go ahead. Let’s call it Cloud
notes Z one. All right, I’ll go
to defaults here. Let’s give it a package name. Let’s call it Cloud notes. I don’t need an [INAUDIBLE]. I’m going to build my own. So I’m finished. All right, so this is like
a simple Android project. And you’re thinking, how do I
generate a backend for it? Is that going to be difficult? Now, just look at this. If I right-click this Android
project under the Google menu, you see there is this
option called Generate App Engine backend. It’s as simple as that. All you have to do
is click on it. So what’s happening is we are
downloading a bunch of libraries that’s going to help
you build APIs on App Engine. And it’s automatically saved
in your class [? pod. ?] And not only that, there are
libraries for Google Cloud messaging, which is
also downloaded. And there’s a library to
actually register your device with App Engine. That’s also downloaded. So all that is done for you. So you essentially have two
projects, one an Android project and one the
corresponding App Engine backend for it. So what’s the next step? The next step is to define APIs
that you can call from the Android app. So what do you define APIs on? You need to define it on some
kind of a resource. So in my case, the resource
is just a note class. So as you might have guessed, a
note is nothing but a simple plain Java, a portal. So I’m going to just copy
over some code. Let’s look at this. All right, so the note class is
nothing but a ID, which is like a unique field. I’ve marked it with a add ID
annotation, which essentially says that it’s a unique
identifier for this particular object. At entity is a standard Java
persistence API annotation to say that this object is
going to be persisted. Description and email
address are just fields, setters and getters. Now, how do I go about creating
APIs that actually create a note, delete a note,
list notes, all the functionality that you see? Again, our aim is to reduce the
amount of code that you have to write on App Engine. Google plug-in for Eclipse acts
like a good friend and allows you to do a one-click
Generate Cloud Endpoint class. How about that? So all your code is
pregenerated. [APPLAUSE] SRIRAM SAROOP: So you have the
list note method, which actually uses the Java
persistence API to persist your notes to the App
Engine data store. So all this code is pregenerated
for you. It should just work
out of the box. There’s list node. There’s get note, insert note,
update note, and remove note. In addition to all this code,
what you should notice is the small annotation on the top. It’s the at API annotation,
which essentially says that this is an Endpoint
that I want to be exposed as a REST API. That’s the only annotation
that you need to add. You can modify this class. You can add other
functionality. For example, if you want to
search note by some kind of a substring, you can add that. And in which case, you will have
to annotate each of the methods with an at API
method annotation. You can read up that
in the docs. But in the default case,
this should just work out of the box. So one thing that’s missing in
this code is the concept of authentication and a user. So list note, in this case, is
just selecting notes from the App Engine data store. It doesn’t really select notes
that correspond to a particular user. So how do I add the notion
of authentication? So it’s, again, really simple. So I’ve just made the
modifications. And I’m just going
to copy over the modified note Endpoint. So I’ll show you what needs
to be done here. So if you notice in the at API
annotation, I’m adding two other parameters. One is a client ID. That should be very familiar. Yaniv just generated that
from the API console. So you just need to
copy that string out that Yaniv generated. Copy it there. The audience is just to make
sure that the request is coming from the correct
server. So it’s just the application
identifier that you can get when you register
with App Engine. So those are two parameters
that you need to put. And after that, life
is simple. So what you need to do is to add
a parameter called user. So user is defined by
the App Engine SDK. And this user object is
automatically filled in by App Engine when a valid request
comes in to App Engine. So when a valid request with
the access token that Yaniv spoke about comes into App
Engine, App Engine is able to validate that and is able to
convert that to the user object that comes in nicely
to your APIs. So you don’t really have to
pass this user object. It’s created by App
Engine for you. And then it’s just a matter of
changing your code a little bit to make sure that you’re
fetching the notes for a particular email address. The user object has a
email address field. So you can use that
to achieve that. So similarly I modify all
the other methods. Get note I add a user parameter
and make the necessary checks. So all that stuff should
be self-explanatory. YANIV INBAR: Can you show me a
little bit what it looks like in the Android application? SRIRAM SAROOP: Sure. Before I do that, one thing that
I didn’t talk about in App Engine is the ability to
actually ping devices when the state of a note changes. How do I do that? Is that going to be difficult? Not at all, so device ping is
a class that’s generated by the Google plug-in
for Eclipse. And device ping has a method
called ping all devices. All you need to do is to
call ping all devices. And all devices registered
with App Engine will automatically be sent a ping. So let me just copy
one more class. And then we should be able to
go to the Android piece. All right, so like I said,
whenever the state of the resource changes, in this case,
note, so for example, when I do an insert note, I just
have to call device ping or ping all devices. And you know that should
send a [INAUDIBLE] ping. So let’s go on to
the Android app. So I’m not going to show you the
standard stuff of Android in terms of UI development
and all that. I’ll just show you the
pieces where I need to call the Endpoints. So I’ll copy over a bunch
of resources that’s needed for my app. Let’s get this [INAUDIBLE]
.xml out of the way. I don’t need it. And I’ll copy a bunch
of classes. I’ll quickly go through them
and then copy the manifest, which defines the activities
that I have. The last thing I need to copy
is this Google Play services [INAUDIBLE] jar. So it’s the jar which allows
you to have that awesome authorization screen that
Yaniv showed you. Unfortunately, it’s not part
of the Android SDK yet. It’ll soon be. So in which case, you don’t
have to do this. All right, so let’s look
at the classes that have been generated. OK, so it’s showing me
a bunch of errors. So let’s be adventurous and
see what those errors are. So it’s essentially saying that
it’s not able to find out what this con.appspots
stuff is. So one thing that it forgot to
do is to actually generate a [? strongly-type ?] client library for my API. So Yaniv showed you how you can
use a Java client library, how you can go to the website
and download the APIs for various libraries. Now, how do you do the same for
the APIs that you develop? Not a problem at all so
right-click your App Engine project, Google generate Cloud
Endpoint client library. So if things work, that client
library should automatically be generated. Copy down to your
Android project. And there you go. The compile errors are gone. [APPLAUSE] SRIRAM SAROOP: So if you see the
lib folder, all the client libraries, including the awesome
Java client library with all the OAuth libraries,
are copied over, set in your class [? pod. ?] In addition to that, you
also have classes that you can call into. So I’ll show you in a minute
how that’s done. So an example of an Async task
that I’m going to show you here is Async edit note,
which is actually the class to edit a note. And if you notice, the code
is really just one line. I just get a object
called Endpoint. I construct it in a very similar
way as I would for any other Google API. And I just call the method
that you want to call. In this case, it’s
update note. And I pass in the note object. It’s as simple as that. So all that stuff was fine. Now, do I want to actually– do we have time to actually
run this app? I think we do. So let’s give it a shot. YANIV INBAR: So what you did
here is you’re actually running it locally? SRIRAM SAROOP: Yeah. YANIV INBAR: There’s a local
App Engine instance. SRIRAM SAROOP: That’s right. So I’m running stuff
locally here. When you’re developing with
the Cloud, you want the ability to test stuff locally
before you can actually deploy it. So let me show you how
I’m doing that here. So just click on the project. Click on the run button. And App Engine should start
up locally for you. Let’s give it a while. The network here is
not very good. All right, it started. So let’s quickly deploy
the Android app. It’s not just the network. My laptop is also slow. Can’t blame Innertrod
for everything. All right, but I think
you guys should trust that it works. Let’s have a quick
shot at that. YANIV INBAR: I have to say. This is pretty amazing, 10
minutes to build an Android app like that. SRIRAM SAROOP: Yeah. Well, I had a lot of code
written already. All right, cross your fingers. So this is the new app. It just come out there. So the spinning wheel indicates
that it’s making a call to get all the notes. Obviously, there are no notes. Because it’s a brand new app. So let’s chill out since
its end of the day. You guys want to go home. All right, chill out, goes in. And just to make sure that I’m
not bluffing you guys, let’s go ahead and click
on list notes. And there you see chill
out out there. YANIV INBAR: All right. [APPLAUSE] SRIRAM SAROOP: All right,
let’s switch to– YANIV INBAR: Great. So you probably want to get some
more information about Google Cloud Endpoints. There’s a great link here. It tells you about the backend
part of building mobile apps as well as covering iOS
and web applications. Google Cloud OAuth support
all of those. And in fact, we have the same
generation service to provide [? strongly-type ?] libraries for iOS, objective C
and JavaScript dynamically. [APPLAUSE] YANIV INBAR: Yeah. And another great I/O session
about how to do it with HTML5 so I’m pretty excited
about this. And I hope you are, too. I highly encourage you to go to
the request trusted tester. I can show that link real
quick right there, endpoints-truste
d-tester.appspot.com. Go there. As well, if you’re interested
in how to build with Google Web APIs, your next
step should be to go to the code labs. So we actually have two great
code labs for you tomorrow. The first is how to build
REST APIs for mobile. I think there’s a great
tic-tac-to sample that you can build, a very simple one. And I hope that gives you
confidence of working with Google Cloud Endpoints. That’s at 11 o’clock. And I’ll be there at 1:15
for the code lab on working with Web APIs. I’ll step you through
the outflow. I’m sorry I’m not going
to be able to show you Google Play services. But I’ll show you the standard
Account Manager flow. It does work really great or at
least fairly well with your new Nexus 7 device. So bring that with you. And I’ll be there to answer
any questions. And before we jump into
questions, I just want to make one request from
everybody here. If you like this session, please
grab one of those plus one cards and put
them in the box. I’d really appreciate it. SRIRAM SAROOP: And we
have a bunch of stickers, Cloud Endpoints. So come here and
collect those. [APPLAUSE] SRIRAM SAROOP: Can you go
to the mike, please? YANIV INBAR: Yeah, please go
line up next to the mike if you have any questions for us. If there’s not enough time,
please feel free to come by. We’ll just stick around. Happy to answer any questions
you might have. So go ahead. AUDIENCE: Yeah, I was
wondering if– These are great presentation
by the way. But I was wondering if any of
these tools and plug-ins are going to be available for
Intellij or other IDEs. SRIRAM SAROOP: So it’s not
currently available. But we do have other means of
generating a Cloud Endpoint. For example, we provide a script
that you can just call on the command line. So currently we do not have IDE support other than Eclipse. AUDIENCE: Because, seriously,
Eclipse sucks. YANIV INBAR: Yeah, that’s
a great question. So like he said there’s
a command line tool. SRIRAM SAROOP: We can have
a debate on that. YANIV INBAR: So actually one
of the cool steps that he showed you is generating
the client library. That’s actually done
in the Cloud. We actually have a service
that does it. So in theory, it should be
really easy to build Intellij integration. Because it’s just a Cloud
service that you can call. AUDIENCE: So I’m actually
working on essentially a weather app. And all I’m trying to do is
synchronize some really simple settings like units, location,
stuff like that. And I came across the backup
API, which I know isn’t supposed to be used for
synchronization. So that’s kind of what I
wanted to ask about. Because having to go maintain
a server and do all of that work just to do something that
simple, it seems like App Engine is really designed more
for applications which almost revolve around– SRIRAM SAROOP: Yeah, so as an
example I showed you how to achieve states in transition. But one thing that I did not
show you is how do you actually store the
state locally. AUDIENCE: Exactly. SRIRAM SAROOP: And you don’t
get it automatically synchronized with the Cloud. So just wait for a few weeks. We’re coming up with an awesome
technology that’s going to allow you to
synchronize shade preferences, which is the standard way of
storing settings on Android across multiple devices using
App Engine as a backend. So that’s going to come out
of the box for you that you can just use. And that stuff should
just work. AUDIENCE: That’s exactly
what I need. SRIRAM SAROOP: Awesome. AUDIENCE: Thank you. YANIV INBAR: Thanks
for asking. SRIRAM SAROOP: Yeah, yeah,
thanks for asking. I almost forgot about that. AUDIENCE: So I have a question
about the authorization part. Like you said, it’s going to
be handled but yet to be released Google Play,
I don’t know,– YANIV INBAR: Play services. AUDIENCE: –plug-in
or whatever. So does this mean that the
Account Manager stuff is being deprecating or– YANIV INBAR: Ah, great question
so is the Account Manager stuff being
deprecated? And I probably shouldn’t answer
that question just because I’m not the person who
owns that part of the code. So I don’t know what
their plans are. But essentially, yes, I mean if
not literally deprecated. SRIRAM SAROOP: Essentially,
yes. YANIV INBAR: We want you to
switch to using Google Play services definitely as
soon as it comes out. AUDIENCE: So it will be like
updated automatically along with the Play client or– YANIV INBAR: So it is actually
an essential part of Google Play. And the beautiful thing that
they’ve done is, rather than just building up the Google
Play, they’ve opened up for developers for anyone to use,
which is just fantastic. So because it’s an essential
part of Google Play, it will be a market update
for everybody’s device, Froyo and higher. AUDIENCE: Because up until now
you have to wait for the next iteration to get the Google
services and Account Manager and whatever. YANIV INBAR: So I want
to make this clear. It’s not just part
of Jellybean. Because it’s an independent
component, it’s not part of the operating system,
it’s just going to be a market update. You’ll get a new application. And so that’s the [? APK. ?] And as well, they will also
publish a jar file, which you include in your Android
application that makes it very easy to use that service. AUDIENCE: Thanks. AUDIENCE: Do you have any
examples of using access control lists and things like
that say, for instance, that note, you want a whole group to
be able to edit that note and where things would fit in? SRIRAM SAROOP: So we
don’t right now. So maybe we could discuss a bit
more to understand what you’re talking about. YANIV INBAR: Can you repeat
the question, please? AUDIENCE: Talking about access
control lists to Endpoints and data and who manages that, where
abouts is that managed? YANIV INBAR: Oh, that’s
a great question. How do you set up access control
lists for that data? So let’s follow up on that. We would like to find out more
about what your use case is. I mean, obviously, you can
build anything, right? It’s an app engine. But that’s a great question
how to make that easier. AUDIENCE: I had a question about
the Account Manager. You said that for using
basically Play services you’ll be using, what was that,
AccountPicker? YANIV INBAR: Yes. AUDIENCE: Does that mean I need
a Google account or Gmail account to use Play services? YANIV INBAR: OK, yes, that’s
a good question. So what I’ve done, so actually
I don’t think there is that restriction necessarily,
however, as far as the Google Play services tools. However, because it will only
work with Google’s Web APIs, it will not work with any OAuth
2.0 server, it has to be a Google account. Now, it doesn’t have to
be a Gmail address. It can be even a
Yahoo account. As long as you’ve set up a
Google account for that email address, it should work. AUDIENCE: Is there a way to
use the OAuth and the API infrastructure without going
through App Engine like if it’s your own server? SRIRAM SAROOP: So it’s currently
not available. But that’s an awesome idea. And we are looking
into it, yeah. YANIV INBAR: Yeah, build your
API on a different kind of server, so as we said, we built
this API infrastructure. In theory, you could build any
kind of service on top of it. But coming up with the
underlying infrastructure of connecting that Google Cloud
with that API infrastructure makes a lot more sense when it’s
all part of the Google Cloud platform. AUDIENCE: Can you
still hear me? If you’re looking to create
an API system for your corporation or whatever, is
there anything else you’d recommend out there
besides this? Obviously, you can’t
use it yet. SRIRAM SAROOP: Sign up
for Cloud Endpoint. Check it out, man. AUDIENCE: OK. YANIV INBAR: Give it a shot. SRIRAM SAROOP: All right, so
we’re close to wrapping up. So thanks a lot, guys. [APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *