Chrome Apps: desktop today, mobile tomorrow


[APPLAUSE] PETE LEPAGE: Awesome. Thank you guys very much. And thank you for
joining me today. Today, I want to
talk about something new called Chrome Apps. And Chrome Apps provide a really
cool new set of functionality that I think is really
useful for web developers to be able to build
native-like applications. My name’s Pete LePage. I’m a developer advocate
on the Chrome team, and I work out of
our New York office. I’m going to make these slides
available offline after, if you want to copy
the URL down later. So you don’t have to worry about
copying any of this stuff down. But if you want to find me,
you can find me on Google+ or on Twitter and
on GitHub as well. And all the demos
that I have today are also going to
be up on GitHub, either later today
or sometime tomorrow. You’ll see some fun stuff
with those lights up there. You’ve probably
been wondering why they’re hanging around up there. Well, we’re going to
make them do some fun stuff with our phone
and with an app. So web apps, I think,
are really amazing. There’s a ton of
phenomenal things that you can do with them. It helps if I start
my timer, too. Wunderlist, really beautiful
to-do task manager. Helps you know what
you need to get done. You can set all sorts of
reminders and deadlines for things. Great, beautiful
app, really useful. “Financial Times”
built a web app because they didn’t
want to put their web app into the different stores,
because they didn’t want to have to pay money
to other companies. They wanted all of the
revenue to come to them. Fair deal, I think. Google Play Music
can go through– and please don’t
judge me on my music. But you can go, and you can
play all your music online, on the cloud. You don’t have to
worry about carrying it with you everywhere you go. Feedly. After Reader went away,
I switched over to here. And this is a great
app, fantastic. I can read all my articles. I can do all sorts of
great stuff with it. But it kind of sucks
once in awhile, right? You get this. Crap. You go to use one of
your favorite web apps, and you’re offline. Or maybe it’s not that
you’re just offline. Maybe you’re somewhere where
there’s no 4G connection. In the states, we say,
there’s no 3G connection, because, well, our
connection’s not so good. But where you don’t have
a very good connection, maybe you’re going
on a train where you’re going to lose
connection intermittently. Or what about if you want
to access hardware devices? So think about playing games. On the web, you can’t exactly
go and use your joystick. You can’t go and use game
controllers or other things like that. Or maybe it’s a matter of you’re
stuck on a legacy browser, and these new web apps require
newer versions of browsers. They need something that
supports modern HTML5 and CSS3 features. But then there’s another piece,
and it’s the native integration component. When you go to run an
application on your laptop, on your Mac, on your
Windows computer, you go, and you hit
the Start button, or you hit the
application on the dock. You don’t open a
browser window and then start typing in the URL. Think about all the people
who are not as technically advanced who are in here–
maybe your parents, brothers, sisters. They click on the Start menu. That’s how you start
an application. You don’t go to a URL and
expect it to work offline. If you’re typing a URL
into an address bar, it’s not going to work offline. You can’t Alt-Tab
between applications if you want to go between
different applications. You don’t have that same
level of integration that you expect to have. And that’s where
Chrome Apps come in. Chrome Apps allow you to build
installed native applications that work just like every other
installed app on your computer, but using HTML,
CSS, and JavaScript. Just the way that we’re
used to building modern web applications, we can do
that with Chrome Apps. So let’s take a
look at a couple. I’m going to come out
of my slides here, and I loaded a
couple already today. 500 Pixels, I think,
is one of my favorite because it’s just really pretty. How many people are familiar
with the 500 Pixels website or web service? A few people. They have really, really
pretty photos, when it loads. We are still connected
to the internet. All right, let’s try this. It loaded before, I promise you. Chrome Apps should work offline. That one clearly fails. But let me pull up Wunderlist. We talked about Wunderlist
a couple minutes ago. Here’s Wunderlist
working as a Chrome App. Notice there’s no address bar. There’s no Back
or Forward button. All the stuff that I
need to do, all right. So for my trip to Korea,
yup, prepare presentation. I did that. And pack heart rate monitor. I’ll explain that one
in a sec, but I’ve got a heart rate
monitor on right now. So we’ll take a look
at that in a second. So then you can also do
just really simple things. 1 plus 1. Yes, success. So you can build
anything from apps that need a network
connection to stuff that doesn’t, to things
that are just daily use, everyday utility applications
to complex applications like Wunderlist. You could write,
if you wanted to, Photoshop in
JavaScript, HTML, CSS and get a pretty awesome app. All right. So let’s pop back into here. So Chrome Apps follow
four important pillars. One, we already saw that
one shot down on some apps. But they should work
offline by default. Two, they’re cloud
ready, so they can take advantage of all
sorts of the great APIs and services that are available
from Google or from anybody else. Third, they should be
natively integrated. I tried to find a nicer
sounding word for that, but it really didn’t– that just
does not roll off the tongue. But they should work with the
system and use all of the APIs. And finally,
multi-device capable. That means that
Chrome Apps are going to work no matter what device
you’re using, whether you’re using a Mac, a PC,
a Linux machine. And we’re going to talk about
the mobile experience today. But no matter what you
do, you write your code effectively once, and
it works everywhere. I know, it’s been
said a million times. Nobody believes it. But for the most part, this
is true with Chrome Apps. So let’s jump in and
take a look at what offline by default means. Like any app you install
from any of the stores or app marketplaces, there’s
the Chrome Web Store. So a user goes to the Chrome
Web Store, chooses the app that they want to install,
which then downloads all of the assets and resources
needed for that app to run. Now what does that consist of? Well, there’s two pieces
here that are required. One, we need to have what’s
called the manifest JSON file. We’ll take a look
at that in a sec. But the manifest tells Chrome
what that app, how to start it, how big the window should be–
or not the window, but version number, all sorts
of little stuff about the information
for this app. And then there’s
the main.js file, which tells Chrome how to
start this application. And then finally, you’ve got
all of the application content. So that’s all of the resources
needed for your app to run. So that’s all the JavaScript,
the HTML, the CSS. Now one key thing
to keep in mind when you’re building
Chrome packaged apps or thinking about them
is it requires a bit of a subtle shift in
thinking as a web developer. As a web developer, we
typically think, oh great, I’m going to go write some
HTML, some JavaScript, and that kind of thing. And I’m probably going to have
a Ruby backend, end, or maybe a PHP back end, or maybe
an ASP.NET back end. And it’s going to
spit out HTML as well. So you’re going to
have some server side code running as well. With a Chrome packaged app,
you can’t really do that. You can use client side
code to run all of your UI and all of that. And then you go up and use your
APIs, services, to get data and then display that on screen. So in the manifest–
how many people have tried writing a Chrome
extension or a old-style Chrome packaged app? All right, a few people. So it’s pretty much the same. There’s only a few
key differences that I’ve highlighted here,
including the manifest version, which needs
to say version 2. And then we tell
the app how we want it to start by saying
background and giving it an array of JavaScript files. So if we take a look
at the JavaScript file that’s running
behind here– so this is the main.js that’s required
to run– we set up a listener. And we say, hey, Chrome,
any time the user tries to start our
application, we want to listen for those events. And when that event gets fired,
we want to create a new window and open the index.html file. Obviously, you can
open any file you want. You can open index
or, in the case we’ll look at in a
couple minutes, Hue, whatever you want. You can provide an app ID, which
is really useful so that Chrome remembers where to
open the window, and it stores state
about the window. And you can also say how big
you want the window to open. You can even go so
far as to say where you want the window to open
and additional properties you can set in there. But those are the key
ones that you sort of need to be aware of. So beyond the ability to be
able to work offline– in fact, there’s one other
thing that I want to mention here is that you
get the Chrome Web Store functionality with this. Which means that, like Chrome,
your application will always stay up to date. So when you guys start
using an application today, usually you pull out your phone. You sign into the
app, and it asks you for your username and
password, which you’ve probably created on a website
somewhere, or maybe you’ve signed up on that
app at one point. And you sign in, and
everything’s there, right? If you go sign into a Google
account, use Google Drive, or you use any of your
applications where you sign in, it remembers you, remembers
all your settings. And everybody
expects that today. And they expect
their applications to stay up to date. So with Chrome apps, we
provide the functionality to make that really easy
for you so that you can just go and be good to go. Your apps stay up to date,
and your users always have the data. So there’s a bunch
of APIs that are available that make
this much easier. One of them is this
synced object storage API. And how many people are familiar
with the local storage API? Yeah, OK, so a few people. So the local
storage API lets you store strings on
the user’s computer. Great. But if they go to
another computer, or if you want to store a
JavaScript object, uh-uh. Not going to happen. So with the synced
object storage API, you can store data for
that specific user that will be synced to every
computer that they sign in on. So whether I come
and use my MacBook, whether I use a Chromebook, or
whether I use any other device, all of that data is available
on any of the devices. It uses the same syncing
system that Chrome uses to store bookmarks
and passwords and all of the other information
that Chrome stores and syncs across users. So that gives us
a really great way to store application settings
or maybe state about the user or what they were doing. There’s also a synced file
system that’s available. So that means you can go and
store large files on the user’s computer but know that no
matter what computer they go to, they’re always going to
have access to those files. That means I’ve got
access to my photos across all of my
computers, or maybe all of my documents
or my presentations. So I’ve got all sorts of
file and data storage. But one of the things that
I’ve always loved about Android is the ability to be able
to send push messages to me to tell me about something new. And the web has never had that. Or it has. It’s called spam. I want web apps to
be able to tell me when something is going on or
when there’s new information, or maybe to wake up
and go do something. So with the Chrome
push messaging API, you can actually send
data to a Chrome app and tell it to either
pop up a notification, like you would see
on Android, or you can tell it to go and
say, hey, the user just added a bunch of new files. You should sync these down. Or maybe the user
has a new friend. Woo-hoo. So with their new
friend, you may want to go get information
about their friend so that you’ve got that
next time they connect. So the push messaging
API is a pretty great one and is something that
I’m really excited about. There’s also an Identity
Services API I hate signing in. How many passwords
do people have? And please don’t put
your hand up for this. Don’t tell me. If you use the same password
for every site, yeah. Probably not a good thing, but
it’s really easy to do, right? With the Identity Services API,
if you forget your password, or if for whatever reason,
your password gets compromised, you have to reset it in one
place with the Google APIs. Or if you’re using one of
the other identity services, you can have the user
authenticate to that, and it’ll give back that
authentication token. Then they don’t have to–
let me rephrase that, sorry. Then you do not need to be in
the job of storing users’ names and passwords, because that
just always gets messy. We hear about it on a
regular basis of somebody who’s gone through and
lost every user’s username and password, or maybe
their credit card number. Generally not a good thing. You also get updates from
the Chrome Web Store. So just like you do if you were
to use an Android app or an iOS app, when somebody
pushes up a new version, you get it automatically. Everything is all good. Now on the web, you may
be paying for bandwidth. So if you’ve got
a website, you’re paying for all of those
megabytes or gigabytes, hopefully, if you’ve got
a good website going out. You don’t have to do that
with Chrome packaged apps. You push stuff up. And then we handle
the distribution. So we’re responsible for getting
it to all 10,000 of your users or 10 million of your users. And we eat the bandwidth costs. Go click on a few ads. And then finally,
there’s a whole set of monetization options. So if you want to
start selling apps, you can do either
one time payments or use the in-app payment model. Now the thing that I love about
this is instead of being, oh, 30%, like most other
places, it’s only 5%. And this works anywhere
where Google Wallet works. So I just put a
little code up there so you guys can see
what’s going on. But chrome.storage.sync.set, one
thing you’ll notice about that, I didn’t stringify that. So you can store straight-up
objects in the Chrome storage. Syncs across all
the user’s devices. Really nice, easy way to be able
to handle data across devices. All right. We’ve covered two. We’ve got two more to go. And we’ve got some
more fun demos. In fact, let’s do a demo now. I like doing fun demos. All right. So it’s always fun
to do a demo when you have to get off the network
and switch to another one. So I’m going to cross my
fingers here and switch over to this other network. And let’s bring up this guy. All right. I’m alive. Sweet! OK. So right now, I’m wearing a
Bluetooth heart rate monitor. You probably can’t
see it through here, and I’m not going
to pull my shirt up so that you can see my chest. That will not be pretty. But there’s a heart
rate monitor under here that’s connected to my
computer via Bluetooth. So right now, it’s probably
not a good heart rate for this, but OK. We know I’m alive. Now that light just came on. Did anybody notice that? And it should be
flickering at about 105. I’m dead. Crap. That’s not good. I need to be very
close to my computer, apparently, if I
want to stay alive. I feel like I should be
on an episode of “24.” if you move far enough away
from the computer– all right. So I can’t see if that
light is flashing, but that light should
be flashing right now. AUDIENCE: It’s flashing. PETE LEPAGE: All right. Sweet. So what’s going on
is through Bluetooth, I’m connected to this guy. And I’m going through
and saying, OK, great, getting the heart rate. And then I’m using–
and I’ll open this up so we can see what’s
going on here. I’m using the Philips
Hue light bulbs, which are a really neat
set of LED light bulbs that allow you to control them
by making an HTTP request. So I’m making an HTTP
request to this light every time, for 80
beats per minute. So you can see as
it’s going through, it sets the hue at zero, which is,
if you think about the circle, it sets it at red, the
saturation, nice and bright. And then it goes between
200 and then down to 128. So it’s doing a rate
with my heart rate. All right. So I mentioned that you can
Alt-Tab between these guys. Because I’m running
Chromium right now, this is not something
that’s available. And Bluetooth is still
an experimental feature. Chrome Apps launched in
mid-September for all users. But we still have a few
APIs that we haven’t quite shipped yet because we want to
make sure we get them right, and Bluetooth is one of them. So it’s only available in
either Chrome Dev, Canary, or in Chromium, as I’m
running this guy here. So let me come off of this,
and we’ll pop back to this guy. All right. Do we get back on the network? This is always the fun one. Woo-hoo! All right, sweet. So you’ll notice
in that app, there was no address bar or
anything like that. And in fact, that
app looked different than the Wunderlist app. The Wunderlist
app, in fact, I’ll just bring it up so
that we can see it. It should run. There we go. The Wunderlist app
looks exactly like we would expect it
to look on a Mac. It’s got the little red X, the
minus sign, and the plus sign. But the heart rate
app, it didn’t. It’s only got this X over here. With Chrome Apps, you can make
the app look however you want. If you want to have it have that
native look, you can do that. If you want to give it something
completely different– oh, that wasn’t a good heartbeat. All right, we’re going
to get out of here. So if you want to make the
app look however you want, you can do that. One thing I would
caution you on is don’t go too far to try and
create a native-looking app, because operating
systems change. Or if you don’t put the right
amount of effort into it, and a user goes and uses
something that looks like a Mac on a PC, they’re going
to be really confused. So just be really careful
about how you do that. So these apps get
launched from the taskbar. So if I go down, I can launch
apps exactly the same way. And there’s a whole
set of additional APIs that give me more
native integration. For example, the
alarms API allows me to go through and set
alarms so that applications run on scheduled tasks,
just like setting up a Cron job or a scheduled
task in Windows. Or I can use the
Media Galleries API to be able to go and access
all of the content that is in my media folder, so
like My Pictures, My Videos, and My Music, so that I
have all of that access for those applications,
no matter where I am. But it also means that, like we
saw a moment ago with the heart rate, I have access to
Bluetooth, USB, and even raw networking APIs. So in order to
communicate with the Hue, I was making just
simple AJAX requests. I was just using
jQuery and saying, hey, go just make this AJAX request. But the Hue– I won’t
pick it up– the Hue has this little hub. And in order to find the
IP address of the hub, you can either open
up your browser, go to your networking switch,
go look up the IP address, and then plug that in,
which is not very nice. It’s kind of ugly and a
small pain in the butt. Or you can do an
SSDP query, which is– I don’t remember
what it stands for. But effectively, what you
do is you send out a UDP packet to a
broadcast IP address. And you say, hey, are there
any Philips Hue hubs out there? And then you sit
back and you listen. And after a few seconds, the hub
comes back and says, hey, yep. I’m here. I’m on IP address whatever. Imagine trying to do that
with an HTTP request. You can’t send an HTTP
request to a broadcast IP. It just doesn’t work. So you can send raw TCP or
UDP messages out to any IP. Think about that for a sec. You can do anything you want
with raw network support, which means with Chrome, you
could write your own web browser, which would be a little
silly, but you could do it. Or you could write a web server. So you could have Chrome
acting as a true HTTP server. You could write your
own WebSocket server. So there’s a lot of stuff
that you can do with this, now that you have
full network access. USB means that you can go
and access any USB devices. I was going to try and do
this demo earlier today, and I can’t get my
Chromebook to work on here. But I’ve got a Griffin
power knob here. This is something that
you guys may have seen. It came out maybe two
or three years ago. Really cool but totally
useless electronic toy. Little spinner
dial, so it spins. Woo-hoo, yay. You can push it and
click it once– woo-hoo– or you can push and
click or push and turn. Yay. That’s about all it does. They sold it for $75
when it first came out. It’s about $30 now. If you’re looking for
a fun toy to play with, it is kind of cool. So we’ll take a look at
how I use this in a sec, but that means you
can use devices like this or any
other USB device without the need for
any custom controlled drivers or anything like that. How many of you guys have seen
those USB missile launchers? You can get them on the
little electronics stores. In the States, we
sell them on Amazon. And it’s a Nerf
gun, effectively, but it’s got a little
missile launcher. You plug it into USB. You can control this sucker
with a Chrome packaged app. So there’s lots of
different things that you can do once you
have access to raw network, to Bluetooth, or to USB. So this is actually
one of the commands that I use to control
the spinner dial here. But all we do is say,
set the brightness. You create the object
that you want to have. So in this particular
case, I said, hey, I want– I just gave away the
next half of my presentation– what you want to do. So I want to send a packet
out to endpoint two. And I just want to
send out this data. And that will set the brightness
on the LED for this spinner guy. So quick and easy way
to be able to set that. The hardest thing
about using this is actually to reverse
engineer the protocol to figure out what
you need to send. So I talked a little bit
about Chrome packaged apps should just work on
any device that you use, whether you’re
using a Windows device, whether you’re using a Chrome
OS device, whether Mac or Linux. Chrome Apps work wherever
you expect them to work. Actually, before I
go in there, let’s go check out one other demo. I’ve got to switch back
on my network here. I’ll pop over here. All right. So I don’t have the USB
dial hooked up on this one. There’s a little bit of stuff
that we’re still working on. When you plug this
into a Mac, it sees this as an HID input
device, and our API for that is still coming. But on a Chromebook,
it works just fine. So now that we’re on here,
I’ve created this Chrome app that effectively does the same
thing as my heart rate monitor, except it’s a
little bit more fun. So let’s go here, and all right. So we’ve got a nice green light. And don’t you just love
that shade of green? Well, I like blue better. There we go. We got some blue. And, ooh, that’s kind of pretty. So just by moving these
dials up and down, we can go through and try this. During the break,
after whoever is up next– I think it’s
Jake– after the break, I’ll set this thing
up with the dial, so that if you guys want to
come and just spin the dial, it’s almost as much fun
as spinning a wheel, but you don’t win anything. You can try it. You can play with it
and see how it works. But effectively, we’re just
doing the same thing here where every time we move this,
we’re going through and sending a new HTTP request. Now I would be smacked
upside the head if I didn’t say
that perf matters. So one of the things that I
did while building this app, and you guys should
think about as you’re going through, if I were to fire
an event for every single move here, this thing would
get really unresponsive. It would start bogging down. My light wouldn’t change
as quickly as it does. So as I move this over,
it still doesn’t quite change as fast as I want. So the way that I
wrote this is that I’m using RequestAnimationFrame to
go through and fire and check to see what the value
of this slider is. So this guy’s running
just 60 frames per second, going, OK, has that
slider changed? No. Has that slider changed? Nope. OK. Oh, it changed. OK, now I’m going to
set this new value. So that way, I’m not
firing 255 events as I move that way
over there really fast. I really probably
only fired one event as I ran across there quickly. All right. I’ve got to get back. So these apps should work
everywhere that Chrome works. So whether that’s Mac,
PC, Linux, Chrome OS, they should just work. But one of the things that’s
been really important to us from day one is to
make these apps work across all devices, not
just desktops and laptops, but mobile devices as well. And so this is a project
that’s still under development. You can go try it if you want
to go grab the code at GitHub. The instructions are accurate. I did it last night about
3 o’clock in the morning. It works. I wanted to make sure
I was up to date. Yeah, that’s it. I couldn’t sleep. But that’s going to mean
that your app is going to work on Android or iOS,
using PhoneGap or Cordova. How many people are familiar
with Cordova or PhoneGap? A few people. Effectively, what
Cordova does is do exactly what
Chrome does, where it takes all of the assets and
resources that are required for your app to run, and it
uses a WebView to render those, and your application just works. So you’re good to go. You can be running the
app in the same way. Now obviously,
you’re going to need to make a few changes
to your application, because if you designed
your application like, say, Wunderlist, where it’s a nice,
big screen, that might not fit so well on here. We’ve all seen desktop
websites on a mobile device, and it looks not pretty. So you want to take
that into account. So I said I had spent a
little bit of time last night. So let’s bring this guy up. Well, you all know
my password now, so there goes that
level of security. All right. So does this app look familiar? Well, it looks also
nicely out of focus. But here, let’s– so I’m going
to change this brightness. Let’s bring the brightness up. And the light is kind of greeny. Let’s see if we
can make it blue. All right. So this same app, doing
exactly the same thing, is now running as a
mobile Chrome App. And you know my phone password,
so you can come play with this afterwards, too. So you’ve just got
that same ability to be able to take a
Chrome packaged app and make it run anywhere. And in fact, the process
is intended to be so easy. What we want you
to be able to do is say, type in on a command
line, build a Chrome app. Not quite literally
that, but close enough. Enter. It will then go and create
the Eclipse project for you. It’ll create the
Xcode project for you. And then all you need to
do is go to the development environment and hit
Run, and it just works. All right. So Chrome Apps are a new way
to build desktop native style applications using the
tools and the skills that we know and love today,
using web technologies. If anybody’s tried using any of
the Chrome embedded framework stuff, I was talking
to somebody earlier who’s thinking about
using that, that hurts. That’s just painful. This, super easy. There’s no DLLs to update. There’s no C or C++
code to compile. You’re good to go. You can just write the
HTML, CSS, and JavaScript that you know and love
today, and it works offline. It works with all of
the cloud providers and gives you a great way
to be able to store data up in the cloud. It gives you full
native integration so that you can
Alt-Tab between apps. Users start apps in the same
way that they’re used to. And it works across all devices. Now there’s one other thing
that I’m going to mention. We haven’t talked
a lot about it, but this is something that I
think is really interesting, and when it comes to fruition,
is going to make these apps a lot more interesting. Today, if you go to
the Chrome Web Store using Internet Explorer,
we sort of smile politely, pat you on the head, and
say please install Chrome and then come back. We want to get this
to a point where if you come to the Chrome Web
Store using Internet Explorer or Firefox or
Safari or Opera, you can click Install on
any of those apps, and we’ll handle all
of the magic for you and install the Chrome runtime
on the user’s computer. Won’t necessarily
install the browser, but the runtime will
be there so that you get the same experience
as a developer where you’ve got
the latest Chrome. The user’s got the latest
version of the app. And you’re all set. You’re good to go. And you don’t have
to think about it, and the user has no clue that
they’ve just installed Chrome, and they’re using your app
as a Chrome packaged app. They just know that they’ve
installed this great app that you guys have written. So the link for the
slides is up there. I think I’ve probably got
like five minutes left, maybe three minutes left. About three minutes left. The link to the
slides is up there. There’s also some learn more
stuff there on that last slide. Are there any questions? AUDIENCE: [INAUDIBLE] PETE LEPAGE: Yeah,
so the question was, in the manifest file,
we have a JavaScript file that is our
background script. Does that work on
the mobile device? And the answer is yes. We have a special
set of wrappers that you’ll find at that link
that will go through and look at the manifest file,
look at the main.js file, and figure out how to
package all of that into the Cordova
environment so that you don’t have to do anything. The cool thing is you
have one code base, and you don’t have to
go and screw with it to get it to work
in other places. We’ll handle all
of that for you. All right. I’ll be around after the break. Thank you guys very much. We’ll play with
the lights later. Thank you. [APPLAUSE]

3 Replies to “Chrome Apps: desktop today, mobile tomorrow

  1. Is there a standard way to access USB serial ports from the Chrome App? This integration with hardware is FANTASTIC! 

  2. Looking at the structure and available APIs Chrome Apps seem pretty similar to the Chrome Extensions. Which is awesome!

Leave a Reply

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