Script It! with Android


[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]

10 thoughts on “Script It! with Android

Leave a Reply

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