Chrome Apps Office Hours: Building awesome multi-window apps

Uploaded by GoogleDevelopers on 02.10.2012


Welcome to "Two Pauls in a Pod" show.
We wanted to say this.
I'm Paul Kinlan.
PAUL LEWIS: I'm Paul Lewis.
You nearly forgot who you were there for a second?
PAUL LEWIS: No, well, I didn't know if you were going to
carry on talking.
I thought it'd be better if I just jumped
in there, you know?
PAUL KINLAN: Yeah, I got you.
OK, so yeah, he's Paul Lewis.
I'm Paul Kinlan.
I'm a developer advocate.
You're a programming engineer.
PAUL KINLAN: We're working on the Chrome apps initiative.
We're based in London in a really small room.
We have an awesome producer, Mark Lunney, who's completely
off screen at the moment.
But I just thought I'd try and embarrass
him live on the stage.
I like how you said that we're in this little room in London.
It makes it sound like that's where we live.
PAUL LEWIS: Yeah, it's not really full-time
two Pauls in a pod.
It could be, though.
That'd be weird.
PAUL KINLAN: I wouldn't mind.
PAUL LEWIS: Well, yeah.
PAUL KINLAN: On that note--
PAUL LEWIS: Let's carry on.
PAUL KINLAN: On that note, let's carry on.
So today's episode is about the Chrome
apps window in APIs.
Chrome apps is a new platform that we're
building into Chrome.
It's not yet in Stable.
It's in Canary and Developer channel.
But we believe it's going to give you the ability to build
great web applications in the future, applications that can
do way more than a traditional web application could do.
So we can access network, UDP, TCP, all
those types of things.
But the thing that we want to try and do is tell you how you
can build great applications which use multiple windows.
PAUL KINLAN: I think on the web today we don't really have
that many applications that use multiple windows.
PAUL KINLAN: Mostly single-page web applications.
PAUL LEWIS: Well, I think, taking a step back, we're used
to pop-up blockers and things because multiple windows or
pop-ups or whatever have been a bit of a nuisance.
PAUL LEWIS: So because we're in the Chrome apps
environment, we're actually able to kind of reassess that
and say, well, actually, multi-windows make sense for
certain applications when you say you've got panels to the
side of your main view or whatever.
So I guess that's where it kind of comes from.
PAUL KINLAN: It's things like-- you
know Photoshop, right?
PAUL KINLAN: People expect like a tools
pop-up out to the side.
PAUL LEWIS: Yeah, that's right.
PAUL KINLAN: You have multiple image windows and all that
type of stuff.
How would you build an application that orchestrates
actions between them?
PAUL KINLAN: I would just like to add before we get into the
code, Paul's going to show you some really cool demos and
everything like that.
One is we have down below.
We're trying it.
Well, Paul's got it completely wrong.
But right down below, we have--
PAUL LEWIS: I have not.
It's over there, right?
There it is.
PAUL KINLAN: There it is.
PAUL LEWIS: Hey, I was just pointing to the bottom.
PAUL KINLAN: We would like your questions, right?
We want to basically answer as many questions as possible
during this session, just so we can provide you with the
best guidance possible.
So if you check our Google link, you'll go straight to
our Moderator page.
And you'll be able to vote on questions that you like, down
vote some that you don't like.
We only have one question so far.
So I'm expecting at least 10 today.
But yeah, just get asking questions.
We also have our colleague in Brazil, Renato.
"Henato," I think, is the proper way of pronouncing it.
PAUL LEWIS: I stand corrected.
PAUL KINLAN: Anyway, he'll be moderating some of the
questions as well as any of the YouTube questions and all
those types of things.
But please feel free.
This is a live show unless you're watching this tomorrow.
PAUL LEWIS: In which case, it's not
Google Developers Live.
It's Google Developers recorded.
PAUL KINLAN: But we'll answer as many
questions as we can today.
And if we can't answer them, we'll try and roll them over
to next week's episode.
PAUL LEWIS: All right.
Should we go into some code?
What editor do you use, by the way?
PAUL LEWIS: I use Sublime Text.
PAUL KINLAN: Sublime Text.
PAUL LEWIS: Everytime we get asked that-- there we go.
That's the one.
It's the one.
You use Vim, do you not?
PAUL KINLAN: I'm a Vim man.
PAUL LEWIS: You're a Vim improved man.
PAUL KINLAN: I used to like VIM until the drink.
That's how it kind of--
You didn't choose your interests based on the drink
that you liked as a child?
I'm glad we had that conversation.
PAUL KINLAN: So I always say that I'm preparing a joke
every single episode.
PAUL LEWIS: Every time.
PAUL KINLAN: This one has been a couple of
weeks in the planning.

