Chrome Mobile: The Mobile Web Developers Toolkit (Part 2)

PETE LEPAGE: Well hello, everyone.
My name is Pete LePage.
And I'm a developer advocate on the Chrome team.
And today we're going to be talking more about using great
tools for building mobile web applications.
Last week, some of you may have joined me for a special
Chrome Developer Tools session, Mobile Developer
Tools session, where we talked about some of the really neat
tools that you can use, like libraries and
other stuff like that.
This week, we're going to talk about testing and emulation
and other great tools that you'll find will help you to
build great mobile applications.
So like I said, welcome.

So last week--
the link to the slides is there.
There's the Development Environments stuff that we
talked about, the Authoring Framework stuff, as well as
some of the libraries.
This week, it's the Testing and Iteration Flow and some
Performance Tooling.
If you're looking for some other great tools, Paul Irish
has a great session on the Tooling and Web App
Development stack that you can check out.
And these slides will be available
after the fact as well.
If you want to go and follow along or ask questions as
we're going, the link is there at the bottom, right here.
Well, I guess it is not quite highlighting for me right now.
But you can see the link at the very bottom.
If you have questions, you want to post those.
Feel free to go post your questions as we move along.
And I'll take your questions as we go and at
the end of the session.
So let's jump in and talk about some testing tools and
ways that you can better test and see how your environment
works when you're building mobile web applications.
So one of the first things I want to talk about is the
network link conditioners and really sort of understanding
how you can better understand and better test the
experiences that you're getting, when your users are
experiencing their websites on a mobile device.
Because on a mobile device, you can't always count on
having a 3G connection.
Sometimes it may be Edge.
Sometimes, it may be Wi-Fi.
Sometimes that Wi-Fi may be worse than a 3G connection.
Sometimes it may be really spotty.
Sometimes it may not exist at all.
So there are some great tools that are available for testing
on your mobile device.
There's two that I think are really interesting--
Charles Proxy, which is available there.
It's available for the PC, for the Mac, and for Linux.
So you can install it on whatever
platform you're using.
And it will go and basically proxy all the network
connections.
So all the requests that are going through go
through that proxy.
And you can specify how you want it to behave.
The other one that's pretty interesting is the Network
Link Conditioner.
And this is a Mac tool.
This is something that you need to get through the Apple
developer tools.
So when you install Xcode, you can get it there.
And the Network Link Conditioner is installed in
your system settings.
Let me bring it up here.
So I'll bring up my tools, my System Preferences.
And down here at the bottom, you can see this Network Link
Conditioner.
So when I start the Network Link Conditioner, I have a
couple of options that I can choose from.
I can choose the profile and whether I want to
turn it on or off.
So first off, let's go and turn it on.
But let's turn it on for an Edge Good Connectivity.
So if I do this, you can see a couple of
things get set by default.
It limits the bandwidth that my device can connect to the
network with.
So I no longer have the full network bandwidth available.
I only have a 256K kilobit stream.
Also, I'm not going to drop any packets.
But it's going at 350 millisecond delay to all of my
requests on the downlink.
On the uplink, it's going to put in 200K connection speed
and a delay of about 370 milliseconds.
So by turning that stuff on, it's going to slow your
network connection down.
It's going to cause some pretty slow things.
So I'm going to bring up my website because I know my
website is probably not exactly designed for a slow
connection-- so petelepage.com.
And you'll notice it takes a little while for
stuff to come in.
And it takes that extra time.
So basically, what it's doing is pruning down my network.
It's making my pipe smaller, so to speak.
So that way you can get a better idea of how your
network is going to behave under low bandwidth
connections.
It's a really good way of testing and understanding.
Through here, you could also go in.
And you can set things like hey, I want to see what a LASI
network is going to look like.
So notice here, we've got 1% packet dropped and a 440
millisecond delay.
I guess it really helps to turn this guy on.
So I'm going to go ahead and turn this on.
I have to enter in my password, so
turn my password on.
Let's just make sure I got turned on here--
on.
So now, petelepage.com--
I guess I didn't get it on earlier.
So now, let's see how long this takes to load.
Again, much slower, so before, we saw it
load reasonably fast.
Now, we're still waiting for content come down.
We don't have that section on the right.
So I can see that the important content on my
personal website comes up pretty quickly.
The thing that I want people to be able to see here, on the
Thinking About, comes up pretty quick.
But the other content is going to take a while to load.
When the Network Conditioner is running, you've got this
little guy up here telling you, hey, it's up and running.
And so you can bring it up really easily, if you
want to change it.
If you want to go and say, hey, I'm on 3G or whatever,
you can turn that on and off pretty quickly-- really
easily, without having to go fight through lots of stuff.
It's a good tool to be able to use and understand.
Charles Proxy is a really powerful as well.
Charles Proxy-- one of the great things about it is it'll
do all of your network connections.
And it gives you a lot more inspection ability.
So you can go in and see what's going on with a
particular request.
You could take one specific request and
make it take forever.
So you drop one specific request, if you're doing a lot
of XHR requests or something to that effect.
It's a good way to be able to specify some of
those things in there.
On Android, if you want to do this on a
phone or on a tablet.
You can do it on a phone or tablet as well.
On Android, you can set up the proxy to go through a
particular device.
So it's kind of buried in there.
I'll get a blog post out or something up on the Chrome
developers page in the next day or so, to talk about that.
But you can go in, and you can turn that proxy on, so that
you can actually use that.
Under iOS 6, if you have the developer tools turned on, you
can turn on the Network Link Conditioner in there as well.
So that you can see how the network conditioner works on
that particular device.
You can test it, again, in a specific scenario, to
understand how things are going to work, how they're
going to behave.
So let's go ahead and close that and go back
to our slides here.
So faking it with the Network Link Conditioner is just one
way that you can understand how your app is going to work
for your users, who may not be connecting with the same great
bandwidth that you're connecting with.
One of the next things I want to talk about is some of the
developer tools within Chrome.
Because Chrome offers a lot of great tools to help you test
your web application.
And I call it faking it because it provides an
emulation experience.
It's not going to be a true experience because you're not
running on the same hardware.
The processor on my Chrome OS machine or on my Mac or
anything like that is obviously much faster than it
is on my phone or tablet.
But at least I can be able to go, understand
what's going on.
And I can get a pretty good sense of how
these things are working.
So there's a couple of things that you can do in the Chrome
Developer Tools.
So I'm going to bring up the Chrome Developer Tools now, so
that we can see what's going on here.
So I've got the developer tools up.
And I'm going to click on this little guy here in the bottom,
the little gears icon for the settings.
When I bring up the settings, if I go to Overrides, I can
change a number of Chrome settings.
So first off, I can change my user agent.
So I can fake out to my server what browser I'm running as.
So I could say, hey, I'm running as an iPhone iOS 4.
And so sure enough, it shows here what my user agent is.
You can see it showing up there.
But it also automatically turns on the device metrics.
Now this is one of those things that I think is really
powerful and really, really useful to web developers.
Because what it does is sets the screen resolution to the
same screen resolution that I would get if
I was on that device.
So in this particular case, it's got 640 by 960.
So it's setting my screen resolution to the right size.
It turns on a font-scale factor, whether it's going to
scale my fonts or not.
So you've got the device metrics.
So you can see what your experience is
going to look like--
much easier to do this than it is to resize your browser.
I'm sure everybody has done it here before, where you try and
resize your browser down to exactly the right size.
And getting it to that particular size you want is
just a pain in the butt.
So this is a good way to be able to go in and say, hey, I
need a particular screen size.
So sure enough, there's the screen size.
You can see these things are rendering as I expected it.
One of the next things that you can do is overriding the
geolocation position.
So you can fake out to the browser where you are.
If you want to say, hey look, I'm in New York.
Or I'm in Mountain View.
Or I want to go test something.
You can go in, and you can specify the latitude here and
the longitude here.
So that you can say, hey, this is where I am right now.
I want to just take my word for it that this is where I
am, in case you're doing any kind of geolocation testing.
And you can also say, in particular, I want to emulate
a particular position.
So I want to say emulate position unavailable, which
may happen, maybe, if you're in a nice cement room where
you can get a location.
Or maybe just the user chooses not to provide a device
location, going in and being able to specify exactly the
location or whether the location is not available--
another one.
You can go in.
And you could also do device orientation, how the device is
with the alpha, beta, and gamma channel.
And there's a great article up on HTML5 Rocks, if you want to
understand how those guys work.
One thing to keep in mind when you think about that is all of
the alpha, beta, gamma is how you would
normally hold the device.
So in some cases, I'd hold my device like this.
But on a different device, you might hold it like
this or like this.
So both of those are all things that you need to take
into account for the device orientation and
device motion stuff.
Finally, on here, you can see the Emulate Touch Events.
So that's going to simulate touch events and fire the
touch events at the same, when I click on things.
So those are all available.
I think Device Orientation is available in beta.
It's not available in the stable channel yet.
So if you need to go in and check, you
want try one of those.
Go have a quick peek in the in the beta or even in the Dev or
Canary or even in the Chromium Channel.
There's a couple of new ones that are coming soon.
Let me pull up Chromium for a sec because I think this one's
kind of neat.
So I'll bring up Chromium here.
And I'll just go to google.com, bring up the
developer tools.
Again, same thing, go click on the little guy here.
And under overrides, I now also have Emulate CSS Media.
So that I can go in and say, hey, in this particular case,
I want you to pretend that I'm a print device.
And I want you to show me what the page is going to look
like, if you're applying the print style.
Rather than having to go hit print every single time to see
what it looks like and look in the print preview, you can
just go apply that print style.
Maybe you want to go to use a different one, like screen or
projection or something like that.
You can go see how all of those look.
So easy way to go do this-- and if you're ever curious
about what's coming and what's down the pike, always check
out Chromium.
My general recommendation, if you're sort of looking to stay
on the edge, but you want something pretty stable.
And you want to be able to test some
of the newer features.
It's to install Chrome Beta or Chrome Stable as your primary
browser experience and then install either Chrome Canary
or Chromium itself.
And that way, you'll always have the latest.
You'll always have the greatest.
You can see what's going on in the fun new stuff.
And you can see what's going on in the
stable, regular thing--
how most of your users are going to see things.
I personally like to go with beta.
So that way, I'm a little bit ahead of the curve.
And if the bug gets introduced on something or maybe
something changes, I'm going to see it before my users are.
And that, to me, is really important.
I want to know about these things before my users do
because I want to make sure that I've got a great
experience.
So a bunch of great Chrome dev tools--
there's a bunch of great sessions available on Google
Developer Live that go into much more depth on how to use
some of these dev tools.
I just sort of wanted to give you a good introduction to do
a couple of these things.
So let's move on to the next one and talk
about some of the emulators.
Emulators are a great way to get an idea of how things
might work.
Is it going to behave how you expect it to behave in the
native environment?
Now again, you're not going to get the exact performance
characteristics.
And there are some things that may or may
not work in the emulator.
For example, the camera doesn't work in the emulator
for most of these devices.
But it does work in other places.
So it does work on the device.
But most other things work.
So there's a few places where this is a good way
to go and do this.
So there's a couple of good emulators available.
There's the Android emulator, which I've got linked there.
It's a quick, easy thing to install.
It's not exactly the fastest thing.
But it's pretty decent.
And it does give a fair representation.
If you install Xcode, you can go and get the iOS simulators,
which will give you the iPhone and iPad, the iPhone
5, the iPhone 4.
In fact, it'll give you quite a few.
Let me bring up one of the iOS simulators.
So when I bring up the iOS simulator, sure
enough, here we go.
We've got Safari running right now.
Let me make this a little bit smaller, so that
it's nice and small.
Here we go.
So you can see that I've got Safari on here.
I can start Safari.
It starts up pretty quick.
If I go to type in here, I can go click on this and type
HTML5rocks.com.
It just uses my network connection to go pull this
stuff down, shows me exactly as I would
expect things to be.
So in this particular case--
and it also responds to touch events.
So in order to scroll, what I have to do is go click on the
page and then scroll up.
So I've got that sort of real experience, as I'd expect it
to behave on a true device.
If I go back up to the top and I want to go search here, I
can click on in here.
And if I wanted to type-- so I said device orientation.

