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


Uploaded by GoogleDevelopers on 03.07.2012

Transcript:

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 srsaroop@gmail.com 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]