All right.
Let's get going.
PAUL LEWIS: So sorry.
PAUL KINLAN: Sorry about this.
Let's look at the code.
PAUL LEWIS: Yeah, let's do it. .
So I have the code up on screen.
Now what I've done is I've taken the liberty of actually
starting the app ahead of time.
So there's a lot of stuff that we've covered in previous
weeks about boilerplating, getting up to speed with some
code and all the rest of it.
So I didn't want to repeat that.
You can find those in the samples on GitHub, And you can
also watch previous weeks.
So I'm in the main JS, which is the background page.
This is the hub of your apps activity.
And as you can see, I'm actually
creating three windows.
So I'm actually creating three of them with
index.html as the source.
And then I'm just positioning them across the screen.
And they're identical apart from the fact that I'm pushing
on variables.
Now, the way to talk to a window.
So the window that gets passed back as this in the callback
function is an app window, which isn't the same as the
DOM window that you're used to dealing with.
So we actually access the DOM window inside the app window
using the content window property.
There you go.
That's a fun way of explaining it.
PAUL KINLAN: So we can't really do this in the web
today, right?
PAUL LEWIS: No, not that I know of.
PAUL KINLAN: Well, we can do it with iFrames.
But it's--
PAUL LEWIS: It's a bit weird.
It's not a generally well-accepted way of--
So you can see what I'm doing, though, is I'm getting the
window passed back as a part where the callback.
I'm accessing content window, which gets me into the DOM of
the window that I created.
Then I'm setting this window name property on there.
And I'm obviously calling one Left, one Mid, and one Right.
And the last thing I'm doing is I'm actually pushing it
onto an array of wins, which is basically what I'm going to
do or what I'm going to use later on to actually talk to
the window.
So let me just show you what this looks like right now.
There we are.
The windows, they're all the same.
Left, mid, and right, although you can't really tell that
it's Left, Mid and Right, particularly.
They just say Window.
So the first thing that I wanted to actually do is in
the source of index.html, you'll see the markup for what
I just showed you, which is this sort of the window, the
form, and an output area, and an index.js file.
Now, what we want to do in this app if we can is have a
setup where if I type a message in here and say hello
and submit it, that it actually does something.
That it actually takes that message and puts it into the
current window that I'm looking at, but it also shows
it up in the other two windows, kind of, I suppose,
like a chat kind of mechanism, I suppose.
So the first thing I want to actually do is I want to pick
up the injected variable.
Let me just find that over here.
So the injected property name-- property, sorry--
window name.
I want to pick that up inside that window.
And I want to use it to set the title.
So you can see I have in the markup a span inside the H1
called title.
What I want to do in here-- as you can see, I've also picked
it up in the JavaScript.
So what I'm actually going to do is say title.textContent
equals this-- because this is going to refer
to the window object--
So that's the variable I injected.
So now if I reload the application, hopefully, Window
Left, Window Mid, Window Right.
So this is the first kind of way of
dealing with this stuff.
You can actually inject variables into your Windows.
PAUL KINLAN: I think we talked briefly about this last week,
didn't we, with Intent data, but We didn't really allude to
what was happening.
PAUL KINLAN: Last week's talk was about Web Intents Oh,
we're on camera!
PAUL LEWIS: We're back.
PAUL KINLAN: So last week was about Web Intents and how to
deliver data between windows.
And this is the same type of way, isn't it?
PAUL LEWIS: Absolutely.
You just push that right in.
And I think that is a bit unusual for web developers
from that typical web development background is to
just kind of inject things.
And certainly what I'm going to show you in a little bit is
using post message as well, which is a lot more, I think,
what people are used to.
You can do it either way.
So that's the thing.
So it's really done to you as to how you want to do this.
So back to the code.
The main thing we need to do here is sending messages.
And what I'm going to do is I'm actually going to send--
when you submit the form on one of those windows, I'm
going to take that input, and I'm going to pass it to the
background page.
And then the background page is going to send that message
out to all the windows.
So the background page, as I said before, is
acting as the hub.
So everything goes via the background page.
And that's the model that I think you need to get used to
if you're going to make Chrome apps.
So the first thing I need to do because form submission is
not accepted.
It's not something that we support in the Chrome Apps.
I need to say the event-- because you can see I've got a
form submission event.
I'm going to say event.prevent default.
So that's going to stop the form from
actually being submitted.
But it does mean that I capture the fact that they've
submitted the form.
PAUL KINLAN: I have a quick question.
PAUL LEWIS: Go for it.
PAUL KINLAN: Are you a tabs guy or a spaces guy?
PAUL LEWIS: I'm a spaces guy.
PAUL LEWIS: But each to their own, you know?

