Google I/O 2012 - The Next Evolution of Chrome Apps


Uploaded by GoogleDevelopers on 28.06.2012

Transcript:
>>Erik Kay: Hi, everyone. Welcome. I think we will have a few more people sprinkling
in here, but my name is Erik Kay. >>Mihai Parparita: And hi, I'm Mihai Parparita,
and together we work on the Chrome apps team. >>Erik Kay: So just a quick show of hands
so I can get a feel for what the audience is here, how many people are as familiar with
Chrome apps as they are today? All right, great. That makes things easier.
So why don't we dive in a little bit and just sort of do a little recap about how we got
to where we're at today? So I/O last year we talked about a few things.
First off, as you know, we talked about Chrome getting to, you know, 160 million active users.
We also launched for Chrome apps in-app payments through Google Wallet.
We announced that the Web store was now localized in 42 languages.
And we had the Angry Birds exclusive promotion that really showed how that it was really
possible to make great quality apps just using HTML5.
And we've kept busy over the last year since then.
The first thing, you know, to highlight, is Native Client. We launched that this fall.
And Native Client really brought to the table a great set of games. You know, some showed
that you could do high performance computing, that you could leverage native code in your
browser. Things like Bastion, Mini-Ninjas, From Dust, great titles that show off the
capabilities of the platform. You saw Gaikai in the keynote today that really
was another great example. We redesigned the Web store. We have a completely
new look and feel, and that really expanded the usage that we saw out from our users.
Users were much more engaged. They come back more frequently. They install more applications.
We've announced today that we're up to 750 million app installs. Overall things are going
great for the Web store. And of course, you know that Chrome is now
at 310 million active users, almost doubling last year's number. So the reach potential
for apps has been going through the roof. However, you know, that's never enough. And
we want -- we've been worrying about the platform itself and how to keep pushing that forward.
And so we've been thinking about, well, what do Web developers need? What are the capabilities
that are missing from the platform and what can we do to move things forward?
So we've been listening to your feedback and we've actually been bringing people on the
team who have come from Web development backgrounds. People who have experience building some these
Web apps, like Mihai, who is our tech lead for Google Reader, which many of you may know.
>>Mihai Parparita: Yeah. So I was on Google Reader for quite a few years. As you may know,
Google Reader is an advanced HDIC application that has pushed the edge of what browsers
can do. On the other hand, we feel like the platform
could do more, could provide more flexibility, more power for Reader and similar apps.
Just to give you a few examples, Reader is one of the first apps to be offline enabled,
and that was a technical challenge and we fought with manifests and caches like everyone
else, but even with that it wasn't the best user experience. Users had to enable offline
mode. Users had to launch a browser to use the app which sort of feels like a tautology.
Why would I use a browser when I'm offline? Another issue that we faced in Reader was
dealing with third-party content where feeds can have Flash, they can have iFrames, they
can have arbitrary JavaScript, and we want to have the experience to be as rich as possible,
but we don't want a random feed to be able to steal your Google cookies or otherwise
take advantage of the fact that it's being displayed in a privileged environment. We
have to jump through a lot of hoops to sanitize the content, have whitelists, blacklists,
and we always lived in fear of well, what if we missed something? What if tomorrow anyone
can access your Reader account and your account and all that?
And finally, users wanted a lot more flexibility about how they consume feeds. Do they want
to open up the item in a new tab, in a new window, in a pop-up, they want a mini browser
inside of Reader? We couldn't provide any of that. We could provide a usewindow.open
or target equals blank, and sort of hope for the best, hope that the pop-up blocker didn't
get us, but that was about it. So Reader, you know, is in some ways a well-suited
app for the Web environment and I'm sure others of you have run into even more issues.
>>Erik Kay: Right. So we took feedback like that and we really started to push forward
in terms of what we wanted to do. We're evolving in four main areas. The main
one that we'll start with is we're pulling apps outside of the browser. We'll dive into
each of these in more detail, but just the quick overview is pulling them out of the
browser. We're enhancing the user interface, giving you more control over the windows and
we're making apps be offline by default, making it so it's easy to build them in a way that
they behave reasonably with poor network connectivity. And finally, we're adding a wealth of new
APIs to give you access to powerful system and device capabilities.
So let's dive in a little more deeply. So what do we mean by breaking out of the
browser? Well, the first thing we mean is that you launch apps from outside the browser.
So you'll see in a minute here that basically you'll no longer need to launch the browser,
go into Chrome, go to the new tab page to find your apps. The apps will instead come
from the operating system, the traditional place that you're used to finding them and
launching them. Second, the apps will act as peers to their
other native applications, top level windows. They interact alt tab to switch between applications.
Everything you would expect a native app to behave like in a user interface perspective,
OS integration perspective. It will no longer be a tab in a browser.
So let's give them a demo and show them what this looks like, Mihai.
>>Mihai Parparita: Sure. So this presentation is actually in itself an app. The demo just
breaks out of the app. And if I move the window out of the way you can see that I have my
top level window. It has, you know, minimal -- no tab strip, no Omnibox, and there's a
Chrome icon at the bottom that seems to be getting clipped. And where I can make tabs
and the application itself has its own icon in the launcher.
This is the experience on Chrome OS where it is a full application launcher. On Windows
there will be shortcuts on a desktop and the appropriate behavior on other platforms.
So let's switch back to the app and let's talk about UI.
>>Erik Kay: Right. So enhanced user interface. So you already saw that it has a native level
-- top level window frame. There's no browser Chrome, there's no tabs, no address bar, no
back button. And further, you have full control over the look and feel of that frame.
Next you have -- you can actually manage multi-window applications.
Actually, I did this the wrong order. But multi-window applications. So that means you
really will be able to cooperate between multiple windows and have them interoperate. Today
in tabs it's very hard to sort of have multiple tabs that are not cooperating with each other
and interacting with each other and it's hard to do things like tool bars and, you know,
panels that cooperate and interact with your host window.
And you know, one of the things by not having browser Chrome is, well, what do links do?
Well, links behave just like they would in a normal native app. When you click on the
link it opens the browser window. Let's show them. There's a link to Google.com.
>>Mihai Parparita: I'll tab back to the application. >>Erik Kay: Right. So now you're back inside
the application. So we've got another demo here that shows a little bit more about what
windowing control can do. >>Mihai Parparita: This is a little toy demo
showing that we have an app window. You can see the minimal Chrome. Bizarro World one
is actually a full custom window where the app controls every single on it. In this case
I just made it all black. We have full control over behavior so I know I can have it resize
itself and certainly drag around and follows. You imagine this could be a little dog toolbar
and I can control it or have the window in a minimized state.
>>Erik Kay: Right. So offline by default. Before we dive into the specifics of this,
it's probably worth explaining what do we mean by offline.
So A lot of people think offline and they think, okay, I'm on an airplane, I have no
connectivity whatsoever. That's not the only time that offline matters for applications.
Offline can mean I have got slow connectivity. I've got spotty connectivity. For anyone who
uses a cellular network, maybe in this building, the Wi-Fi, you know, you're used to not have
reliable connectivity. The speed might change as you go. Maybe you're
in a hotel with a captive proxy. If your application is trying to talk over the network, it needs
to be able to be robust in the face of these different network connections.
So how do we do this? Well, we're starting from a base of Chrome packaged apps. Basically
for those of you who aren't familiar with Chrome apps in general, packaged apps are
a zip file, a collection of HTML, JavaScript and other resources for your Web application
that are downloaded, installed on the user's computer. So all the code and logic is always
there ready to go. We take some extra steps and -- to make sure
that we're enforcing a strict separation between data and user interface.
By being packaged, by making sure that all the code and logic are always being -- are
always running from client side and not being generated server side, we mean that the app
doesn't get into a broken state and it's up to you to download your data, store it locally,
render your UI appropriately. We further enforce this with -- support this
with building APIs that are themselves resilient to being in these poor network connectivity
conditions. And finally, this may seem like a small thing,
but the fact that we've moved apps from launching outside the browser actually addresses one
of the key usability issues with offline. Today some of you may have actually gone through
the effort to make your hosted Web app work offline and found that even after you went
through all the effort to work with AppCache and make that do what you want it had to do
that users are still not finding that functionality and they are still frustrated with using it.
For the reasons that Mihai was pointing out before, they had to know first to launch the
browser, then they had to somehow navigate to your app. Well, if they know how to bookmark
it, that's about 10% of users, then they can get back to it. What about for the rest of
the users? Well, for them they have to either know what
the URL is ahead of time or for many of them actually what they do is they go to their
favorite search engine and they try to navigate to it. And guess what? When you're offline
search engines don't really work. So people in a poor connected world are continuously
reinforced that the browser doesn't work because all their tabs are broken. Even when they
have an app that they know works, they don't know how to get to it. So pulling app outside
the browser and making it a first class peer to their other native applications gets past
all that anxiety and all the logistics of getting there.
>>Mihai Parparita: So we're gonna demo this very quickly and we'll get the presentation
out of the way. I'm going to yank the ethernet cable out of my Chromebook.
As you can see there's a little icon in the corner that says I'm offline. I can refresh
Google and show that it doesn't seem to work. And we're going to install an app.
In this case we're going to sort of do a kind of stress test where we are offline. We're
going to install the app right now in developer mode, but it should process the same. And
this app has never had a chance to run before. It's never had a chance to talk to its server,
download data, but the experience should still be acceptable.
The specific app we're doing is a diff tool that lets you compare files. So when it launched
it has an offline indicator that says you're currently offline, so all it can do is it
can diff local files, but dash will keep working. So let me pick a couple of files. And as you
can see -- I lost focus. As you can see, the application still works.
If I manage to find the ethernet cable and plug it back in --
>>Erik Kay: While Mihai is doing that, I'll point out that we're doing this demo on Chromebook
and we're doing it with the latest Canary build of Chrome OS. So we're taunting the
demo gods -- >>Mihai Parparita: Fine in this case. We are
back on line. The app has noticed that we are online. The choose URL feature has appeared,
so now we can diff not just local files, but ones that live on a server. So I think I have
some cuts. And as you can see -- >>Erik Kay: This is really a tortured case
for an application. It launched for the first time never having seen the network. So it
was able to run robustly. Without quitting and relaunching it, it recovered. So it was
able to see, you know, the fact that the network was back. You didn't have to do anything,
you didn't have to refresh the page, you didn't have to take that extra step. The app was
just able to proceed. >>Mihai Parparita: Now that the projector
has been fixed you guys can see that the app launcher at the bottom is what I was referring
where all these apps can be launched offline. >>Erik Kay: Right. All right. So new APIs.
Now, this is one of the more -- the area that I think most of you are going to dive into
first when you start playing with Chrome packaged apps. And it's all the new APIs. We think
of them in three groups. The first area are what we call system APIs. The system APIs
interact with the operating system at a low level or with hardware on your device, so
maybe USB or bluetooth, or as you saw in this morning's keynote, raw UDP or TCP.
These will enable a wide variety of apps that you've never been able to build with Web technology
before. Next we've got shared data APIs, and shared
data APIs are -- provide ways of interoperating with other applications on your system. Things
like photos or contacts, calendar entries, things that you want to be able to access
safely from multiple applications. And finally then a group of service APIs.
The service APIs are your -- the Web services that you all know and love, but built into
Chrome, into the Chrome runtime in such a way that it's going to be resilient to poor
network conditions. So things like analytics, in-app payments, things like that, will be
coming to the APIs. Why don't we give a demo of one of these APIs
in action? >>Mihai Parparita: Sure. So this demo is going
to display me because I'm going to hold a physical device here. This is a little science
fair kind of project that one of our engineers Mike made. It has an arduino board on the
back. It has -- it talks to the Chromebook via a serial port, a serial-over-bluetooth
a serial-over-USB in this case, and it has a little stepper motor here that is controlled
by the arduino. And the slider at the bottom of the screen controls the motor. It just
sends a one-byte command saying "please rotate to my current position," and that goes over
the serial wire, the arduino interprets it. The key thing here is that the Chromebook
knows nothing about this particular device or about arduino in general, it just knows
that there's a serial port and that in turn is exposed to the application. So all of the
logic about the specific device is in the application that can be installed by any user.
>>Erik Kay: The other key bit is that all this code is just JavaScript and HTML, right?
It is -- no special, no device drivers, no, like, native code that needed to be there.
That said, we are going to be providing bindings in addition to JavaScript, also to Dart and
to Native Client, so you will be able to access these APIs from whatever programming environment
that you'd like. Speaking of the programming model, why don't
we dive in and take a look at some code. Before we do that, though, just a refresher
of what is behind the core bit of the programming model. So as I said, these are packaged apps,
and that means they're a directory full of resources.
They have a background page that acts as a hub, so what that means is this is what starts
up. When you launch the app, a background page launches and it triggers an event, and
that's what -- then it's up to you to decide what to do.
In previous incarnations of Chrome apps we had a launch URL, basically a page that would
open up in a tab. Now you've got full control over how your app behaves, how many windows
it opens up, if it even opens up a window at all, or does something in the background.
And that last step is sort of an important use case that we're really interested in is
being able to handle system level events and have your app come and go based on signals
from the runtime. So let's take a look at some of the code that
shows this in action. >>Mihai Parparita: Sure. So I'm going to call
up a Hello World demo. And incidentally, to actually code the app I'm going to use an
app. This is a text editor that's been whipped up by one of our other engineers.
So like Erik said, first we start with the manifest.
So if you went to the extension talk yesterday, you know there's a new manifest called Manifest
Version 2. >>Erik Kay: Right. And Manifest 2 basically
is the trigger that we use to enforce some of the new policies with apps and extensions,
and fork turns on CSP by default which we'll talk about in a little bit, but it also is
one of the keys for showing off the new app behavior. It also has a -- the basics that
you're used to, a name, a version, and another field that is -- you've seen before, the app
field, but rather than a launch URL like we said before, instead it has a designation
of the background page, as I said, the main, the hub of the application, it uses the same
event page technology that we've just announced with Chrome extensions which means that it
basically can come and go on demand, as the system needs it. So we specified the app.
The other thing actually, Mihai, you might want to add permissions to it. So permissions
are the way of specifying in the manifest what capabilities your app needs up front.
This allows us to, you know, control, you know, it's a security feature that basically
allows us to limit the damage that an application can do if it has a bug in it. So then next,
we're diving into the actual background page itself. This is main. As I mentioned before,
what it does is it loads, and then it fires off a launch event. So the first thing Mihai
does in his background page is set up an event listener in the background page, and in that,
first thing he does is to create a window, using our new window app API. And basically
this is the Hello World, launch the app, get a launch event, create a window, show just
an obvious snippet of HTML, so here is our Hello World. The next step is to load into
Chrome, now again, since this is just a packaged app directory, it's built in the same technology
as Chrome extensions and other Chrome Apps have been built in the past, so just going
to developer mode, load and unpack extension, and then we can just launch the app from the
app launcher directly, there you go, and we have our Hello World, so really trivial bit
of code, as you can imagine you can do whatever you want from that launch event and do more
advanced things, so before we do the more advanced things, let's talk a little bit more
about some of the other features of the programming model. So one of the things that's interesting
is that all of the windows are what we call single page applications. There's no navigation.
So we think this leads to an overall better experience and simplifies a few things, again,
the fact that we don't have a back button, that we don't have an address bar, we don't
want to have people building apps that wind up getting users trapped and stuck, we don't
-- we want to get rid of that flash of white repaint. And we've also actually removed a
few Web features, things that are -- that we think lead overall to bad Web performance
or have security problems with them. It turns out that on the Web at large, it's very hard
to deprecate features. Very hard to (inaudible) We have strict compatibility needs. As people
who are going to be building these Chrome Apps are going to be starting from scratch,
we have the opportunity to take a few and just eliminate them from the beginning, and
they will be things like synchronous requests that will block the UI thread or again things
that might call security problems. Speaking of security, let's talk a little bit about
the security model. So to start with, you get all the things that you're used to with
Chrome, you get process isolation, Chrome is famous for being a multi-process browser,
and apps are no different. Each app runs in its own process, completely separate from
each other. We also Sandbox each app, so each app has its own storage area, its own Sandbox
execution runtime Sandbox which makes it so that even if it had a bug, the limit, the
damage to what it could do is tightly controlled by the runtime. And part of that is the permissions
model I was talking about before. The app has to declare up front what capabilities
it wants to use, so in this case we have our little app that used the serial port API and
the Web cam, so if that happened to have a bug in it, that could be exploited by an attacker
somehow, the worst that could happen is it could do exactly what that app could do and
talk to the serial part, the Web cam. This is very different from what you're used to
with native executables, where once you have a security bug in the native executable, you
have access to the whole machine, everything the user could do, attacker could do. So I
mentioned content security policy. Now, what content security policy is is a way to protect
your app against cross-side scripting bugs. For those of you who aren't familiar with
cross-side scripting, it's basically a way that an attacker can somehow get code injected
into your page and run in the context of your page. Now, in a Web page, this is bad enough,
because it means like -- in something like Gmail, it could -- you know, an attacker could
maybe read all of your e-mail and post it to another site. In the context of an app
it could do even more potentially with the new more powerful APIs we're adding, like,
you know, I don't know access your Web cam, leave persistent files somewhere on your hard
drive, talk to some hardware you didn't want them to talk to. So we really try to lock
this down content security policy makes it so your apps will be resistant to these sorts
of attacks. So let's show that in action. >>Mihai Parparita: Sure, so I'm going to take
my Hello World demo from earlier and make it actually do something besides play Hello
World. I'm going to have it -- have a little form that asks users for their name and then
displays it in the output, so that is the markup side, and then on the scripting side,
I have sort of the obvious implementation I just described where I -- where I get the
submit event and display the name and the output.
>>Erik Kay: For those of you who are, you know, the more observant in the crowd, you'll
know that inner HTML is a pretty dangerous feature of the web to use. Basically is taking
-- he's taking unescaped content and just injecting it as code straight into his page.
>>Mihai Parparita: Let's load that same page because it doesn't use any app APIs just in
a regular Chrome tab the way a Web app would run in. So, sure, I can type in my name, but
because of inner HTML, as Erik mentioned, markup gets interpreted, H1s aren't so bad,
well, what if I had an unclick handler here that --
>>Erik Kay: So you can see that this is script. He's actually typing in JavaScript, now it's
going to get injected into his page. Now, obviously this is a very simplified form of
an access because there's a form field, user had to type it in. Usually they might come
in as a parameter in URL somehow got data stored into your system, but you can see that
if they could run code in the context of your app, they would be able to do the dangerous
things your app could do. Let's try that same code in an app.
>>Mihai Parparita: So app still works. HTML still gets interpreted because, you know,
Chrome does what it's asked and gives us inner HTML, but if I type in that same script snippet,
right, and try to run it, nothing happens. If I pull up the developer tools, these are
the same developer tools that you're used to, you can see a content script clause here
that appears. >>Erik Kay: Right. This is basically showing
you that we are locking down the app, so if you have a bug that might enable somebody
to inject inline script into your page, it can't -- it can't exploit anything in your
app, it's just stopped right up front. As Mihai pointed out, this is all tightly integrated
again with all the developer tools that you're used to, you know, so you can leverage all
the power that's there. They've been evolving really rapidly, and so there's a lot of great
features if you haven't been checking them out.
So let's talk about a few other bits of a security model. We take a further step and
isolate storage from one app to the other. So what this means is that what gets written
in one app, what happens in one app, stays in that app, it can't affect what happens
in the other. Cookies in your browser don't affect cookies in your app and vice versa.
And this is true not only for the origin, but if your app is doing -- interacting with
Web content from other origins, that too is isolated, so if you're logged in to Twitter,
you know, in your browser with one account, and your app interacts with Twitter, it isn't
affected by that. It would have to log in separately.
And I mentioned explicit shared data APIs before when I was talking about new APIs.
This is also a security feature, because it means that we can give apps access to more
powerful functionality without exposing your whole hard drive to them, and without giving
them the ability to write arbitrary files into arbitrary locations, so they can't leave
an executable on your hard drive and they can't, you know -- they can't just read your
Quicken file, for example, but they can read your photos perhaps, if they've got the photos
permission. And one further distinction that we've made for apps is that we no longer have
access to extension APIs within packaged apps. So we made an explicit split to say that an
app is outside the browser, and that means that interacting with the browser through
these extension APIs no longer makes sense. It's also true vice versa, extension APIs
can't affect apps. These apps are truly isolated from the browser and operate on their own.
There's one last security feature that we added here, which actually has some very useful
functionality as well, so you've heard us just talk about how we lock down this, lock
down that, you can't get this web content or that content. Well, sometimes it's actually
useful to get a host of Web content in your app. Well, in a similar way that you're used
to with native desktop and mobile applications, you can embed essentially a view, a full browser
inside of your app using something we call the browser tag, so this is different from
an iFrame in a couple of different ways. The first is that it's a top level frame. It doesn't
think of itself as an iFrame, it thinks of itself as if it were in a tab or in a window
by itself. Second is that it runs out of process. So if there's a bug, if there's some issue
where by going to remote website, somebody found a security hole in Chrome, it would
only affect the browser tag instance. It wouldn't be able to affect your app. And finally, once
again storage is isolated, so again, what happens in this browser tag doesn't affect
what's in your app and vice versa. So we've got a little more time, so why don't we dive
back into the -- that serial port demo and show what it's like to actually use some of
the more powerful APIs and do a little bit more stuff with it.
>>Mihai Parparita: Okay. So I'm going to close some more windows and load up a standalone
version of that serial port demo that we had earlier, and let's launch it. So same sort
of setup. Camera using the Web RTC API to show me, the same slider. This one is a bit
fancier. It has a serial port ticker listing all serial ports that are local. So the goal
is we have a Chrome logo, physical Chrome logo here, and we have the on-screen logo
here, this board actually also has a potentiometer, this little knob I want to turn, and I want
to make it so that turning this knob turns the logo on the screen, so let's pull up the
code for this. So it's in -- >>Erik Kay: Right, so the existing code was
basically writing to the board, sending it data. Now this one, we're going to change
it to add read function, read back. >>Mihai Parparita: So walking through the
existing code briefly, we have the Web RTC side of things where we get access to the
user's camera, and display the result. Since the app has the video permission, this did
not trigger info bar, the access happened immediately. We have the slider, the HTML5
range element here, we set up an on-change listener for it to set the position, and we
built a serial port picker by listing all of the ports that are available. Once we pick
a port, we have the open API call to actually start opening up a connection to it. And once
we open, we can start setting the position. We have the connection ID that we get from
the API callback. This is -- all these functions are async and we can start setting the position.
To actually set the position, we just send a single byte as -- actually as an ASCII character
from 0 to 9. We're using the buffers so that the serial port API can work with any kind
of binary data, too. We're using ASCII here for convenience. So as Erik mentioned, the
next up is to actually start reading back from the board. So given that there's a write
API call here, because you can imagine there's also a read API call we can use --
>>Erik Kay: Right. As Mihai mentioned all of the Chrome App APIs are asynchronous, so
you'll notice they all take a callback, and so he has in his function there, and on read
function for the callback which he's pasted in to save some typing time.
>>Mihai Parparita: Yep. So using array buffers we read back the data from the serial port,
we do the opposite conversion from ASCII to a degree value, and then we use CSS 3 transforms
to set the position of the logo and finally we want to read the next byte, so this isn't
a blocking call, it's just whenever the next byte happens to appear, the call back will
be invoked again. Let's save this. We're actually going to save it in the same place.
>>Erik Kay: And that -- by the way, that programming model did show some of the flexibility and
power of having an asynchronous API, but we're able to sort of cue these things up and have
multiple async things going on at once, and the callbacks happen, you know, when they
happen. We don't have to worry about inner leaving them.
>>Mihai Parparita: The App, it's the same sort of edit reload cycle that you might be
used to from web development, and so let's make sure it still works, that we can still
control it, so that part still works, and now if we have the knob up here, and we turn
it, the Chrome logo appears to spin, so we're reading data.
[ Applause ] >>Erik Kay: Obviously, this is a really simple
demo and not all of you are going to be sitting in your garage hacking on arduino boards,
but we're hoping that this sort of conveys the kind of thing you can do. Web technology,
and interact with hardware and system level data.
>>Mihai Parparita: For example, people on our team have built our C clients, you know,
telling their clients to use the raw socket API, someone else built an interface to a
heart rate monitor that uses Bluetooth, and all of this networks on a Chrome build, for
example, that couldn't talk to these devices before.
>>Erik Kay: So let's sort of wrap up about and recap a little bit of what we've gone
over. So we're evolving apps to break out of the browser, to have enhanced user interface,
more control over the windowing. To be offline by default, to have access to new, more powerful
APIs, now, we're also -- this is also available for you to play with right now, basically
as we said, this is canary build of Chrome. For those of you who don't know, the Canary
is our nightly update schedule. It's available for windows and Mac. If you're a Linux or
Chrome OS user, if you're brave enough, you can do your own build, or you can wait for
your next dev channel to come out and you can start playing with it then. We've also
been asked in the past about why are these apps, you know, specific to Chrome?
Why are they tied to Chrome? And part of the reason is, because, well,
there hasn't been a lot of appetite in the browser community for doing things, doing
more dangerous capabilities, but in the last six months or so, we've been, you know, talking
to more and more folks from the community and discovered that momentum had been building,
that people were all starting to think along these same lines; that building -- using Web
technologies to build more powerful applications, its time has come, and so we're working with
the W3C and with other browser vendors including Mozilla, and Adobe, and Intel and Samsung,
people in the Web community to form the new working group to help standardize this going
forward, so we're excited to help take the technology that we've been building for Chrome
and try to contribute it and make it a standard across multiple operating systems and platforms.
And finally you heard Sundar mention this in the keynote, but our intent is to make
these apps work on mobile as well. Everywhere the Chrome runtime exists, we think that we
can build -- bring apps -- bring this technology along with it. Now, we only showed you this
very simple serial demo, and -- but there's a lot more that you can check out. Some of
it right here at I/O. If you go over to the Chrome Sandbox area for example, you can see
Sencha has a neat media player demo that actually is implementing UP&P to stream from a local
media server, which is kind of cool. Kendo has a photo booth app that uses a lot of the
Web RTC stuff. There's a text editor that was done by the annular JST at Google, and
there's a demo that we'll call "Johnny" that is a --
>>Mihai Parparita: Johnny HTML5. >>Erik Kay: Oh, Johnny HTML5. Sorry. Johnny
HTML5 which is a Lego mindstorms robot which is being controlled over Bluetooth from your
desktop computer. Now, you can find all of these samples and a bunch more, actually,
in our new GitHub repo at GitHub.com, Google Chrome, there's an apps demo section there,
so I encourage you to go fork and play and contribute.
And -- and finally, the way to learn more, you can read our docs up at developer.chrome.com/apps.
Now just a quick warning. Since all of this new on the Canary channel by default, our
apps documentation points you at our current stable channel stuff. But there will be a
helpful link there that shows you how to get to the latest stuff. You can also join our
mailing list, chromium-apps@chromium.org, and if you want to talk to people in person,
people on the engineering team, we also hang out on RC at Chromium apps@freenotes. So feel
free to join in and ask away, we are looking forward to hearing from you.
We're really excited to see the kind of things that you guys can build with what we're doing,
but it is early on. Expect some bugs. Expect some growing pains. We would love feedback.
So now we will take your questions. [ Applause ]
>>Erik Kay: So if you have any questions, please come to the mic. By the way, when if
-- if we end this and you still have questions that you would rather not ask at the mic,
we will stick around afterwards for a few minutes, but also you can find us over at
the Chrome booth. We will be having office hours, so feel free to, you know, not only
check out the demos, but come by and ask us questions.
All right? >>> Can -- can an app launch another app?
>>Erik Kay: Not right now. That's a good question. >>Mihai Parparita: Can you describe more specifically
what you would like to do here? Is it a matter of like I would like to send an email so I
could launch the Gmail app sort of thing? >>> Well, sort of like the launcher, but without
having to bother the user with them going to find the app, saying this is the app that
you are looking for to complete this request. >>Erik Kay: So you can do some of it with
Web intense but not exactly the way that you're talking about for making a full launch replacement.
But that's the kind of thing actually we would probably more likely expose through extensions
in some way, but remember that each operating system is going to have it's own sort of natural
way of launching apps. So even if we did provide it, that might be specific to Chrome OS or
something like that. >>Mihai Parparita: Go ahead.
>>> Yeah. You mentioned early on in the presentation about offline usage and -- and the APIs into
the system that would degrade gracefully. Offline. Can you give some examples of that?
>>Erik Kay: Sure. So take, for example, something like that Google analytics right now. Everyone
is used to using Google analytics in their app, they want to see how their app is being
used. The way to traditionally include it would be to say script source equals whatever
your path to your analytics JavaScript file. But what if you are offline? So first off,
if you are offline when you launch the app, it might just fail to load the analytics code
altogether or it might load part of it. Then let's say that you load the code successfully
but then go offline. Well, the traditional way that it does its thing is to ping a server
to send its data. So in that case, we're modifying -- both the API to be loaded, you know, safely,
always on the client side and to know when it's offline and to store and cache some of
its statistics locally so it that it can save them up and report them up at a later time.
>>> Okay. Thanks. >>Erik Kay: Okay.
>>> So you said there's going to be a split between the app extensions -- I mean the app
API and the extension API. Can you tell us a bit about more about these, which go to
which category? >>Erik Kay: Sure. In general, extension APIs
are going to be limited to the things that affect the browser. That affect Web pages,
tabs, that sort of thing. And apps is going to be, you know, everything else. Now there's
going to be a few that are going to exist in both. In general, what we have done is
for now limited the ones that are more dangerous system-level things and those are not going
to be available in extensions to begin with. Something we're evaluating, we might change
our minds on some of that over time. But to start with, we're going to try to keep a clean
break between those sorts of things and apps and the things for extensions, keep those
tied to things that affect the browser. >>Mihai Parparita: Some APIs might behave
slightly differently, so the context of your API, for example, can affect any Web page.
But when used within your app it would affect only your own apps pages.
The docs I think should cover -- will start covering this.
>>> You mentioned the -- the applicant launcher can use a browser tag to launch another website.
So can any JavaScript in that website interact with the app?
>>Erik Kay: Sure. The way it will interact -- you can interact with the browser tag,
but it will be through a very specific post message type of interface. So it will be possible
to have some hosted Web content that you want that can message out and for you as the better
of the browser tag to inject bindings into the page as well. So you will have full control
over that page. We actually expect eventually the API to be rich enough that people will
be able to build a browser using a browser tag. So maybe you don't like Chrome's UI and
you want to build a browser with tabs on the side or something, I don't know, we think
that eventually you will be able to do that with the browser tag.
>>> What is the level of integration with the file system? So I saw in the text editor
you click, open a file, browser, you pick a file. But say you wanted to build an editor
where you have, you know, a directory tree on the side like a normal ID, click through
it. >>Erik Kay: Sure.
>>> Is there some -- I guess what kind of APIs are available for accessing the file
system generally? >>Erik Kay: Right. Actually, good point. We
didn't mention that. Probably most of you noticed that the text editor that we were
using is itself an app and was interacting with the file system and that text editor
was using -- was, you know, all JavaScript and HTML as well and it was using some of
the file system APIs that we're working on. In general, we're -- we're trying to limit
it, we can think of file system access in kind of two ways. One way are ways where the
user specifically indicates a specific file that they want to give you as the app access
to, through a standard open save dialogue type of thing. For that, you can access files
anywhere on the system, read, write access to them with the right sort of permission
and that sort of a thing. But in terms of arbitrary non-user initiated things, where
things you might say oh, because of file A I want to access file B, C, and D, we don't
allow you to do that. So in those type of cases, take an IDE, as an example,we would
say that you should bill something that interacts with files in your own Sandbox in that world.
So in that case maybe you might use native client to build the git implementation that
actually, you know, can directly, you know, pull down code from your repo right into your
Sandbox and edit things locally there. In your Sandbox you have got full access to all
of the directories, all of the files, unrestricted. It's the rest of the hard drive that's off
limits, unless the user does a specific gesture to give -- grant it --
>>Mihai Parparita: The third way for getting access to other files on the hard drive is
by the shared data API. So if your app is interested in not any arbitrary file but photos,
then it can, yes, ask for any photos without a user gesture.
>>> So does that mean -- so on Windows or Mac system, there's a system photo directories,
where supposedly the user puts their photos, you can ask for permission to access the files
in that directory; is that the idea? >>Mihai Parparita: Yeah.
>>Erik Kay: It's not exactly that. It's a little more. So we will actually try to discover
the types of places that you store your photos and so a lot of people don't -- don't keep
their photos leveraged to that one thing; they have an extra hard drive, whatever. The
ability for users to configure what defines their photos area. But even then it's not
just directory access, limited to the types of files that you can access to. There have
to be known types that we expect to be photos in that case.
>>> Okay. >>> Are there any particular patterns or practices
that we should employ when designing apps in terms of UI state so when a user exits
a UI, when we want that UI to come back exact the same as when the user exited.
>>Erik Kay: Yeah. That's a good point. So there's a lot of things that we think are
going to change in terms of how you build these apps that are different from what you
might expect with the Web page. Because you might be dealing with multiple Windows and
because your app can get shut down and pulled back at any time, we definitely want you to
be resilient to that and to be able to restore and pick up from exactly where you left off
in those cases. You know, the example is remember -- think
about this, these apps also need to be able to run in mobile environments where mobile
apps don't have guarantees of a lifetime. So that means that you have to write your
apps in a way where they might be shut down due to system resource issues, right? But
the user then switches back to them and it should look like nothing happened and it should
look like you never exited. >>Mihai Parparita: Sorry. The other part there
is that we have storage API. So for storage state, you can use the storage API which looks
like local storage but is asynchronous and more importantly is synced so that can have
the same state across all chrome devices that the users assigned them to.
>>Erik Kay: Yeah, absolutely. So we actually think it's a really interesting use case,
that you have your app in one state, you know, on your machine at work, you go home and you
launch it again from exactly where you left off at work.
>>> Any ability for external devices to wake up apps?
>>Erik Kay: Well, basically the whole gist of these -- of this notification based model
that we've got for -- for the app, it should enable that sort of a thing. We don't have
any specific APIs to talk about on that front yet. But -- but absolutely, things like -- you
can imagine things like server push, synchronization, that sort of thing will all be --
>>Mihai Parparita: I think the one thing we have is for the media gallery API, if the
SD card is inserted, it will fire an event, for example, so your app can decide to do
something in response to photos that just appeared even if it's not running.
>>> With the serial device that you were -- that you were working there, can -- when can we
expect to -- like support for USB devices in Chrome? And will it cover the whole range?
Can I like have a device that emulates an RS 232 system, could I access these kind of
things with Chrome, through Chrome? >>Erik Kay: So this serial device here was
actually a over USB, so it's serial over USB, and actually we do have a USB API as well.
>>Mihai Parparita: Low level USB API. >>Erik Kay: Right, exactly. So basically if
you know everything about a device, one of the demos that we have if you look in our
repro -- >>Mihai Parparita: It's a Griffin PowerMate.
Sends its rotation position over the USB, and we can read a byte off of it.
>>Erik Kay: So there's a little bit more work we need to do with the USB to really flesh
it out. For example, we don't have support for HID devices yet, you know, and I think
it would be nice for us to build in a little more knowledge about some of the specific
devices. Right now it's low level, you have to know a bit more about the device that you
are talking to. >>Mihai Parparita: For example, one of our
developer relations people has got his connect hooked up to an app, but that seems to work.
>>> Time schedule, approximately? Months, years?
[ Laughter ] >>Erik Kay: Well, as we said, you can play
with this today. And you know that in general our approach is to take a very incremental
release early and often type approach. So our intent is to get it out this year, you
know, into the stable channel. But you should be able to start playing with it now and building
apps now. Just depends on your tolerance for early code.
>>> Right, thank you very much. >>Erik Kay: All right. Well, we might be out
of questions. Any others? All right. Well, I think that's about it then. If anybody
wants to find us afterwards, like I said, we'll be over at the Chrome booth answering
questions and come check out Johnny HTML and the other fun demos over there and we hope
to hear more from you. Thanks. [ Applause ]