You can see this would take me forever-- device orientation.
So sure enough, I go click on that.
I should get some results here.
And sure enough, here's that device orientation article
that I was talking about earlier.
So we can go through, scroll, and see all the stuff that
we're looking for.
So there's a good, easy way to be able to
go in and test this.
You can switch between different hardware.
So you can change from the iPad to the iPad Retina to an
iPhone, whatever you're looking to test.
That same is true for Android as well.
You can try different devices.
You could try different characteristics on those
devices, whether they have a keyboard, whether they don't
have a hardware keyboard--
so quick easy way to be able to go in and do these guys.
So let's go back to our slides here and
continue on from here.
The other one that's worth checking out is Browser Stack.
Browser Stack is a great tool that you give it a link to
your site, and it'll go render it in several different
browsers and give you the screen shots.
And in fact, I believe on this one even gives you access to
the DOM, which is pretty slick.
Because you can go in, and you can try seeing how things
behave in the DOM.
But emulators are only so good.
We want to be able to test these on real devices,
understand how these are going to behave in a real scenario.
So let's have a look at how you'd use one
of the remote debuggers.
And actually, we'll have a look at a couple
of the remote debuggers.
You can do remote debugging with Chrome for Android on an
Android device.
You can do with us Safari on iOS 5 and Safari 6.
And you can actually do it on Firefox as well.
And I've got all the slides that walk you through the
instructions on how to do this.
And you can follow the instructions
along on your own.
So for Android, the first thing you've got to do is--
on all of these, there's a one-time set-up experience.
You have to go set a few things up, turn debugging on,
that kind of thing.
So for Android, we need to install the
debugger for the SDK first.
Once we've done that on our mobile device, we need to
enable USB debugging at the OS level.
If you've got a phone that has not ever gone into developer
mode before, you're going to have to go through clicking--
I think it's you click on the About Phone Settings like
seven times.
And that brings it up.
If you can find the developer USB Developer Options in the
Settings menu, just a quick search.
You'll find it pretty quickly.
Once you've got that done, we need to open up Chrome and we
need to enabled the web debugger within Chrome.
So once you've done all that basic stuff--
I've already done all that stuff on my device.
Let me bring up the device down here.
So I've got my device.
And I'm going to unlock it here.
So let's bring up Chrome.
And so we'll go to HTML5 Rocks.
I'm just going to grab my phone--
so HTML5 Rocks.