It's a personal preference thing, isn't it?
So the thing I want to do is I want to say--
let me just do this.
If I've got the background page, and I want to call a
function on the background page called broadcast, and I'm
going to say this.windowname, and then whatever was in the
box at the time.
And then I'm going to set whatever was
in the box to nothing.
So there's a couple of things here.
The background page is currently set to null, so I
don't actually have a reference to the page.
Now you could use window.opener as one option.
But because there's actually something built into the
Chrome runtime, which we can use.
So we're going to do that instead.
We're going to actually do--
let me see, now.
Chrome.runtime.g etBackgroundPage.

PAUL KINLAN: Should we explain a little bit more about the
background page?
PAUL LEWIS: Well, the background page, as we said a
couple of times, is the hub.
PAUL KINLAN: That shows me listening, doesn't it?
PAUL LEWIS: It does rather.
PAUL KINLAN: But does the background
page always live there?
Or does it die at any point in the application?
PAUL LEWIS: Well, it can get suspended.
But typically, it's there all the time.
PAUL KINLAN: Yeah, so it's a good, little
hub, as you were saying.
PAUL LEWIS: It is a good little hub.
So because the getBackgroundPage takes a
callback function.
I have passed that in there, as you can see.
And what I'm going to do is I'm going to use
backgroundPage equals page.
So I'm going to set that given whatever I've got returned.
So hopefully now, by the time sendMessage is running, we
have BackgroundPage in place.
Now, the problem is we're calling broadcast and we don't
have that function in there.
So we better go ahead and add that.
Now, this is where I'm actually going to use
postMessage to talk to the window.
So I've got this message being picked up.
I'm sending it to the background page and saying can
you broadcast this to all the other windows?
So in main JS, which is my background page, I just throw
in a function called broadcast.
And I'm going to have it take a message.
And then I'm going to go through all of the windows
that I put onto that array before.
Views less than wins, length, go through all windows.
I always write my four loops like that.
Some people write some very, very crazy four loops.
So Eric Bidelman showed me a way that we don't have to use
the length property, but it auto assigns
wins to a win object.
PAUL LEWIS: Oh, I like this.
PAUL KINLAN: --a while ago.
Yeah, I'd never seen that before.
PAUL KINLAN: Again, each to his own.
He's super nice, actually.
He's pretty cool.
PAUL LEWIS: Oh, I'll have to ask him about that.
So as you remember from before, I was actually pushing
on the app window.
I was pushing the app window reference onto the array.
I could have pushed on the content window, the
actual DOM window on.
But I didn't.
So I have to reference it via content window now.
And I'm just gonna say postMessage.
And I'm just going to pass in the message.
And then the second part is about the origin.
So you can check that one if you've not come across that
one before.
So I'm posting the message through to each of the
windows, in turn.
So the last thing that needs to actually happen is, back in
my index JS, you'll see I've got this receiveMessage.
So I've added onto this particular window each of
those three windows.
I've added on an event listener for message.
When we get a message in, we run this
receiveMessage callback.
So that's going to take an event.
And I'm going to say output, which if you remember, is this
text area over here.
So I've got a text area on the page.
I'm going to say output.textContent plus equals
the data, and then a new line just to keep
things nice and neat.
So hopefully, all being well, unless I've made a mistake
somewhere, when we re-load the application, I can say hello.
And you see that Left is now saying hello to
Left, Mid, and Right.
And go in here and say world.
And the Window Right is going to chime in with no--
So there you go.
So that's the way that you can actually have windows
As we said, it always goes via the background page.
That is, that you need to treat that as a whole.
So again, just a quick run-through.
When we send a message, in this case, we're just calling
a function on the background page.
But again, you could post a message through if that was
your preferred method of doing it.
In this case, I just decided to call a function on the
background page.
In there, I'm actually then picking that up and finding
each of the individual windows and posting a
message through to them.
And then when they get our message, they just simply
append it to the text area.
So that's kind of the way all this works.
Obviously, we're covering getting hold of
the background page.
And that is that.
PAUL KINLAN: I have one question to say.
The actual Moderator questions,
I set this up wrong.
I've been disabled.
So I'm actually just working on this whole process now.
Um, yeah.
So presumably, people can't ask questions right now.
PAUL KINLAN: People can't ask questions right now.
PAUL LEWIS: We'd like them to, though.
PAUL KINLAN: I did try to enable it.
I just got rid of the deadline, so yeah,
it should be there.
It's not quite.
PAUL LEWIS: Well, sorry about this, folks.
PAUL KINLAN: Yeah, sorry about this.

PAUL LEWIS: Not to worry.
PAUL KINLAN: It should be there.
I mean, you guys, you should be able to submit questions.
If not, I'm actually monitoring the
actual event as well.
We mainly have--
yeah, that's pretty much it.
PAUL LEWIS: Any changes this week in Chrome Apps?
PAUL KINLAN: There are no changes.
PAUL KINLAN: Well, there are changes.
There've been quite a lot of changes.
But generally, what normally happens each week is that we
try and give you a breakdown of breaking changes, things
that have kind of happened inside the APIs where you have
to change your code.
This week, especially around the window in API, there is no
changes of note, at least.

