Tip:
Highlight text to annotate it
X
[MUSIC PLAYING]
ARUN NAGARAJAN: Hello and welcome to another exciting
episode of Google Developers Live.
This is Script It!
With Android, and my name is Arun Nagarajan.
I'm with the Apps Script Developer Relations Team and I
have a special guest.
ADAM KOCH: Hey, guys.
My name is Adam Koch.
I'm from the Android Developer Relations Team.
ARUN NAGARAJAN: Excellent!
ADAM KOCH: Happy to be joining Arun today.
ARUN NAGARAJAN: Excellent!
Yeah, super excited to have folks from the Android Team.
Adam usually does a lot of stuff around design and
writing some killer apps, and today he's going to help us
walk through what we can do with Android and Apps Script.
So the series here today, it's just called Script It! and
it's something that the Apps Script Team does where we take
what Apps Script's all about, along with other Google
products to explain how you could do more with apps,
specifically Apps Script.
And in today's session, we're going to talk about how
Android could leverage some of the backend capabilities of
Apps Script, to expose data from a spreadsheet or even
notification, and through Google Cloud Messaging.
So that's quite exciting.
So we have some exciting demos, and we're going to show
some slides to orient you, and then we'll dive right into the
demos and we'll share all the code right after it.
So the folks that are not familiar, Google Apps Script
is all about doing more with Google Apps.
So it allows you to build integrations into Google Apps
such as Gmail, spreadsheets, sites, drive, Docs, and so on.
It allows you to send data back and forth.
It allows you to show UI.
So for instance, Apps Script allows you to inject menus
into a spreadsheet.
So it really allows you to build more with existing apps
technologies on The Cloud.
All the code that you write is all in JavaScript, so it's
super easy to pick up, and we have a bunch of APIs, and it
allows you write very quickly with all the samples we
provide as well.
And Adam, what is an Android all about?
Never heard of it.
Just kidding.
ADAM KOCH: Hopefully you've heard of Android.
It's a mobile phone operating system and, of course, many
Android apps actually connect with Cloud backends, right?
They connect to the internet, they pull down information.
So I think the neat thing about the demos that we're
going to show you today is, it sort of gives you a really
good way to sort of set up a backend, and get in touch with
the various Google Apps that Apps Script can talk to.
In addition, we're going to talk a bit about GCM, Google
Cloud Messaging, which is Android's push messaging
framework, which allows you send push messages from the
interwebs down to an Android device.
And the nice thing about the setup today, again, is that
you don't have to go and build a full fledged server
infrastructure to be able to play around with this and test
it and use it.
You can leverage Apps Script to actually do a lot of this.
So it's pretty cool stuff.
ARUN NAGARAJAN: Yeah, exciting!
So what we'll do is just a couple minutes to kind of
orient the crowd with what we're about to show, so we'll
just show a couple of slides real quick here on my laptop.
So the goal today is to showcase how Google Apps
Script can act as a backend system for Android apps.
Most apps often need to connect to some backend system
every now and then, whether it's registering a high score
or pulling down new data once a day, what have you.
So a lot of times, it may not be millions of users
connecting every day to a system, as much as just a few
users in a departmental app for instance, or maybe they're
just connecting once a week for updated data.
In those scenarios, Apps Script is really ideal to
build a simple lightweight backend system.
Obviously, we have systems like App Engine, which provide
sort of the large scale scalability that you may want,
but that also requires installing Eclipse and getting
SDKs, and pushing it to App Engine, using all the
different frameworks it provides.
It's a little bit more heavyweight, but you get the
benefits of it.
But Apps Script allows you to do things with spreadsheets,
so a lot of times spreadsheets might be sufficient for what
you're trying to achieve.
So if it's just a tabular data set with 10 columns and 40, 50
rows, maybe Apps Script is sufficient to get started with
the spreadsheet itself.
ContentService is the technology that we have that
allows you to build these web endpoints on top of a
spreadsheet, so we actually did a whole GDL on
ContentService.
Definitely check that out.
And, in fact, at that point, I mentioned the plug about
coming back to Android, and here we are.
And Apps Script actually allows you to take advantage
of external systems like GCM, Google Cloud Messaging.
The great thing about GCM is that it's just a web call.
It's not complex socket connections.
It's not complex APIs.
If you can make an HTP post, and you have the right
credentials, you are able to send GCM
message, which is great.
So we'll kind of showcase that today.
So back, I think, three or four months ago now, we demoed
how you could write a simple mobile app on iOS and connect
to a spreadsheet for data.
The example of that point we used was a
simple inventory app.
The scenario we painted was you are an IT support
technician or a help desk person and you're on the go
and you want to be able to check inventory of various
things that you may have at your tech stop or
your IT help desk.
So we'll just continue that scenario today.
And a lot of folks, I remember at that point, were commenting
saying where is my Android demo?
Now why are you showing iOS?
The good thing is that we're here and we're going to show a
lot more with Android, and we're going to enhance it to
even show push notifications.
So that's going to be really nice.
So there's going to be two demos.
So it's going to be two-part, and it's going to be cohesive.
It's going to be the same demo that we are going to carry on.
The first part we're going to show how you can take data
from a spreadsheet and showcase it on an Android
application using standard technologies
like REST and JSON.
In the second part, we're going to do something exciting
where we're going to actually take a change that's made on
the spreadsheet and then push that down
to the device itself.
Sound good?
ADAM KOCH: Sounds good to me.
ARUN NAGARAJAN: All right.
So I actually have this crazy, complicated diagram that will
explain towards the end, but I think it makes more sense once
you see the demos.
All right.
So let's go to our screen here, and I have a couple of
spreadsheets and stuff loaded up.
So here's the data set that we're going to use.
So a few items, some SKUs, and quantities, and colors, and
stuff like that.
So we're not going to mobilize all of these, we're just going
to mobilize a couple of columns and hopefully you'll
get the picture in how you can make that all available for
all the rows, and maybe even bi-directionally.
There's a bunch of exercises left of the viewers.
So let me showcase the code real quick.
So a lot of this is used right from the example that we had
back in January.
So if you go to my get GitHub page, there's a whole section
for ContentService.
We'll make all these links available right after.
Where you can see what it's doing, where it's lifting up a
spreadsheet, opening it by ID, and then getting a particular
range, that's a name range, and then it creates objects
out of those rows using some sample functions that we
provide, and then outputs that as a JSON string and the right
MIME type's up.
And this is the ContentService code that I was talking about.
I'm going to zoom in a little bit more so
that you can see that.
And I have that same code here.
And then what you can do is publish it as a web app.
So this is sort of the magic that makes it all work.
For now I'm not using an authentication, but with
Android, you can actually craft the response, and if
it's a challenged response, pop up a web view where
someone can authenticate as well.
For now, I'm going to keep it very simple and just using
some demo data here.
ADAM KOCH: I just want to comment there.
So when it comes to authentication, you can, of
course, pop up a web view and then ask them to
authenticate it.
We actually have a newer mechanism there on Android,
that you can also try and use.
It's called Google Play Services.
So that actually lets you use the system credentials that
are already available on the device to authenticate in.
So I haven't personally tried it with Docs and what not yet.
So I don't know how well it works or if it does work right
now, but it's definitely a good experience for the users
just because you don't have to go and enter all your
credentials again into a web view.
ARUN NAGARAJAN: You're right.
Totally.
Yeah, this is why we have Adam.
He's making sure that we're showing the right thing.
But yeah, that's a great exercise to try out and see if
you can actually achieve it using that for authentication.
And here's what the output looks like.
So this is the spreadsheet that we had, and you can see
it's just an array of JSON objects.
Nothing special.
No magic here.
You have a URL that redirects it to a temporary URL, which
then outputs all the JSON objects.
So that's essentially a spreadsheet
data turned into that.
So now let's--
ADAM KOCH: I have a quick question, sorry.
ARUN NAGARAJAN: Yes.
ADAM KOCH: I don't know that much about Apps Script.
To turn the spreadsheet cells into that JSON,
is it really trivial?
Or do you have to still go through each row and actually
change it into JSON?
ARUN NAGARAJAN: It's super trivial, because we have a
really good recipe to do that.
If you look at the code.
So this is copied and pasted right off of the
developer.google .com/apps-script page and it's
one of the very common ones that we do.
And what it does is actually reads the ranges into a bunch
of methods that normalizes the headers, makes the header,
names the object properties, and it does some basic checks.
Is it to run empty cells, is it alpha numeric,
and stuff like that.
So it is trivial because we've written all the code for you.
Obviously may want to change some of the logic, and that's
why it's not baked into the platform, and so we share some
recipes for you.
But yeah, so you can see that get rows data is basically
passing the sheet reference and then the range reference,
and then you get back objects, JavaScript objects, which you
can JSONify and then just spit it out.
So that's what makes it really easy is that you don't have to
iterate through all the cells.
No, we really ought to make this into a library, but it's
easy enough to copy paste for now and enough people have
small variances.
For instance, some people don't like to have the first
row as a header, all these little nuances.
So we figured it's just better to leave it as a sample that
people can tweak.
Good question, yeah.
Great.
So on the client side, it's a really simple app.
Let me zoom in a little bit here.
All I have is a simple layout with a couple of fields.
A list view, which has two fields, inventory name and
inventory count.
And then I am essentially making a quick call over the
Async Task Mechanism that we have on Android, which
frankly, I haven't programmed an Android for a long time and
this was actually really impressive how easy it was.
ADAM KOCH: Yeah, Async Task is useful for fetching little
pieces of information from the web like this.
Just a note to the Android dwellers out there, if you did
want to turn this into a more robust app, you would probably
run something like this Async in a background service, and
then sync it into like a database of sorts, maybe a
content provider, and that way you could display a list view
based on the content provider or database instead.
But this is really good for demonstration purposes, and as
you say, it's really nice and particularly easy to get up
and running.
ARUN NAGARAJAN: Yeah, and also their built-in functionality
to be able to turn a response into a JSON array or object.
And I'm just iterating through that and then just showing
them the UI.
And I have a simple adapter here that essentially take
those row layout views, and then just sets the text to the
appropriate object, in this case, item.name and
item.count.
So real simple code, didn't really do anything fancy here.
I'm more of a backend developer anyway.
So let's go to the phone here and then see
what this looks like.
So I have an app here called Apps Script GDL.
I'll share the code as well.
And there it is.
So we were able to take the data from the spreadsheet, the
inventory objects, Chromebook, I have nine counts of it,
headphones, I have five counts of it and so on.
This is all real time.
So if I go into my spreadsheet now--
let me zoom out here--
so here's my spreadsheet on my computer and I'm able to go
and change let's say I just dropped off a Chromebook to
someone, I change it to eight, and then I picked up some new
speakers, let's change that to four.
So I change two things I can just go here--
ADAM KOCH: Wait until--
ARUN NAGARAJAN: I can go in here and hit refresh, and
that's just going to go talk to the server again.
And that's going to take a second and hopefully--
ADAM KOCH: If the WiFi connects.
ARUN NAGARAJAN: Stay with the WiFi.
ADAM KOCH: Come on, WiFi.
ARUN NAGARAJAN: Did the WiFi drop off?
ADAM KOCH: It's weak.
ARUN NAGARAJAN: It's weak, for sure.
Oh, something's going on.
Let me say refresh again.
If that doesn't work, I'll come back to this.
ADAM KOCH: Come on, demo gods.
ARUN NAGARAJAN: Yeah.
We've got to always be nervous about the demo gods.
All right, so let me just kill this and then see if that
makes a difference.
All right.
Click on that.
So it's going to go talk to the server, and hopefully
it'll download the right count, which should
say eight and four.
Hmm.
Not happy with the WiFi here.
Did I change something with the application now?
It should be all published.
Let's see what's going on here.
All right.
I'll just check to see if the internet is working or if it's
my app that's broken.
I'll go to google.com.
No, the WiFi is giving me some trouble.
ADAM KOCH: Now, let me set up a--
ARUN NAGARAJAN: All right.
So what that should show is the updated data.
Let me see if I have my other phone.
ADAM KOCH: One thing you do need is a network connection.
to get this.
ARUN NAGARAJAN: The one thing you definitely need is a
network connection.
ADAM KOCH: It's very helpful.
ARUN NAGARAJAN: Let me see if I have another phone that I
can pull up here real quick.
I apologize for that.
Let's see here.
I'll pull my personal phone here.
Hopefully I will get no calls or anything on this.
All right.
Let me see.
Here it is.
ADAM KOCH: I'll quickly trade with this thing.
ARUN NAGARAJAN: So this should load and there it is.
So that worked.
I'll leave this here.
I'll just use my phone for the time being.
Let me actually do a quick test again.
Go back to my computer to see if this picks up.
So let's change the real count from Chromebook to six to
eight, and then I'll say refresh data and it updated.
So a lot faster this time.
So we'll stick with my phone for the demo, and hopefully
WiFi will get better with the other phone here.
So the process there was actually fairly
straightforward.
All we did was refetch the data and
repaint the list view.
Nothing fancy, but you kind of can see the point of--
in a spreadsheet, you have a natural user interface, you're
able to make quick changes, and then since it's all
serving from the spreadsheet itself, the ContentService,
it's immediately reflected on the device whenever you make a
quick call, right?
So that's actually super powerful in that it's not
something that you have to synchronize, it's just
refreshing.
It picks up.
But what if there are other scenarios where you want to
notify the end user when a change happens?
So that's really where the second part of the demo comes
into place, and that's what we call Google Cloud Messaging,
and it's something that we announced a year
ago, two years ago?
ADAM KOCH: Yeah, I believe last year, we
announced it, yeah.
It was a replacement to the original push
framework, which was C2DM.
ARUN NAGARAJAN: That's right, yeah.
And one of the nice things I like about it is that it's
super straightforward to get started.
It didn't require me to know a lot of server technologies
specific to Google, it was just standard post and
standard post body that came in that I was able to handle
in Apps Script itself.
So, in fact, for this the documentation is actually
really robust.
So if you go to, I believe, developer.androi
d.com/google/GCM, there's a wealth of content there about
how you can get started.
The first thing you have to keep in mind is that you have
to create a Google API project for this, and it's actually
straightforward.
I've created one and I'm using a demo key that I'll show you,
but you'll have to create your own.
I'll disable the key right after this demo.
So there's a couple of things that you have to be careful
about from a process standpoint.
There's something about the project ID you
need to save as well.
So once you create this project, there's two pieces of
information that you need to grab onto, the API key and the
project ID.
And, in fact, what I've done is you'll see a lot of
similarities with the demo application and the UI that
I'm showing, and that's because I've taken the demo
application as my basic framework.
So I've kind of built everything around it.
And the demo application actually talks quite a bit
about the server side of it.
So in this it talks about how to run a Java server to
achieve the push registry, and then also to
send the push messages.
And also shows you how you can run that on App Engine.
And the ideas is that all of this is
possible in Apps Script.
So you can build a simple automated server in Apps
Script itself.
ADAM KOCH: Yeah, and the interesting thing is, like
when I've run through this before, personally, I find the
server piece takes me the longest, just because I'm
really bad at that kind of stuff, like getting App Engine
set up and getting it working correctly the way I want.
And that's why I think this is really a nice way to sort of
get up and running on GCM quickly using Apps Script.
ARUN NAGARAJAN: Yep, and that's great.
So I'll just show the demo and hopefully this time around,
things will--
ADAM KOCH: I put this on, tethered to my phone, so maybe
it'll work.
We can try both.
Whichever has the best WiFi.
ARUN NAGARAJAN: This one has it.
All right.
Let's go back to this guy.
It's a better WiFi situation here.
ADAM KOCH: Potentially.
ARUN NAGARAJAN: Potentially.
All right.
So let's give it a shot.
So you can see that the data is back to what the other
device was showing, which is Chromebook at six and speakers
at four and so on.
And what we're going to do is I'll just show the demo first,
and then we'll explain all the different moving pieces,
because there's quite a few.
I could've simplified this into one single, big Apps
Script project, but I kept the different separated so that
it's easier to explain and then potentially for you to
optimize and clean up.
So let me go back to my spreadsheet, here.
And if you go to Tools, Script Editor, one of the things
you'll see here is this call for send notification.
So a spreadsheet has this concept of associated script,
which can have a lot of interesting things about the
spreadsheet exposing to the script.
So events, you'd be able to inject menus into the script
itself, and a whole slew of things in between.
So I just went to Tools and Script Editor.
I already kind of seeded the code here, but this is, as you
can see, very straightforward code to do.
I'm referencing something called
SharedDb, which is a library.
And you can find these under Resources, Manage libraries.
And I will show you where this library is defined and why I
have it as a library in a bit.
And all I'm doing is saying send GCM, and I'm just saying
something was edited.
And right now, I'll have to manually run this.
And what I'll do is now turn this into a trigger.
So I can say send notification is the function that I want to
run from the spreadsheet, as far as events go, on the on
edit function.
All right?
So I'm going to hit save.
And that's really it.
That registers a an event, a trigger associated with the on
edit event.
So I'm going to go in here--
ADAM KOCH: Just so I get this right, whenever you make any
edit to the spreadsheet now, that trigger will run?
ARUN NAGARAJAN: Yep, exactly.
And then each user can register a trigger for
themselves.
In this case, I've done it for me as my demo account, but
there's ways you can make this a much more
broader base as well.
So I'm going to change this Chromebook.
I've decided to deploy Chrome Pixels to everybody.
I'm making that change.
And then I don't know if you caught that.
That was actually too quick.
ADAM KOCH: Better change something again.
ARUN NAGARAJAN: I'll change something again.
So my hand's on the monitor and I'll make it 101
Chromebooks.
I'm going to tab off, and then you can see that, right on my
device, there's a notification first, and then the UI knows
to refresh itself and pick up the new count as well.
And it also, since it's the Android notifications, UI is
actually quite nice.
It injects itself into the--
what's it called?
The notification panel?
Is that the right term for it?
ADAM KOCH: Yeah, it's the notification panel.
ARUN NAGARAJAN: And I remember at I/O last year, we unveiled
a really nice look and feel for this as
well, so I can actually--
ADAM KOCH: It kind of expanded notification and included
additional information in those notifications.
ARUN NAGARAJAN: Yep, and for now I'm just showing a very
basic set of things in there.
And one of the nice things about GCM is that the app
doesn't have to be running.
So I could actually have the app killed, whereas I could
minimize this and swipe it out.
And if I make a change here, let's just say I have given
out 10 of my Chromebooks and I'm down to 91.
I hit tab off and that is, as you can see, it beeps and the
notification comes in, and I think it took
all of three seconds.
And I can then go tap on it, and then that will come back
up, and it should reflect the right data now, 91.
So that's GCM in a nutshell, and the whole idea is that the
end user doesn't have to go in and say refresh, or check
every day and be worried about whether they have the right
data or not.
And this, combined with the offline capabilities of
Android applications, you could actually have a pretty
nicely set up app where it only checks for updates when
there's new data available, rather
than constantly checking.
Or the user worried about saying, hey,
is there new data?
ADAM KOCH: Of course, the other option is to have like
every five minutes, check the server.
That's going to drain the user's battery.
It's not a great experience.
It's going to take up extra CPU and battery.
So this is just really nice.
If there's no changes, it's not going to refresh at all.
ARUN NAGARAJAN: That's right.
And that's really nice in allowing just saving data as
well, because that's expensive around the world, here.
ADAM KOCH: Yeah, one quick note.
So right now, we're sending a ping down to the device which
just says, hey, there's new data, why
don't you go and refresh?
But GCM also supports sending actual payload in
the message as well.
I think it's up to a four kilobyte payload.
So if your message is small enough, and you have the right
setup, you can actually send the entire amount of data,
changed data, in the payload as well.
And that way, it doesn't even need to go and refresh.
It can just automatically use the information that was sent
down from GCM.
ARUN NAGARAJAN: That's a really good point, because
what I could've done here is, instead of send message, I
could have just [INAUDIBLE]
the objects and sent it right down.
So that's actually something--
ADAM KOCH: It's a little bit more complicated, because say
the data is really large there, and you want to send
the delta, but it's definitely possible and it's definitely a
really, really neat feature.
ARUN NAGARAJAN: Yeah, for sure.
So now let's take a step back and see how this all is
connected and how it all works.
So this is a script that's associated with the
spreadsheet.
So all this is there for is to detect changes, and then to
delegate that off to the actual system that's sending
out the push messages.
And that's in a project called SharedDb, and I'm referencing
that by this concept called library.
And all of this is documented on our website, and I'll make
sure this is shared out from a code standpoint as well.
And here's my SharedDb project, and all this is doing
is it provides a unified data store that can be shared
across multiple projects.
It's not possible to share data store
today between projects.
And the way you do it is by sharing library, because that
is a lot easier to control access to and it's provided
manually by the developer, so it's actually a little bit
more flexible, even though sometimes it could be a little
bit painful.
And then here's the function that basically says send GCM,
and it just defaults it to Hello World if nothing is
passed in, and it's all pure JavaScript here.
So this is not any new syntax or anything like
that you have to learn.
So Db is our data store.
It's a product called ScriptDb and that's something that we
launched last year at I/O and it allows you to store
JavaScript objects as is into a database, and
then query them back.
So what I'm checking here to see is give me all the records
in the system that has a registration ID.
And then I'm just tracking them all into
a JavaScript array.
And then I have my API key here, which I'll destroyed
after this demo.
And then here are the URL Fetch options that I have.
URL Fetch is basically our--
and I think App Engine calls it the same thing, in fact--
allows you to make outbound connections from the Google
data centers to, in this case, also a Google data center
running GCM.
So all this code is running on different parts of the Google
data center, if you can think about it that way.
And then that's it.
It just takes this and then sends it.
I can actually send it to multiple
systems, multiple devices.
So if I have multiple devices registered against the same
GCM registrar, I can send one call with an array of
registration IDs, and they'll all get notified.
So you don't have to make an individual call for every
device, which is actually, I think, one of the benefits of
GCM as well.
ADAM KOCH: Yeah, that was one of the new things added, I
guess batching calls in GCM versus the older C2DM.
And that's nice because I don't know if this particular
app would have a million users, but say an app had a
million users, you can batch up and update all those
devices with one push message.
ARUN NAGARAJAN: Yeah, that's actually something that is,
even for testing purposes, reducing the call volume for
my code, is a nice thing.
So this is a shared library.
How does data get into this data store?
Because we haven't shown how we have collected the device
IDs, the registration IDs as it's called here.
So for that, I have another endpoint.
In this case, I'm just calling it GCM, and this registers a
do post handler, which essentially gets called when
the client makes a call for post.
I also have a do get, which I'm using for some debugging
purposes to show the UI of what's in here.
And it basically says if the device wants to be
unregistered, remove that record.
If it's not there and the type is register,
just store that record.
E.parameter is basically the JSON object.
And that's it.
This is how we're registering and unregistering users, and
there's actually a simple UI for this.
I'll refresh this to clean this up.
This is a ScriptDb visualization console that I
discussed a little while back in one of the GDLs, and you
essentially enter a query.
Empty brackets mean everything.
I can just run query and see what's in the data store.
So in this case, there are two different registration IDs for
the two devices that I've done.
So if I go back to my phone here, and I go and say
unregister, and that's going to make a call
to unregister hopefully.
Maybe it's not working.
Oh, there it goes.
It's making a call to unregister and it says
successfully removed.
It's tiny font.
I apologize.
And then if I go back to my system here and say run query,
so you'll see a new line pop up, and then it should only
return one record.
So you can see that there's only one record now, and these
are the two records from the prior query.
So this record, 940, is gone because the user said I don't
want any more messages from the system and it's our
responsibility to get rid of that registration record.
If the user wants it again, they can register again.
And all of this, of course, is running on the Google Cloud,
which is great.
So the system where registration IDs are stored is
in the Google Cloud, the data source itself, which is a
spreadsheet, is in the Google Cloud, and GCM, of course, is
Google Cloud Messaging, is routing via that.
So it's actually great to be able to just copy, paste and
code into a Script Editor.
I think I mentioned briefly that it's all done in the
browser, but here's the Script Editor.
It looks and feels like a simplified IDE.
And you can just punch in some JavaScript
code and off you go.
In this case, the notification is on every edit, but here's
where you can put in your business logic.
You could say only notify me between work hours, or only
notify me if something exceeds a threshold, and so on.
So you can actually build some interesting business processes
around this.
So with that let me actually go back and just show you the
diagram that I said I will show in a little bit.
I think this will help kind of see how everything kind of
came together.
So the top part of the diagram is actually real
straightforward.
An Android device making an HTP call to get data against
the ContentService, which returns JSON from the
spreadsheet.
So this is really straightforward.
Something that makes sense.
And that's our little icon for Apps Script.
And then the bottom half is the much more complicated one,
because there are a lot of moving pieces.
The first part is the GCM, the Google
Cloud Messaging component.
The native application is expected to make a
registration call against the GCM and a server, and the
server gets what's called the registration ID.
The registration ID is stored into a shared data store,
which is also responsible for sending out the push messages.
There's also console view to see all active
registration IDs.
And then here's a little component that tracks changes
and then queues up messages against the data store, which
then sends it out to the GCM component, which then notifies
the device.
So a lot of different moving pieces.
Hopefully this diagram kind of brought it all together.
But the idea is that this whole box here, this little
gray box, is all in the Google Cloud, as far as applications,
logic, and even some of the messaging components go as
your applications are concerned.
And the client side code is, like I said, straight
from the GCM demo.
So if you just go to this page and then download the client
and the server code, just look at the client code, and then
everywhere there's an App Engine URL, replace that with
the URL for your application.
To show you that in action, you can see that the server
URL is script.google.com URL, instead of my host or some
other local server or App Engine server, so certainly
it's not a big delta change, as far as how things work.
One other change that I had to make here was in the server
utilities code.
Apps Script doesn't allow for paths on your web application,
so you cannot have /register, so I kind of commented it out
and just have a type in the URL, in the post body, that
tells me what I'm trying to achieve.
So it's something that you should keep in mind instead of
App Engine allows you have slash whatever, slash my
particular path.
With Apps Script, there's no router and everything kind of
goes in via one endpoint, the do post or the do get endpoint
and you have to, through parameters, decide which way
you want to go.
And unregister is very similar as well.
The same URL with the type of unregister.
So that's really all we wanted to show.
All the code will be shared.
Certainly we are very excited to see what you
can build with it.
I think there's a lot of interesting use cases that,
just showing it off internally to some folks here they've
thought of, allows you to use Google Apps as their
spreadsheets, and maybe even Docs and Gmail, of course, all
of that as a data source for your Android applications.
Anything that I missed, Adam?
ADAM KOCH: Not really.
I guess one question for you is how does
this kind of scale?
Like when making the do get and do post, are they quotas
or can people go and make as many calls as they want?
ARUN NAGARAJAN: Yeah, so there are quotas.
Our quotas are described in our Dashboard.
So I'll just pull that up real quick.
That's a really good question.
Apps Script is not a platform with which you'll build a
business by itself.
So there's definitely quotas.
This is a free version, so if you have a Gmail account you
can start using this.
So if I go to Other and then go to Dashboard and quotas and
go to quota limits, you'll see a lot of the quota are
described here.
And there's a bunch of information about URL Fetch
and web applications as well.
And this is something they you can track around what are you
doing with the application and is Apps Script going to be the
right fit for you?
But in general, if you're only using it for a few dozen
users, or if you're not abusing it in any crazy way,
and you're not trying to build millions of user application
installs, I think it's going to be fine.
But there's definitely a fine line between do I want to
control the whole platform in something like App Engine,
where you have a lot more control and you can pay for
more scale.
With Apps Script, there's a free quota that anyone can
build with and test with, and then you can graduate to the
Google Apps for Business version, but even that is
capped at a certain limit.
So you'll want to be a little careful if you are planning to
build the next Angry Birds or something like that, yes.
ADAM KOCH: And one thing I just really like about this,
though, is sort of rapid prototyping.
I mean, you can't beat this really, when you just want to
get up and try out GCM or something like that.
See how it works and maybe create some proof of concepts
and what not.
ARUN NAGARAJAN: And someone also gave me a really good
idea where this may not be right for data, but maybe for
configuration settings that you can cache for a long
period of time and then only manually fetch against the
spreadsheet.
So maybe colors, maybe labels, things like that, that you may
want to tuck away under a debug flag or something like
that, that only certain people can get at.
Maybe that's a good way for you to use this as well, where
the spreadsheet gives you such a simple interface where you
can change things, add things very quickly.
Even use the Google form to populate into it, so it allows
you to build these administrative tools as well.
So not just for data, but maybe for some certain
configuration settings.
So that's all I had.
Sorry the demo had some issues early on, but hopefully you
saw the whole thing, end to end.
And thank you very much, Adam, for joining us.
ADAM KOCH: Thanks for having me.
That's really, really interesting stuff.
Really cool.
ARUN NAGARAJAN: Thank you very much, and we'll share the code
with you, and looking forward to what you can do with this.
ADAM KOCH: See you guys.
Bye.
[MUSIC PLAYING]