And this will take a second and load.
Let me zoom this in just a little bit, so you can see
this a little bit better.
All right.
So now that we've got this, there's a couple of things
that we need to do.
On our desktop, I'm going to come out.
And we need to run ADB forward.
Now, I have this set up as a script.
So I'll just show you what my script says.
So you can see here it's adb forward tcp 9222 and then
local abstract.
I recommend just having a little script to do this
because it's a heck of a lot easier than it is to go and
remember that all the time.
But what this does is it connects through my USB port
to my device and allows me to do remote debugging.
So I'll do Clank Debug.
It's gone and run.
So now, when we go back to Chrome, let's
go open a new tab.
And we'll go to local host colon 9222.
So at this point, we get two windows that pop up.
So we've got the Mobile Web Developer Toolkit and the
HTML5 Rocks.
So when I click on this, it opens up the dev tools, just
like I'm used to seeing on my computer.
But this is now showing everything
on the mobile device.
Now, I've got the standard resources, so I can go see all
the files that have been pulled down.
I can go.
And if we reload this page-- so let me go hit reload here--
you can see all of the network requests coming in.
So we could see how everything is going.
We can see all the scripts that got pulled down.
So if I go and click and say, OK well, let's see what this
script looks like.
OK, lots of great stuff in here.
The timeline to understand what's going on--
again, all the stuff that you're used to being able to
use and see within the Chrome Developer Tools are all
available here for you, right now.
So in particular, what I want to go do is show you a couple
of things in here.
Because it behaves just like it does on your desktop.
I can go in.
And sure enough, notice how in the actual device, as I
highlight through different portions, if I go and expand
my header, so there is that hyperlink there.
I can go through.
And I want to actually go, and let's find where the main
content is here.
So I think my main content is-- where are we going here--
content.