All your apps should work.
I think what we're going to do for the next couple of
episodes at least is start demonstrating more real-world
We have a couple on GitHub.
So we're not going to go directly into the APIs and do
this kind of conversation anymore.
Well, we will.
We'll have conversations.
And we'll have Moderator questions that work.
I apologize about this profusely, profusely.
PAUL KINLAN: But there have been no changes this week.
There might be some next week.
We don't quite know.
But we'll let you know.
PAUL LEWIS: But generally, actually if you want us to
cover anything specifically alongside the apps that we're
going to take a deep dive into, just let us know.
You can do that in the Moderator when it works.
Or you can post to the comments on Google+.
Or you can tweet in our general direction as well.
PAUL KINLAN: So we do have some things coming through.
Oh, thanks, the questions are up.
So Hemanna--
I hope I've pronounced your name right.
If you have any questions, please submit them.
We have also a question from Josh Libby,
which I believe I answered.
There is no captioning on live content.
So what happens at the end of this, we'll produce it and
publish it, push it live onto YouTube, where there will be
some automatic transcription and transcription of the show.
PAUL LEWIS: Of the video.
PAUL KINLAN: It's pretty cool.
They can translate Scouse and Burnley.
PAUL LEWIS: Burnley.
PAUL LEWIS: In case anybody from outside the United
Kingdom is watching, which I'm sure you are, I'm from an area
called Burnley, which is the source of his
mockery, which is good.
PAUL KINLAN: I wasn't mockering.
PAUL LEWIS: Why not?
PAUL KINLAN: Mockering?
PAUL LEWIS: Mockering.
PAUL KINLAN: I can't even speak.
So anyway--
A good question is--
PAUL KINLAN: I actually wanted to ask some questions to you
about patterns and practices for multi-window applications.
PAUL KINLAN: So you showed basically calling the method
directly on the background page.
PAUL KINLAN: Would you use that over post message?
PAUL LEWIS: I think it depends on the application.
I have no strong feelings.

