Tip:
Highlight text to annotate it
X
BRAD ABRAMS: Good afternoon.
Thank you for coming.
In this talk, we're going to show you how to build
backends, cloud-based backends in for your amazing Android
applications.
I'm Brad Abrams.
I'm a product manager on the cloud team.
DAVID CHANDLER: And I'm David Chandler, an
Android developer advocate.
BRAD ABRAMS: So David, I haven't seen you in a while.
How are you enjoying IO?
DAVID CHANDLER: It's great.
It's great.
Love to be here and meet up with geeks from
all around the world.
You know, the only thing that I think we need for IO is, we
need a way to find geeks.
Because there's lots of them around, but I don't know what
everybody's interest is, and when people scatter out at the
city at night.
BRAD ABRAMS: You know, I think there's an app for that.
We've got a couple of hours.
We've got-- not a couple--
we've got 39 minutes.
We could probably build a cloud-connected Android app to
solve just that problem.
DAVID CHANDLER: I think you're right.
BRAD ABRAMS: What would be on your wish list?
DAVID CHANDLER: I'd probably want a map display.
And it would show me where other geeks are.
They'd have a way to register what they're interested in--
Android, Chrome, cloud, et cetera.
And then maybe color code the markers by their interests and
show them on the map.
BRAD ABRAMS: Yes.
So David, you really, they shortened the session length
this year, so there's only like 40 minutes.
I don't know if we're going to have time to build all that.
But luckily, we launched a new member of the Cloud Platform
family, the Mobile Backend Starter.
And what this does is, it's a no code server solution to
build a highly scalable, cloud-based backend in for
your mobile applications.
It's built on App Engine, so it was born to scale.
We've got built-in Google Authentication, built-in
Google Cloud Messaging, and a very cool Continuous Query
feature that we'll show you about.
The Mobile Backend Starter has two parts to it.
The first part is on the server side with App Engine.
We define a few Cloud Endpoints exposed over Rest
APIs to do generic data storage and access from there.
And then it integrates with Google Cloud Messaging to send
tickles down to the device.
And then on the device side, we have a Client Library
that's tailored to that backend, and then a place to
put your own application.
So with this David, how do you think that would
look for your app?
DAVID CHANDLER: Well, we need to come up with a map display,
so we could use the new Android Maps V2 API.
And then use the Mobile Backend Starter to make our
queries to the cloud, and get the locations of geeks, and
report our own location up as well.
BRAD ABRAMS: Sounds good.
So should we get started?
DAVID CHANDLER: Absolutely.
BRAD ABRAMS: OK.
Let's go.
So our story begins here at the new Cloud Console.
This is the new integrated experience for
all the cloud features.
So if you might have been used to using API console in the
past, and eventually this will also replace the App Engine
admin console.
But for now, both exist in parallel until we get this one
all the way there.
So on this site, and I invite you if you're watching this
online, to play along with us here.
If you want to follow the steps that I'm saying.
The Eng team would love it if you just really slammed our
servers right now.
So you just go to cloud.google.com/console and
create an app.
And then click on this Get Started button.
There's a few samples here to choose from.
One of them is this new Mobile Backend.
Now for the sake of appeasing the demo gods, I have already
deployed this a little earlier this morning.
But the way this works is, you just click on Deploy here.
And notice I can download--
all the backend source code for this is available.
I can download that and do whatever I want to with it.
Or I can just deploy that.
And this, without having to install any App Engine SDK,
any tools on the client.
It deploys a fully-functional App Engine app.
Everything we're going to show you in this demo is
already in that app.
And that's deployed for you.
Once that deployment finishes, you can click on the Settings
link there.
And that will open up the Admin Experience for this
mobile backend.
In it's actually part of the App Engine app
that we've just deployed.
And you can see here, we start locked down.
It is locked down by default.
and the messaging is disabled by default.
So it's locked down so no one can access your server.
So what we want to do for development mode is flip this
to Open Access.
And that means everybody can access your endpoint.
The next step we need to do, we come back over here.
We did step one, step two.
Step three is to download an Android client.
So we have all of the source code available
for an Android client.
That works super well in the Android IDE or in Eclipse.
So we're going to use Eclipse with ADT, the latest Android
Development Tools installed.
And I've actually already downloaded that and have the
project here in Eclipse, so you can
see what you're getting.
There's the base files that handle accessing the server.
And then there's a sample that comes with it with this Guest
Book example, which we'll take a look at.
And then the main configuration place to look at
is this cons.java file.
And we'll look at this a little bit over the
course of the talk.
But there is a few constants here that you fill in to be
able to wire these things together.
So what we need to do is wire up our client to our server,
just so they can talk.
If you're familiar with App Engine, it has a URL format
that matches the project ID that we gave it.
And then we just give the project ID in
the cons file here.
I've actually already got that up and running.
I've already deployed that.
So if we just switch over to the camera, which is here.
So here we have, this is the Guest Book app.
This is what comes by default with the project.
And we can just send a message here, "Hi
IO." And I click Send.
When I click Send, what it's going to do is send a REST
request up to the server.
The server will store that data in App Engine's noSQL
data store.
And then we'll get a Ack back on the client here.
And just to show that, let me switch back.
I am--
DAVID CHANDLER: Four.
BRAD ABRAMS: I'm four.
Sorry about that.
OK.
We'll just switch back here.
And let me show you in the new Cloud Console.
So if we switch up here, you can see our beautiful new
Cloud Data Store Explorer.
And we click on Queries.
And we can see that entity that we [INAUDIBLE].
Notice there's that Guest Book entity.
You can create your own entities.
And they can have any fields that you want them to have.
And you can see, here's our Guest Book Entity and there's
the "Hi IO." So in about five minutes, we've already built a
cloud-connected Android app.
But I think there's more we can do.
I think for the Geek Serendipity app David's going
to build, he's going to want more than just storing the
state in the cloud.
He's going to want to be sitting at a coffee shop and
just see geeks pop in on his mobile device, without having
to refresh the application.
DAVID CHANDLER: In case I can't recognize them when they
walk with their Google apps.
BRAD ABRAMS: Right.
Exactly.
So there's a couple of approaches to this.
This is not the right slide.
There's a couple of approaches to this.
And we don't have our--
anyway, yes.
There's a couple of approaches to this.
One would be polling.
We could, from the client of the app, we could every few
minutes, we could go up to the server and
say, is anybody new?
Is anything new?
And get the results back there.
But that would be bad.
That would be expensive in battery life, expensive in
network resources, and would use a lot of server resources.
So rather than that, we're going to use
Google Cloud Messaging.
It's the same technology that Google uses to power Gmail on
Android or Google Chat.
There's a persisted connection that's maintained between
Google's data centers and all the phones that have those
Google Experience apps on them.
And your code, your applications can use that same
channel to be able to send notifications.
So we're going to use that.
So there's really two steps to doing that.
The, first step is we need to know who is sending the
notifications.
And in our case, it's going to be the Mobile Backend Starter
that we just deployed is going to send those notifications.
So the way we do that is, let's come back to our app
here and click on APIs.
And you can see, I've already ahead of time turned on the
Google Cloud Messaging for Android.
So you have to enable this API.
And then, we go into the Mobile Backend Starter, and we
need to give it the API key.
This is where we're going to use that to pass along to say,
here's who's sending the Push notification.
So in order to do that, in order to get that key, we'll
go into the New Cloud Console and we'll register a new
application.
And we'll just call this our Mobile Backend.
And it's just a generic web app.
And we'll register it.
And we'll actually use this a couple of times when we do
Auth as well.
But for this time, all it asks for is that server key.
So we just grab that server key and put it in here.
And we've done everything we need to enable our server side
for Push notification.
The last bit is just to put the project ID
that cons.jafa file.
Once we've done that and deploy, then we get the same
Guest Book application.
But now if David were to send us some messages, David's got
that same app running over there.
Oh, and we need to switch to it, so you can see it.
So what David's going to do is he's going to find the app.
And then he's going to start sending us messages.
When he sends a message from his phone, that's going to do
a REST request up to the server, going to store that
data in data store.
And then there's a technology called Perspective Search that
is looking at changes in the data store.
And when it sees a change, it's going to send a
notification over to Google Cloud Messaging.
Google Cloud Messaging will then find the subscribers and
send a message down to my phone.
And you can see, David's using all his creativity at this
point to come up with very creative things.
And you can see sort of hands free, we're getting
notifications.
So just a few minutes in, and we've already got a pretty
functional application with just setting a
few variables there.
So at this point, David, I think we're probably ready for
you to start putting some map goodness on here.
DAVID CHANDLER: OK.
Excellent.
So I have started project based on the cloud backend
that Brad has on his machine.
And I've put on a Map activity in it using the
new Maps API V2.
So there's just a map fragment and a very simple activity,
which I'll show you here.
And you have to paste your API key into your
Android manifest as well.
Don't forget that if you're setting up maps.
Let me zoom in on this code a little bit so you can see a
little bit about it.
We just have a Setup method where we obtain the reference
to the map.
And then we enable our location, which makes the
Location Services work.
So that gives you the Locator button in the upper
right in the app.
And that's really about all there is to it for getting the
basic map up.
So what we want to do is, as soon as we launch the app with
the map, we want to find our location.
And we're going to use the integrated Google Location
Services that work with the Maps V2.
And then we want to do something whenever it comes
back and notifies us it has a good location for us.
So there is a listener called On My Location Change listener
that we can set.
And that will allow us act on that information.
So what we'll set that--
set On My Location Change listener.
And I'm going to just let this class implement it.
Let me blow this up again a little bit.
So we're getting an error there because we need to let
this class implement that method.
So we'll go ahead and add that.
And then, oops--
scroll back.
We need to add the actual method.
So I've got a little code here I'm going to paste in from the
snippet on my Location Change handler and we'll fixed
imports here.
Zoom back in on it.
And you can see, it's doing Send My Location.
And then we've got a little code further down to do that.
And it's not implemented yet, so let's go ahead and
implement this method as well.
So to send our location to the server, we're going to use the
cloud's backend sample code that's here.
And it's really pretty straightforward.
We just create a generic entity, that's the way the
cloud, the Mobile Backend Starter works, is it gives you
generic cloud services that you can send and receive these
generic cloud entities.
We're just creating a new cloud entity.
And we're making of kind of Geek.
This works really well with the App Engine Data Store
because it is schemaless.
So you can create any number of kinds and
properties on the fly.
That makes it actually it very easy for us write this kind of
application right now.
So we'll put in a few things.
Our interest is cloud.
Our location is what we just got from the
Location Change Handler.
And then we call getcloudBackend.update, and
this is one of the built-in methods that's available to us
as part of the Mobile Backend Starter.
And because in Android everything should be
asynchronous, we pass it a Callback handler that will get
called when the request completes.
And when the request completes, then we draw a
marker on the map.
The reason getCloudBackend is in red is because I need to
let this activity extend Cloud Backend activity now, instead
of Fragment activity.
So there we go.
Now all those features are available to me.
You can look here and see that method should be OK.
So let's take this and run it on the phone.
It'll take just a second here.
Let me get the phone plugged in.
OK.
And a little trick I learned just this morning actually, is
that if you want to install an app on your phone but not run
it yet-- which I'm going to do because of the ethernet
situation here--
you can just change your run configuration and tell it to
do nothing on launch.
And that will build and install the app on the phone,
but it won't actually launch the activity yet.
So we're going to go ahead and do that now.
Run as Android application.
See it's building.
We'll wait for it to come over here.
And then we'll go plug the phone into the ethernet and
show the map on the camera.
OK.
It looks like it's already there.
I'll grab this.
BRAD ABRAMS: Not that we're paranoid about the network.
DAVID CHANDLER: Yeah.
These Galaxy Nexus phones have the capability to do USB to
ethernet, which works very well for us here.
So here is our app--
comes up with our basic map display.
We have Location Services available.
And then when we touch that, we should see that
it will locate us.
BRAD ABRAMS: You should see.
DAVID CHANDLER: Very interesting.
It doesn't seem to be able to find a location for us.
Let's see if we scroll the map over and zoom in a little bit.
Well, something new every demo.
BRAD ABRAMS: Awesome.
DAVID CHANDLER: OK.
BRAD ABRAMS: So David's going to debug that.
DAVID CHANDLER: Yeah.
I think, I think maybe not.
BRAD ABRAMS: OK.
DAVID CHANDLER: I think we'll go to the next stage.
BRAD ABRAMS: OK.
Great.
Yeah.
Yeah, so David's going to debug that while I go--
so David is now theoretically sending our
location up to the server.
DAVID CHANDLER: Yes.
BRAD ABRAMS: Yeah.
David is now sending our location up to the server.
And I have the digerati following me all the time.
And I think with our server being open and my location
being sent up there, that's sort of a bad combination.
So what we want to do is lock down our server.
We're going to lock it down so only our Android client can
call our server.
Just because there's REST endpoints out there, doesn't
mean we want everybody else to call them.
We only want our client app to call those endpoints.
Now there's a number of options for how to go do this.
Some people have been put secrets in their Android app--
some token that they generate that's in their app.
And they send that up on each request.
But that has a obvious problem, because how many of
you have ever unzipped an APK before?
Right.
And so if you can do it, a lot of people
could probably do that.
And so those secrets are discoverable.
So rather than using some secret that we put into the
APK, we're going to use a mechanism that's built right
into the Android OS.
And that's, all Android apps are signed.
There's a digital signature that's
cryptographically strong.
And we're going to use that signature.
That signature is actually what the Google Play Store
uses when it is updating apps.
When it's finding which app to update, it uses that signature
to ensure that you're the same publisher.
So what we're going to do is use that
signature on the client.
And we're going to give that a token generated from that
signature up to the server.
And that'll be sure the requests only
come from our app.
So to do that, what we'll do is come back over to the
Mobile Backend Settings page.
And then, it's asking for an Android client ID that I've
already filled in.
So the way you get that Android client ID is back in
the cloud console, you register a new app.
So click on Register App.
I've called it Android client--
client.
And then you just give it the package name and the SHA1
fingerprint.
The SHA1 fingerprint is the interesting one to get.
That you run the Keytool command over your
debug.keystore file if you're in Debug mode.
And that keystore file is generated for you
automatically by the Android ADT.
And it's in the--
it's usually in your root directory in dot Android.
So anyway, we generate that.
And then once we have that, we have a client ID
that's all wired up.
So we just take that client ID and hand it
to the mobile backend.
So that handles the first step.
The second step of this is, if you noticed, we're actually
using OAuth to do this security.
And OAuth is tried and true technology, but somebody may
associate OAuth with the OAuth Consent Dialogue that you may
have seen before, like when you're trying to access say
Google Plus data or Google Docs on behalf of somebody.
They'll get a prompt that says, do you want to allow
this app to access your Google Docs data?
That's a OAuth Consent screen.
And that makes sense in that scenario.
But in our scenario, we have the Geek Serendipity app on
the client accessing the Geek Serendipity Backend.
That's not one where--
the OAuth Consent screen would be sort of silly.
Do you want the frontend of this app to be able to talk to
its own backend?
And that's not a choice that we think is
meaningful to users.
And so what we do is, we can suppress that screen so it
doesn't get seen, if we know the publisher is the same on
the client and server side of the app.
If we know it's your backend and your frontend, you don't
need to see that screen.
So the way we prove that it's your backend and your frontend
is we use a web client ID.
And so you get the web client ID--
this is that--
yeah, this is the Mobile Backend that we created
earlier for getting the Google Cloud Messaging to work.
And before we used the server key.
And now, we're going to use the OAuth client ID.
So we just grab this OAuth client ID.
And you put it in the second field here for
a Web Client ID.
And then you also put it in your Android app.
So it needs to be in both.
Now this is not a secret.
Somebody could unpack your APK and get that, and they still
couldn't access your backend.
It just proves that you're the same user on the frontend and
the backend.
OK
And then there's one more step.
So the last thing is very easy and that is that because we're
using Google authentication in here, we have the same notion
of who a user is on the client and the server.
That's built into the App Engine framework and it's
built in to Android.
So it's a very seamless experience.
So I've have already loaded that up on this phone, and
let's switch over.
So I loaded this app just a minute ago onto this phone.
And you can see now, when I run the app, it's giving me a
chance to login.
And all of the--
most Android phones have [INAUDIBLE]
IDs, Google IDs, associated with them.
So I'll just log in with this one.
And now what's happened is, it's gone out and
validated who I am.
What's the secret?
DAVID CHANDLER: The secret is in order to know your location
it needs one of two pieces of information--
either GPS--
BRAD ABRAMS: Awesome.
DAVID CHANDLER: --or Wi-Fi.
We have Wi-Fi off, because we had it hard wired.
BRAD ABRAMS: Awesome
DAVID CHANDLER: And now we have Wi-Fi on.
BRAD ABRAMS: Give it a whirl.
[INTERPOSING VOICES]
BRAD ABRAMS: Fantastic.
So now it knows who I am and where I am, and we're looking
for an acknowledgement that it knows who I am.
And we can switch over and see the data store.
Is it going to work?
OK.
DAVID CHANDLER: I think so.
BRAD ABRAMS: Give it one more second.
Let's switch over and see.
I'll just run this.
It's not there.
DAVID CHANDLER: Let's try closing the app.
BRAD ABRAMS: So now turn off Wi-Fi.
We're done with-- we know where we are.
Now we can use the internet-- that we can use the hardwire.
DAVID CHANDLER: No, I don't think so.
I think we want to close the app and then come back in.
BRAD ABRAMS: OK.
DAVID CHANDLER: Sorry.
BRAD ABRAMS: Just one demo glitch.
DAVID CHANDLER: Yeah.
BRAD ABRAMS: We really need the ethernet to be able to
tell us where we are.
So what we've done so far, is we've built a
backend on App Engine.
Just click once to deploy that backend.
And we've stored our state there.
We've shown Push notification, the easiest GCM wire-up I
think you've ever seen.
And we've showed using a map and logging in.
DAVID CHANDLER: Sorry.
I did something wrong.
BRAD ABRAMS: OK.
All right.
DAVID CHANDLER: We'll move on to the next thing.
BRAD ABRAMS: And so that will now store your
data up on the server.
So you want to switch the next one?
DAVID CHANDLER: Yes.
BRAD ABRAMS: OK.
DAVID CHANDLER: OK.
So now that we are sending our location to the server.
BRAD ABRAMS: Sorry.
OK.
DAVID CHANDLER: We'll go ahead and proceed with the next
stage, which is we want to find out where all
the other geeks are.
So we want to query the server.
And if you could put up the slide.
BRAD ABRAMS: Oh, I forgot that.
DAVID CHANDLER: --the Keynode slide.
BRAD ABRAMS: OK.
DAVID CHANDLER: I'll tell you about the Continuous Query
Capability that we're going to use to do that.
So this is a feature of the Mobile Backend Starter project
that uses several App Engine features as well.
There's a API [INAUDIBLE] preview
called Prospective Search.
And what that does is, anytime data comes in that matches the
parameters of your query, then App Engine will notify your
app on the server side that some matching
data has been found.
So we're going to use that to our advantage here.
Any time a new location update gets posted, then our Apple
get notified on the server side.
And the Mobile Backend Starter project takes that further,
and will send a GCM message to our app running on
the phone, as well.
So the flow looks like this.
In step one, a new location update comes from the phone.
It gets put in the server.
In step two, the App Engine Perspective Search API
notifies the server side part of our Mobile
Backend Starter app.
That sends a GCM message--
Google Cloud Messaging-- to the client in step three.
Then in step four, we re-query to get the latest data from
the server.
And then finally, step five, we draw the markers on the map
with that most recent data.
So I'm going to go now write the code that actually does
this in our app.
So we'll again take a look into our Map activity.
And the first thing we want to do is write a query.
I'm just going to stroll down a little bit here.
That will go out and get the geek locations.
So let me paste in some code here--
query geeks.
And show you what that looks like.
All the capability that I just described on that slide is
called Continuous Queries, is what we're calling it right
now on this project.
And so the first part of our query is to write a handler
that will receive the results.
So we have a On Complete handler and we're just going
to draw markers.
Simple enough.
Then to actually register the query, we call Get Cloud
Backend, dot Clear All Subscription.
Now, the notion of a Continuous Query, you can
subscribe to queries on the server.
So we want to clear any existing subscriptions, and
then set up a new one.
So we say New Cloud Query for kind Geek.
We're just going to get the top 50 geeks sorted in order
of the most recent location updates.
And we're going to make the scope future and past.
So again, this is a feature of the Mobile Backend Starter
that lets you say, I want to be notified of future matches
to this query, as well as present.
And if you think about the amount of code that you have
to write to do that all manually, setting up GCM,
keeping track of this data, it is actually a very nice
convenience.
And then we actually register this query by calling
getCloudBackend.list.
And we pass it our query and our handler.
So the code that runs up here in lines 72 and 73, the On
Complete handler will get invoked any time there's a new
location update that gets sent to the server.
Then all the clients who are subscribed to that query will
get notified so they can update their
map displays as well.
So we've made a query method.
Now we actually need to call this.
And we only want to call this query.
Now we have authentication turned on, it's going to
enforce that at the server side.
So we only want to call it if we're already authenticated.
There's another method that's useful to do that in our
project called On Post Create.
We can inherit this from the Cloud Backend activity.
And here's where we're going to call our Query Geeks method
to register our query--
so only gets called after we're authenticated.
And then lastly, I just want to remove my Draw Marker
method, because now in our On Complete handler, we're
drawing all the markers.
So that's the final code for that.
Let me go ahead and put it on the phone.
BRAD ABRAMS: You have a suggestion?
DAVID CHANDLER: Right.
We'll do run as Android app again to get it here.
And once it appears, I will cross my fingers, walk over
there, stick it under the camera.
Wi-Fi's still on on this one.
You'll need Wi-Fi on for the second part
of the demo as well.
OK.
So here we go.
Going to give it a whirl here.
I'll switch back to the camera view.
And we'll try the app.
Authentication is enabled now, so I have to log in.
The map should be coming up.
You know what I didn't do.
I didn't plug in the ethernet, but Wi-Fi
appears to be working.
Yay.
BRAD ABRAMS: Shoot.
DAVID CHANDLER: And we'll locate.
OK.
And there is a marker--
actually two markers, which is exciting.
Have you already launched the app?
BRAD ABRAMS: No.
DAVID CHANDLER: OK.
Well.
BRAD ABRAMS: You may see one more.
Let's see.
DAVID CHANDLER: In the advanced section of this
presentation, we will discuss how the clone ourselves--
or at least, our Android devices.
Yep, I saw it appear.
BRAD ABRAMS: Did you see a third one?
DAVID CHANDLER: Yes, I saw the third one appear as
Brad did the demo.
You remember, there were two, right.
Nothing up my sleeve.
A third marker appeared.
That is the Continuous Query in action when he ran the app.
Thank you very much.
BRAD ABRAMS: So, did you want to do that slide?
DAVID CHANDLER: Yes, let me get that up here.
I'll switch back to mine.
I wanted to say a little bit more about a couple of things.
First, the Mobile Backend Starter project is brought to
you by a team at Google called the Cloud Solutions Team.
And I wanted to acknowledge the engineers there--
I'll be calling Greg, because no one can pronounce his name
properly, Kaz Sato, and Jenny Lo.
The Cloud Solutions Team is involved with helping App
Engine customers figure out the optimum technical
solutions to run--
cloud customers, more generally.
And they also publish best practices white papers you can
find them at cloud.google.com under the Solutions Section.
I wanted to mention a little bit more async tasks, as well
because part of the magic that the Mobile Backend Starter is
doing for you is to run off the UI thread.
And Android is behind the scenes.
That Cloud Backend activity is actually creating a new thread
for the network request.
But that's all.
You're insulated from that.
You don't have to worry about it.
Even better would be to use services on the Android
platform, and that's something that we're looking at
extending that project to do.
BRAD ABRAMS: OK.
Thank you.
So I think now we have a very full-featured app, and its
cloud connected.
I think the Mobile Backend Starter has
served us really well.
We haven't had to do any server code yet.
But I'm a server guy.
And I was talking earlier, I think there's a few App
Engine-- who's sort of an App Engine guy here?
Are you guys missing writing code on the server?
I know I am.
So I constructed a reason to have to write
some code on the server.
So both David and I are little bit data geeks.
Being at Google, we love processing lots of data.
And so we want to log everything about the user
experience on this app-- how do people use, how they pan,
what do they do on the app-- so that we can do data
processing on it, and learn how to make the app better.
But the Mobile Backend doesn't have a logging mechanism--
doesn't have any way to store stuff in logs yet, although
they will probably add it right after this talk.
But for now anyway, it's an excuse to
write some server code.
So we're going to write our own custom cloud endpoint that
is part of this Backend Starter.
And then we're going to call that endpoint from a Client
Library in the client.
So let me show you how this goes.
So what I've done is I've gone out to GitHub and I've
downloaded the source code for the Mobile Backend Starter.
As we've said, everything in this thing, the
source code's available.
So if you don't like something Greg, did you can go and
change that.
And so what I'm going to do, I've got that.
And I'm just going to drag in an end point I wrote earlier.
And this is the world's simplest cloud endpoint.
So it's got that @API attribute that indicates to
App Engine at that we're going to expose this is a REST API.
And then right here, we're seeing where we are defining
what its name will be in the Client Library and what the
REST interface should be.
And then, it's very simple.
We just call log.info and put that in the App Engine logs.
So I've already deployed this a little earlier this morning.
And what's very cool about Cloud Endpoints is that
there's this neat URL.
If you go to _ah/api/explorer, then you can actually view the
API Explorer for your interface.
So what we saw earlier was the Mobile Backend.
And now I've just added a new one called Cloud Login API.
And that's got the same name I gave it in the source code.
And now if I "hi from the web app," then this goes out and
it calls my interface.
And if I look at the App Engine logs for this, you can
see there is that log, "hi from the web." So, very nice
experience there.
Now what we want to do is called this
from our client app.
So in order to do that, what I need to do is generate a
Client Library.
So I'm just going to right click on this and find the
Generate Cloud Endpoints Client Library feature.
And this is going to go out.
It's, going to take the discovery document, the
description of that interface, go out to the web to a service
we provide that will generate a strongly-typed
Android-optimized Client Library for our service, and
then download it, and put it right here in this project.
There it is--
Client Logging.
DAVID CHANDLER: That functionality, by the way, is
provided by the Google plug-in for Eclipse.
BRAD ABRAMS: That's right.
And then, we just need to copy it over, very simple.
I'm just going to drag this over.
And now we need to add it to our Build Path, so we're going
to right click on this and use a source folder.
So now this to be part of the build.
And then, I just have a very simple bit of source code to
add to the client to actually do the calls.
And let me show you what this looks like.
So this is my Cloud Log function.
It's very simple.
In the constructor, we take the unique ID of the Android
app that we're using.
So we can tell in the logs what's happening where.
And then in a thread, I am going and doing the
asynchronous call up to the server.
And that's right here-- service.logs.log, passing that
message, and doing execute.
In just a couple more-- if we had a couple of minutes--
I would wire this up into the UI, but it's very simple.
You just call this Log method and we do that request each
time up to the server.
You might want to do batching, but for the demo to be snappy,
I decided not to.
There's nothing really to see on here, but I have this on
the phone and I'm just going to pan around a little bit,
generate some log data hopefully, if
the connections working.
Then if I come back to my logs, I should see new logs.
And we do in fact, see logs from client, right,
with a unique ID.
And this is for example, on my location changed.
So we've shown you how to add custom logging to the custom
endpoints to your Mobile Backend Starter.
So with, that I think we're pretty much done.
Let's--
DAVID CHANDLER: OK.
BRAD ABRAMS: --wrap up.
DAVID CHANDLER: All right.
Everything that we've done today is available.
The Mobile Backend Starter, of course, you can get to off
cloud.google.com in the Cloud Console,
as Brad showed earlier.
The demo code is going to be posted soon, as well.
And we also created a little more refined version of the
app called Geek Serendipity, which you can download in the
Play Store.
I may drop that on the camera real quick here, just so you
can see it in operation.
We sent it out the other day and allowed a few
people get in on it.
So you can see, it'll just put markers on the map for you,
showing different types of geeks in the area.
So we hope you enjoy using the Mobile Backend Starter.
And we have one minute and a half left.
If there's a quick question, we could take that.
Yes, right here.
AUDIENCE: Do you need to inherit from the
Cloud Backend activity?
DAVID CHANDLER: Do You need to inherit from the
Cloud Backend activity?
Currently, yes.
Yes.
AUDIENCE: [INAUDIBLE].
DAVID CHANDLER: Yes, we are looking at moving it into a
fragment or otherwise abstracting that capability,
so that you don't have to extend.
Yes, behind you.
FEMALE SPEAKER: There's a microphone right
in the center aisle.
DAVID CHANDLER: OK.
Yeah, please step to the microphone.
Thank you.
AUDIENCE: OK.
So What would be the difference between using that
Cloud Messaging and web sockets or Channel APIs?
DAVID CHANDLER: What would be the difference between using
Google Cloud Messaging, web sockets, or other APIs?
AUDIENCE: Channel APIs.
DAVID CHANDLER: Or a Channel API?
OK.
Google Cloud Messaging is really optimized for phone use
because it'll send the updates over the air.
It's written in such a way to be battery efficient.
And it is a true Push mechanism.
Some of those others maintain long-running connections.
I'm not sure they're designed as much for Android,
specifically.
So I think Google Cloud Messaging would be the most
battery efficient.
BRAD ABRAMS: I think we're out of time.
So thank you very much.
Appreciate it.
DAVID CHANDLER: Thank you.