>>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.
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.
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.
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.
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.
>>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, firstname.lastname@example.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. >>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.
>>> 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.
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.
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? >>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.
Erik Kay, Mihai Parparita
For all I/O 2012 sessions, go to https://developers.google.com/io/