For me, personally, I'm very used to the web developer kind
of methodology of decoupling.
And for me to some degree, it's a change in mindset.
There's a lot of change in mindset that are required for
Chrome Apps.
And I think this is one of them.
I'm sort of making my peace with the fact that I have
control over these windows.
I should expect them to be there because I'm
in control of that.
I'm not expecting pop-up blockers to get in the way and
those kinds of things.
I'm OK with it.
I don't think there's any particular problem there.
It is a different model.
And if you were building a native application on the
platform, it would be weird to not be able to just kind of
hook directly in and talk to it.
So I'm OK with it, yeah.
I'm just curious.
Because I've seen this thing before, where we've had like
magic iFrames, which if you look for documentation about
what a magic iFrame is--
PAUL LEWIS: I don't know what it is.
PAUL KINLAN: It's magic.
PAUL KINLAN: So basically, the idea was that you want to have
one piece of logic, like the background page inside these
applications, live inside your web app.
And say it was a new mail application that you had, and
you opened it up to run your email.
You don't want the cold start time of that new window to be
horrendously long.
You want all the code to be there straightaway.
And when you were showing that, you were basically
calling and passing in methods and data into a newly opened
window, I think it was kind of a similar thing where
basically you would say this is my background page.
Push it onto this new window.
PAUL LEWIS: Ah, so you're smooshing in.
PAUL KINLAN: Yeah, you're kind of smooshing in
all the logic, basically.
PAUL LEWIS: Like as sort of a primer or starter thing, like
go with this, right?
PAUL KINLAN: And that was basically designed to get rid
of that kind of massive overhead of download and
assets and everything, which doesn't necessarily apply
here, but we now have a centralized
resource for app logic.
And I think that actually brings onto--
the question from Hemanna HM from Bangalore.
"Is NVC dead?
Should we move on?"
PAUL KINLAN: No, I think it's more relevant and applicable
to these types of applications.
PAUL LEWIS: Yeah, absolutely.
I mean, you can inject controllers into these.
You could have a central controller and then treat
these as views.
So we were talking about this the other day, weren't we?
PAUL KINLAN: Where we were basically saying that the
traditional model for web applications is to build a
single-page application and manage the views inside that.
And we're not saying that this is ever going to go away.
We're saying that you have the ability to basically go
outside the normal single page app and have multiple windows
and do tool pilots like on Photoshop and all
those types of things.
But how do you develop those applications?
Well, by the fact that we have access to the window object
that we've created, we were talking about whether we could
do what the magic iFrame did.
You kind of smoosh HTML and JavaScript from one window
into another window with logic or with CS--
well, maybe not with CSS, but basically enough of the
construct to say, well, it's an empty window until you
inject data into it, and content, and logic.
PAUL LEWIS: I think the thing to remember as well is we keep
saying that that background page is the hub.
And if you were going to do this, you would do that kind
of magic iFrame smooshing-in kind of
methodology, wouldn't you?
To be like here's a new window.
Smoosh in everything I need.
Off you go.
I mean, we've played around with Web Intents.
I keep saying this.
I'm known for Web Intents and pushing it.
That's a shock to me.
PAUL KINLAN: Yes, I know.
I do, you know.
I warn you now.
We'll talk about it.
But yeah, the idea behind Web Intents was Web Intents inside
Chrome applications-- they opened up--
basically they just called on-launched again, so it's
like launching a brand new version of the application
each time you call it.
But your entire application was constructed and
componentized out of defined actions.
So in this case, I mean, this is not a great
example for Web Intents.
It's not a great example.
No, it's a good example.
I'm joking.
PAUL LEWIS: I am mortally offended.
PAUL KINLAN: The general idea was that you might have like
an edit function, a view function, and different
components inside your application
with different views.
And you'd want third parties to be able to kind of edit an
image, or view an image using your application.
But what about yourself, right?
Do you want to be able to have to manage all that in a
completely different way than the Web Intents client would?
And so we played around with the idea of saying, well,
every single app inside your application is just an intent.
So you basically say I'm going to fire a brand-new window.
I'm going to fire an intent.
Find me an application.
I know the applications myself, so I just call my
on-launched event and pass the data in.
And then the system goes, well, I know I need to make a
brand-new window.
Open it up and put your data in.
So in that sense, so you're saying if I had an application
that could edit an image, it doesn't matter whether
internally I say dispatch the Web Intent to edit an image,
or somebody else says dispatch the Web
Intent to edit an image.
PAUL KINLAN: It's all the same.
PAUL LEWIS: It's all kind of handled the same way.
It kind of standardizes and homogenizes that interface to
your application, doesn't it, I suppose.
PAUL KINLAN: Yeah, and uses the same logic that an
external party would use as well.
It's kind of nice.
It didn't work.
PAUL LEWIS: But it will, right?
PAUL KINLAN: Yeah, it will.
There was a bug where you couldn't fire an intent on
your application, which I hope will be fixed.
At least it should be.
Otherwise, I'll go and crack some whips.
Well, that'll be fun.
PAUL KINLAN: That'll work, won't it?
PAUL LEWIS: Yeah, it's never going to be a problem.
PAUL KINLAN: But yeah, we were talking about this with
Angular as well.
PAUL KINLAN: We haven't quite worked it out just yet.
But we were talking about having your entire application
user interface defined in one HTML file.
And then certain directives--
and those directives, for instance, in Angular, which
say make this area a modal dialog.
You basically call it.
It makes a modal dialog inside your page.
Well, if we can inject content into web pages, why can't we
inject that kind of modal dialogue?
It's not necessarily a modal dialog.
We haven't got modal dialog in this.
It doesn't directly inject them in.
It just basically says, well, I'm going to inject the HTML
and JavaScript content in my controller, and my view, and
all that type of stuff in.
And you've got it coming out, and you've just got one HTML
resource as the window.
And we're open to experimentation, right?
PAUL LEWIS: I was going to say this.
And I'm glad you said this.
We're keen to get feedback.
The question is--
coming back around, is NVC dead?
Should we move on?
No, it's not dead.
Should we move on?
Go with the methodologies that you're comfortable with.
We're keen to see how you get on.
So just let us know.
That's really the general gist, but no, I
don't consider it dead.
Next question, then.
PAUL KINLAN: So the next question, "Does multiple
window message pass-in require the Beta version of Chrome?
Or will it work with the current Stable version?"
That's from Chris from Philadelphia.
So this is very much in the Dev channel at the moment.
The Chrome Apps system which are--
well, the aim is to make these applications look and feel
native on the desktop, right?
They're not quite ready for Stable channel just yet.
The APIs are still evolving.
So they're very much behind the Canary branch and Dev.
At some point soon, they should roll out into Beta.
And once they roll out into Beta, they go into Stable.
The interesting thing just generally is that--
sorry, I'm just seeing a Web Intent question.
I should not look at other screens.
So the thing is they're not there just yet.
They will come soon.
And then this will be available for those types of
applications also.
So it's pretty cool.
PAUL LEWIS: What was that Web Intents question then? "Chrome
extensions on Web Intents?
Best mates or oil and water?"
PAUL KINLAN: Best mates.
PAUL LEWIS: Oh, there's a shock.
PAUL LEWIS: Color me surprised.
Why are they best mates?
PAUL KINLAN: Because the whole of Chrome is a best mate with
Web Intents.
PAUL LEWIS: I like it.
PAUL KINLAN: So when you look at a lot of things to do with
Web Intents-- can we just try actually?