There we go.
I think that's our content.
OK, so div--
I'm going to expand this out.
And so there's that.
So now, we could start going through and finding all of the
different pieces that we want.
And we can go through and change these things.
So I'm having a hard time finding this.
I always love going for these kinds of things--
live sessions.
Let's go up to Nav, Unordered List, expand this.
And instead of it saying Home, let's say Pete was here.
And sure enough, if we go have a look at our page--
well, we're replacing those with images.
So of course it's not going to show that
particular right now.
But let me try.
Let me see if I can get a different one.
I'm pretty sure it won't work.
But Pete was here.
Yeah, there we go.
All right, so we've got Pete was here.
So you can go through.
You can change all the things that you'd expect to normally
be able to change, within the Chrome Developer Tools.
Nice, easy way to be able to go in, understand what's going
on, and build your website, your web application, without
too many things.
You can apply styles.
Now, the one thing to keep in mind, this is being served
from the developer tools on the device.
So you are getting the Device Developer Tools.
So currently, this is Chrome that's available in the
marketplace.
It's Chrome 18.
So you're only going to have the
standard Chrome 18 features.
So if I go down here and I bring up my settings, I don't
have the ability to be able to change my UA string.
Actually, yes I do have the ability to
change my User Agent.
But I don't have the ability to be able to go and change my
device metrics or anything like that.
Now, obviously, it would be a little weird change the device
metrics on something that's already a little tiny, but one
of those things you may or may not want to do at some point
in the future.
Certainly, setting geolocation is something that's
interesting and that you might want to be able to do.
So with that, let's get out of here.
So that's the Chrome remote debugging.
It give you easy access to be able to go through and debug
Chrome, remotely.
Let's take a look at how you'd do Safari, on iOS
6 and on the iPad.
So again, very similar, there's an initial set of set
up that you're going to need to go through.
And I'm going to just switch out some devices here.
So that I can plug-in an iPad in.
And we can get this connected.
Now, again, one of the key things that you need to be
aware of is that it does that same thing where it needs to
be connected directly to your device.
So you need to plug-in via USB.
And your device is connected.
So now, let me bring up our device.
So we can see what's going on here.
So here we go.
We've got we've got my device.
And the set up settings are pretty much the same.
We need to go through, and in Safari, on our iPad or on our
iPhone, we need to enable the Advanced Settings, so that we
can go in and actually see what's going on.
But we also need to, on our computer, go and to turn those
things on as well.
So that we've got them set up there as well.
So sure enough, I've got my iPad up and working here.
So you can see that we've got everything running.
And so now, very similarly, we're going
to do the same thing.
So I'll start up Safari.
And we'll come out of the slides--
and Safari.
Great, so Safari comes up just as we would normally expect.
I'll make this full screen, so that we can see
everything going on.
Here we go.
And what I'm going to do is go to the Develop Menu.
And you'll notice that your device shows up, in the
Develop Menu.
So I go and click Pete's iPad.
And it shows me all of the tabs that are currently open.
So I can go and click on HTML5 Rocks.
And sure enough, there it goes.
We've got my page up, open, and ready
for me to start debugging.
Now, these are the Safari developer tools.