Go back to the screen.
Where are we going?
What are we doing?
Can we go to a site, your blog.
Can we go to your blog?
PAUL LEWIS: Oh, interesting.
Look at that.
I'm joining Google.
PAUL KINLAN: When are you joining Google?
PAUL LEWIS: already did.
Oh, look at these!
Some tutorials.
So click on the little plus button.
Share this page.
PAUL LEWIS: I would love to.
PAUL KINLAN: This fires Intents.
So we don't have any of these installed.
So what happens here is there's actually three or four
different applications.
None of them are installed.
Share to--
is this--
what type of email is this?
Is this a--
PAUL KINLAN: --personal email address?
PAUL LEWIS: This is completely fresh.
PAUL KINLAN: OK, we'll give it a go, right?
Oh wait, tell you what.
Let's share with Gmail.
See what happens.
We won't actually see any data come through, but add it and
come through.
So what's happened here is that we've redirected.
Could we jump back from the code now and then just go to
our pretty face?

So what's actually happened here is that we've actually
passed the data from the share intent straight through to an
It can be a Chrome application, old packaged app,
new packaged app, hosted website.
So it could be say, a cloud file, [INAUDIBLE].
PAUL LEWIS: Could it be an extension?
PAUL KINLAN: And an extension.
So this is not Gmail directly supporting Intents right now.
This is me writing an extension which uses Intents.
PAUL LEWIS: So it passes through.
PAUL KINLAN: Yeah, basically.
So all of the Intents system is built
off the back of Chrome.
And irregardless of whether it's an extension, the host of
that normal web application or website, or an application,
they will all work together.
Best mates, indeed.
PAUL KINLAN: Best buddies.
Definitely not oil and water.
So next question--
"How do I manage supporting users-- we might as well
answer this question.
We're not going to have a good answer, I don't think.
"How do I manage supporting users on all the Chrome
versions, eg, 15 on Ubuntu.
I can see breaking changes around Version 18, but the
docs pre-18 are no longer available.
My specific problem is around send message and send
I think the best thing to do is send that to the Chrome
Extensions group or the Chrome Apps group on Google Groups of
all places.
Or ask on Stack Overflow, because we monitor Stack
Overflow as well.
The actual documentations, we try to keep the documentation
in line with what is mostly in production.
So Stable is where, I presume, like 99.9% of
all our users are.
I don't know the exact figures there.
But the majority of everyone's on Stable, which at the
moment is on 22.
Beta, I believe, is still 22 as well.
It might change to 23 at some point.
Dev is 23 going on 24, those types of things.
So we tend to only keep documentations for what is
really, really applicable.
Because we're an auto-updating framework, the number of users
outside is pretty small.
But that being said, we want to make sure you can have your
questions answered.
And you could do that in Stack Overflow.
Tag it with either Google Chrome or Chrome
App I think is the--
PAUL LEWIS: Google Chrome App.
PAUL KINLAN: Google Chrome App, is it?
PAUL LEWIS: I think so.
PAUL KINLAN: Or Chrome Extensions.
Google Chrome Extension, I believe it will be.
Tag them up there, and away you will go.
And someone will try and answer your question as best
as possible.

So do we have any more questions?
Sorry if this is out of topic.
It says Luciano. "What are the deploy
options for Chrome Apps?
If I'm using Google Apps for Business can I deploy only on
my organization?
PAUL KINLAN: This is a good question.
So we have good support for Apps organizations.
If you go to the developer dashboard,
m/webstore/developer/dashboard, That's where basically you
manage your applications.
And if you're inside a Google Apps domain, I believe it very
much depends on the policy that your admins have set.
PAUL LEWIS: Absolutely it does, yes.
PAUL KINLAN: So you can either publish locally to your own
/a/yourdomain kind of web store, which will have the
rest of the web store in if the administrator's
technically enabled it.
But it'll have just your applications and only your
users will be able to see them.
That being said, if you make an application and you want to
host it, publish it using your own Google Apps domain, you
can still do that, and you can still publish
it publicly as well.
PAUL LEWIS: Awesome.
PAUL KINLAN: So, yeah, that should work.
And the thing right now is we don't have the ability to
support these new Chrome apps just yet.
I hope it's soon.
And we'll let you know as soon as that happens because it
will be a joyous day.
PAUL LEWIS: But do start playing with it.
Because when that does happen, you can have your
apps ready to fly.
And that's a lot of users that get to play with
your shiny new app.
So I'm apologizing for looking away from the camera.
PAUL LEWIS: Got any more questions?
PAUL KINLAN: So Terry Davis. "With this practice, can you
code a floating YouTube video that can have an adjusted
PAUL LEWIS: So the floating window thing--
PAUL LEWIS: --yes, we can do because--
PAUL KINLAN: The transparency, no.
PAUL LEWIS: The transparency, no.
PAUL KINLAN: There is actually an open book about this.
We would like you to be able to have the ability for you to
say, well, different parts of your Chrome are transparent.
We can have the ability to do a lot with the Chrome in your
Chrome application right now.
But not transparency.
PAUL LEWIS: But the floating window thing, you can, for
example, set.
When you create that window, if you remember back to my
code, I had the createWindow going on.
In the object that you pass through where I had the width
on the left, you can actually add frame as an extra property
and then set none.
And that will get rid of the bar at the top and all the
rest of it, so it's actually just a window.
So you can then drop in some YouTube goodness into there.
So you can do that.
And then also we've got a bug open for transparency.
PAUL KINLAN: I think we're at the end
of our general questions.
I do want to talk one more time about the windows and the
window in APIs.
We are definitely open for consideration of how you want
to build applications with the window in API.
We do have some examples on GitHub, and we'll share them
out later on.
I'm just cleaning some of them up little bit.
But both Censure and Kendo made two applications.
One is a video streamer that connects to your media center
on your local network.
Pretty cool.
PAUL LEWIS: That sounds amazing.
PAUL KINLAN: Yeah, it does UPnP broadcast, all
that type of stuff.
PAUL KINLAN: It's nice.
They actually built their own method for routing messages
between them.
So there's some pop-up frameworks you can get in
I think it's JPopup of all names.
And basically, the idea behind that was to have this
background page orchestrate all the logic, especially when
you're in sandbox.
We didn't really touch that today with the sandbox.
PAUL KINLAN: If your application is in sandbox, I
don't believe you can actually get access to
the background page.
PAUL KINLAN: You have to post message.
PAUL LEWIS: Post message.
So if you need to use eval and a new function and you have to
have the sandbox attribute for your
application, you will be--
I think you have to use--
PAUL LEWIS: Kind of what I was saying.
Actually, that does apply if you are using say, a
templating engine.
Most of the time, they use eval or new function.
To get those to work seamlessly, then you do put
them into a sandbox.
So you would use that, as Paul said, the post message thing.
I think the only framework I'm aware of is Angular right now,
that It doesn't need--
PAUL KINLAN: Backbone.
You can use Backbone to some extent.
The only thing is the [INAUDIBLE] on the template,
which you can work around quite easily.
But generally, Backbone work perfectly.
Kendo, I believe, censured the use of the sandbox
system, so they use--
but it's kind of cool because it abstracts your view and
your logic, awake quite nicely inside the background page, so
it's pretty cool.
PAUL LEWIS: Also, what we didn't cover today, I believe
we covered in a previous week, was the minimize and maximize.
You've got also other methods that you can call on the
windows, which as I say, we didn't cover today.
But you can find the documentation on
And that covers things like minimize, maximize, and--
PAUL KINLAN: You know what is interesting I found the other
day scanning the docs?
PAUL KINLAN: If you put "trunk" before "apps," you get
the very latest documentation.
And TCP Listener looks like it is in the latest version.