So if you're used to using those, you've got the ability
to be able to do all of the things that you'd expect to be
able to do.
And notice, as you start going through these things, you get
that same experience.
So let me just bring this down, so that we can see this
a little bit better.
And I'm going to zoom in just a little bit more, so that we
can see this.
So again, same thing, I'll open up the
header, open up my Nav.
And again, here's my unordered list.
And Posts and Tutorials--
I'll change this.
Pete was here.
And sure enough, can we see that there?
There you go.
So it says Pete was here.
So you've got that same set of tools, same set of abilities,
to be able to go in and do remote debugging as you'd
expect to be able to do.
So this is a really great way to understand what's going on
with the experience.
How are things working?
Is something going a little bit weird?
Is something maybe not acting like it you'd expect it to?
Is it pulling down different data?

On this device as well, you do have the ability to be able to
get in and turn on the Network Link Conditioner.
Let me see if I can find that real quick and show you guys.
But it's under Settings and under the Developer Tools.
I'll see if I can find this here real quick.

Of course, I'm not going to be able to find it.
Well, I didn't plan on showing this.
I was thinking about it after the fact and thought it might
be kind of cool to show.
But I don't see it.
So I won't show it today.
It is a way that you can be able to go and set the things
that you want.

All right.
Well, you can trust me that it is in here somewhere--
a quick, easy way to be able to go in, set up the network
settings, and turn on the particular things that you
might be looking to do.
So Firefox has the same set up, or a similar set up.
One of the key differences on the Firefox set up, that I
really appreciate in their particular set up, is that you
don't necessarily need to connect the device via USB.
You can actually do it over the network.
So as long as both devices are connected to the same network
and on the same subnet, you can connect in.
Again, there's a bunch of set up that you need to go to.
On the desktop, you're going to need to
enable remote debugging.
And on the remote device on your mobile--
either your phone, your tablet,
whatever you need to do--
you need to go and turn on the debugger.
You need to turn on the local debugger, set that to false,
so that it sends all the connection out.
In fact, let's see if we've got it set up.
Actually, I tried it earlier today.
It didn't work.
I don't want to go and try it again.
I think the reason it didn't work is I just didn't have the
same subnet set up.
Or there's some kind of firewall rules within our
subnet that prevents that from happening.
Again, you can go check at the link there, where you can see
how to get more instructions on getting that set up.
But it's a pretty easy way to be able to go through and see
how your experience is going to work.
One of the other really important ways that you can
test your devices and this is something that is, I think,
super important.
And I really want to encourage the community to go out and
participate and help with these Open Device Labs.
But the concept behind an Open Device Lab is to have a space
where anybody can come in, test their web application on
the variety of devices that are out there.
When you think about the cost of maintaining multiple
devices between all the different versions, the
different operating systems, the different sized screens,
the different processors, all of a sudden that becomes a
pretty complex and almost nightmarish experience to do.
And so to be able to go through and use something like
an open device lab where there's just tons of devices
available, and not just the latest and greatest devices,
but also older devices that have been around for a little
while or devices that are newer but have the original
version of their operating system on them.
So having those open device labs are a
really fantastic thing.
If you have spare devices you're not using anymore,
donate them to your local device lab.
Or if you're in an area where there's not an open device
lab, start one.
Find some folks.
Find a location where you can help start your own open
device labs.
There's a great blog post here that talks about all of the
open device labs, as well as where you can go to find them,
as well as how to start your own.
There's a couple here.
There's one that's just starting in Brooklyn.
We're trying to get one started in Manhattan.
There's one in San Francisco, I believe,
just getting started.
There's one in Oakland.
We need these all over the place.
We need these are all around the world, so that developers
have a place where they can go and test their applications,
where you can go, where I can go.
Because I don't have every device.
And I'm sure you don't either.
And you probably don't want to maintain all
those devices either--
crazy, crazy amounts of work to go do that.
So with that, I've got a couple of favors to ask before
I start taking some of your questions.
I will just bring up slides so that you can have a look.
If you've got questions, you can post them there to that
Google short link.
And I'll take your questions here in a minute.
But we need your help.
We can't accept the status quo with web development.
It just simply doesn't work anymore.
And we need developers to really push the limits of
what's cool, of what's available, and
just do cool stuff.
If you're building something, don't accept
that, oh, it's mobile.
So it's kind of going to be slower.
It's going to suck.
Don't accept that.
That's not a good answer.
Go build awesome for the web.
If you find bugs, if you find things that don't work as you
expect them in Chrome for Android, tell us about them.
We want to hear about them.
You can go File bugs at new.mcrbug.com.