PAUL LEWIS: Service in the browser.
So we have the ability to do UDP service in the browser
because we have BIND, which is pretty cool.
PAUL LEWIS: It is amazing.
PAUL KINLAN: The biggest one people want, though, is the
ability to do a TCP server in the background.
So you could basically run an HTTP server inside your
PAUL LEWIS: And the web serving the web--
PAUL KINLAN: It's like oh!
PAUL KINLAN: It's pretty cool.
But that's actually pretty cool because we get the
ability to do nice things.
I haven't tested it to see if it works.
I'm presuming, though, the documentation is there.
Then there's a good chance that at least the AP-- well,
I'll rephrase it.
The documentation generates off the API information.
So at least it means the stubs are there.
Whether the actual implementation is there is a
different thing.
But yeah, we have this ability to do some really potentially
awesome stuff around networking.
Eric Bidelman-- so we ran a hackathon internally.
PAUL LEWIS: Certainly did.
PAUL KINLAN: Eric Bidelman was trying to
do something similar.
We couldn't do it.
Basically he was saying I want to be able to develop a My
So My Chromebook.
We always get questions about Chromebooks.
He wants to be able to develop on his Chromebook, but also
host it and test his application.
PAUL LEWIS: Absolutely.
PAUL KINLAN: So the idea is basically like I don't want to
have to go out, FTP it up somewhere, and
test it that way.
I just want to be able to run a basic web server to test my
content and view it inside the browser.
PAUL LEWIS: So TCP Listener is exactly what
you need for that.
That's the aim , is TCP Listener is that exact thing.
That's the first use case I can think of.
PAUL LEWIS: Yeah, it's a good one in all.
PAUL KINLAN: I think it's pretty cool.
PAUL LEWIS: All right.
PAUL KINLAN: I can't imagine SMTP servers in the browser.
PAUL LEWIS: There's a whole world there.
PAUL KINLAN: Yeah, it's pretty cool.
PAUL LEWIS: It's pretty awesome.
PAUL KINLAN: So anyway, we would actually like to know
what type of things that you want to hear
from us in the future.
PAUL KINLAN: Will I be on my own next time?
PAUL LEWIS: I don't know.
We'll find out, won't we?
We'll see what happens.
PAUL LEWIS: Tune in.
Oh, to find out.
PAUL KINLAN: Ideally, we want to try and get more very
specific application information--
so show you applications running rather than just show
some of the raw APIs.
I will deep dive into those APIs.
But we'll give you a good overview of
what's going to happen.
I really want to talk about the browser type, because
that's one of those things that's going
to be pretty cool.
PAUL LEWIS: Yeah, especially how that differs
from like my an iFrame.
Because that has come up before.
How does this differ?
So we can cover up that as well.
PAUL KINLAN: We'll cover up that.
We'll do a whole load of stuff around storage.
You'll do some playing around with that.
Image downloading at one point.
PAUL LEWIS: Absolutely.
I know Eric Bidelman covered it.
But hopefully, we'll get a library out at some
point soon I hope.

PAUL LEWIS: Thank you very much for joining us.
PAUL KINLAN: It's a little bit short today.
I'm very sorry about the questions and answers, just
pure because I--
So what It was, I didn't set it up correctly completely.
I set the questions to end as we started,
not end as we finished.
PAUL LEWIS: This is quite cathartic for you, isn't it?
To just share this out to the internet.
PAUL LEWIS: Dear internet--
PAUL KINLAN: Dear internet--
PAUL LEWIS: I'm sorry.
PAUL KINLAN: --I'm sorry.
PAUL LEWIS: There you go, you see?
Feel better?
And also--
We have another question.
Can we continue?
I think we can.
PAUL LEWIS: Well, we haven't said goodbye.
PAUL KINLAN: We haven't said goodbye.
PAUL LEWIS: This is the joy of the liveness.
PAUL KINLAN: So if you're into British comedy, we have a
surprise for you later.
PAUL LEWIS: No, don't do that.
Yeah, we did it.
PAUL KINLAN: We did it.
It's put the pressure on.
PAUL LEWIS: No, I like it.
And we'll forget.
I'll be fine.
PAUL KINLAN: So it's "Heymonth." I think that's how
we pronounced it.
I got it from, I think, Bangalore again.
PAUL LEWIS: "What was that about magic iFrames?"
PAUL KINLAN: "Magic iFrames. "I saw a proposal to remove
it." Yes, I heard about a proposal to remove the magic
iFrames work as well.
The reason why-- well, I say the reason why.
I don't know the full reason why.
I wouldn't be surprised because no one really knew how
it ever worked.
I never saw any documentation.
PAUL KINLAN: You search Google for magic iFrames.
You get a page mention in magic iFrames and not exactly
what it was.
But that was the idea, is you could start to inject content
and bridge an iFrame between two windows.
So you've got open window, well, the window reference off
You basically put the iFrame in.
But no one ever knew how to do it.
But if you ever saw that's live, share them, out and I'll
share them on Google and Twitter.
I'm Paul Kinlan on Google+.
PAUL LEWIS: I'm Paul Lewis on Google+.
PAUL KINLAN: But you have a funny name on Twitter, right?
PAUL LEWIS: Aerotwist.
PAUL KINLAN: Aerotwist.
Why is that?
PAUL LEWIS: It's just because they're apparently--
and this was a shock to me, but there
are other Paul Lewises.
And some of them are like a famous pianist, a journalist.

So that left me no choice.
I had to come up with another name.
So Aerotwist it is.
PAUL KINLAN: That's a pretty cool name.
PAUL LEWIS: It's all right, yeah.
It sort of works.
PAUL KINLAN: I'm lucky that Kinlan is not a
very popular name.
So what are you going to do?
Roll with it I think is what you're going to do.
PAUL KINLAN: Yes, yes.
There was an actor called Jim Kinlan.
But that doesn't mean anything.
It's not really the same.
PAUL LEWIS: Well, this is a thrilling end-on topic.
So with that said--
PAUL KINLAN: So with that said--
PAUL LEWIS: It's goodnight from me--
PAUL KINLAN: And it's goodnight from him.