Also, go there.
Have a look to see what bugs are already filed, and star
the things that you think are important.
Do you think it's important that there's an ability to be
able to hide the address bar?
There's a bug for that.
Go star that if you think that's important.
Reliable viewport control, there's a bug for that.
We've got lots of bugs filed already.
And we want your help to make sure that we're making Chrome
for Android the best browser that it can be.
If you're building cool stuff, tell us about it.
When we launched Chrome a number of years ago, one of
the things that we did was launch Chrome Experiments,
which was sort of this playground for people showing
off the cool stuff that they built on the web.
Well, when we launched Chrome for Android back in June, we
wanted to say to developers, show us the cool stuff you're
doing on the mobile web.
Show us cool.
And it's a great place where you can show the rest of the
world all the cool stuff that you're doing
with the mobile web.
So build some cool mobile experiments that work great on
mobile devices, that take advantage of the unique
capabilities of a mobile device-- maybe touch, maybe
device orientation, maybe multi-touch--
but works beautifully on that small screen and just is an
awesome experience.
Show us those things.
Show off your skills.
Show it off to your friends.
Do neat stuff.
Start an open device lab in your area, if you haven't
started one.
Or you haven't seen one in your area.
Or you think it's important.
Go do it.
We'd love to have more of these.
It's really important to get these out, to get access to
these devices.
So that we can build more cool stuff and make sure it works
on the plethora of devices that are out there.
But really, the mobile web is what you and I make it.
We have an opportunity to build absolutely cool.
We have the ability to do amazing stuff.
And it's up to as web developers to go do it.
So don't accept the status quo.
Go build cool.
So with that, I'll open it up to your questions.
I've seen already one question in our moderator, as well as a
bunch of other places.
These slides are available if you want.
Let me get rid of this guy here for a sec so that you can
see the slides.
But the slides are available.
It's always kind of fun to do this.
I do this a little backward.
See the slide link is right there.
Yes, so the slide link is right there.
You can go check out these slides yourself, as well you
can watch last week's session, where we talked about some of
the libraries and other stuff that is important for mobile
web developers.
I'm going to be back in the new year, doing more stuff for
mobile, talking about High DPI, multi-touch, all sorts of
stuff that really is relevant to the mobile web developer.
If you're building for the mobile web, you want to tune
into these sessions.
We'll try and do them at least monthly, if not more.
Because there's a lot of really great stuff out there.
So with that, I'll take your questions.
Pop this guy up, and let's just go to me.
So you get a nice, big picture of me.
So one of the first questions that I've got--
during my session last week, I'm just reading it off the
screen here.
"During session one, you mentioned to avoid relative
and absolute positioning.
Why?
Can you explain a little bit about that?"
Yeah, absolutely.
Relative and absolute positioning on a mobile device
can be used.
But you need to use them with caution.
Because when you start thinking about, I want to move
this div, for example, over 600 pixels, on a mobile device
that's maybe only 320 pixels wide.
You're going to move it off screen.
So as you think about using absolute and relative
positioning, you need to be very careful that you're not
using pixels, but instead of using either percents or--
there's a new unit that you can use--
I don't think it's landed everywhere.
I think it's only landed in a couple of places.
But Viewport width--
so you can actually say, 1% of the Viewport width, I want to
move it over.
So you can move a div or element
over a specific amount.
So as you think about using absolute and relative
positioning, just think in terms of the size of the
screen that you're working on.
So I guess I should have been a little bit
more clear last week.
It's really about being careful and not moving stuff
over that will show up off screen.
Because it may just show up in the wrong place, may not even
show up on the device anymore.
So the next question that we've got is--
what's going on with Chrome for Android for--
"What's going on for Chrome for Android?
Are we going to see another release this year?
Are we going to get more developer tools, like some of
the stuff you showed us earlier?"
So that's a great question.
The end team is working on trying to get sort of feature
parity between the mobile and desktop version, get us to the
same version.
On desktop right now, I think we're running 24 or 25.
On mobile, we're only at 18.
When they started working on Chrome for Android.
They had to do a fork to the code, to be able to make some
changes and all that.
They're almost done, if they haven't already finished
integrating all those changes back to the
main Chromium tree.
Now that's done, they're going to be able to go through.
And we'll be able to see, hopefully, more frequent
releases soon.
I don't have a date for you on when we're going to see the
next release.
I've got my fingers crossed that we're going to see it
really soon.
But I'm not going to hold my breath on the specific date or
tell you a specific date because I'm
not really 100% sure.
We want to make sure we get this right.
We want to make sure that we're giving you the right set
of tools and the right set of resources that you need.
So that looks like that's the end of the questions.
I want to say thank you guys so much for joining us, or
joining me.
It was a great session, I think, today.
I hope you learned a lot.
Be sure to check out session number one, so that you see
some of the stuff that's going on.
My name's Pete LePage and thanks for joining me.
I hope you have a really great holiday.
And we'll see you next year.