Google I/O 101: Developing Mobile Websites with Chrome for Android

MIKHAIL NAGANOV: Hi, my name is Mikhail Naganov.
I'm a software engineer at Google working
on Chrome for Android.
In this video, I will talk about building modern mobile
websites using Chrome for Android and
Chrome Developer Tools.
Not surprisingly, a mobile web site runs in a browser, just
as a regular website.
But it's more than just a simplified version of the
desktop web site.
A modern mobile website takes advantage from the fact that
it runs on a mobile device and integrates itself
tightly with it.
Chrome for Android and other mobile browsers offer APIs
that allow web sites to implement first class touch
support, tactile feedback, and provide access to the current
device state, such as orientation and geolocation.
This makes it possible to create websites that are very
close by their look and feel to native mobile applications.
The question is, what are the advantages of implementing
your application as a mobile website versus implementing it
as a native application for mobile platforms?
First of all, you have to deal with a single platform, HTML5,
which is implemented uniformly across
different mobile platforms.
This is a great saving of effort if you compare it with
the need of porting your native mobile application
across different implementation stacks of
various mobile platforms.
Also, languages used in the HTML5 platform, JavaScript,
HTML and CSS, are high level languages that make
programming a lot easier to compared to native
applications programming.
Browsers are hot at the moment, and they are all
evolving very fast.
New features are added literally every month.
Having ported Chrome to the Android platform, we intend to
follow Chrome's release program and provide beta and
developer channels for you to preview the new features.
It's also simpler for users to get access to websites, as
they require no installation procedures.
And updates to new versions are invisible because they
don't need modifications on the client.
From a security standpoint, web sites provide a different
model than native applications.
They run in a browser sandbox.
The user is being asked by the browser to confirm a
permission for an action, for example, to
access user's location.
As soon as the action takes place, instead of providing a
long list of permissions during applications
installation, that's now what it usually takes care of.
There are several points that you need to keep in mind while
planning the development of your mobile website.
I will name the most important of them.
First of all, there are a lot of different
devices in the wild.
We have cheap phones with small screens on one side of
the spectrum and high-end phones with high density
screens and tablets on the other, and everything you can
imagine in between.
Not mentioning that every device can be used in the
portrait or a landscape orientation.
Obviously, your site needs to be ready for that, and might
need to provide different layouts for
different types of screens.
And then touch input requires a different strategy comparing
to traditional keyboard and mouse input.
On one side it's more intuitive, but on the other
it's less precise than using the mouse input, and typing on
an on-screen keyboard is much slower than a physical one.
Mobile devices have less computing power than regular
computers, and the power consumption question
is vital for them.
There should be no waste of precious CPU cycles in your
application.
Network connectivity might vary depending on where your
user is situated.
Your website must be prepared to work without any network
connection.
Happily, most modern browsers support offline storage and
can inform your website about the current
state of the network.
There is a problem that a lot of mobile users are stuck with
outdated mobile platform releases, running old versions
of browsers.
But as I have mentioned earlier, we intend to shake
this situation up by updating Chrome for Android as often as
the desktop version.
By the way, it's a good idea to get the most from your
desktop Chrome browser debugging features while
developing a web site for mobile.
Developing on a desktop is more convenient and involves
less set up steps.
What mobile features can be tested using Chrome Developer
Tools and third party tools on your desktop?
Surprisingly, a lot.
In the recent versions of Google Chrome, you have an
ability to override user agent strings with the ones used in
mobile platforms.
And what's even more important, Chrome Developer
Tools can automatically adjust your window size to the size
of the device screen.
Also, it's possible to emulate touch events with your mouse.
Multi-touch event simulation is also feasible, although
setting it up is more involved, and perhaps it will
be just easier for you to test it on a
physical mobile device.
It's awesome that you can develop and test the lion's
share of your mobile website functionality without even
running an emulator.
It would be ideal if you could do everything on desktop, but
unfortunately some of mobile environment specific features
should be tested on real devices.
Of course, you can't provide the same interaction
experience from desktop, just because your desktop or laptop
computers feel differently from mobile devices.
For your website to provide intuitive interaction, it must
work with a real device and strive to make the interaction
as natural as possible.
Obviously, hardware platforms of mobile devices are
significantly different from desktop boxes.
And actions that are performed with ease by powerful desktop
processors may significantly slow down
their mobile siblings.
Not mentioning the GPU acceleration pipeline is
different on mobile devices.
As with regular web site development, you need to test
your site on real browsers, because even despite the fact
that many of them are based on the same rendering engine,
differences in versions and vendor patches may
significantly affect the behavior of the website.
And the last important point is network connectivity, that
I have mentioned before.
Although it's possible to try to simulate different
networking conditions on your desktop by inserting
artificial delays into network packets processing, or drop in
packets, the setup of such tools is usually complicated.
While on a real device, you can easily switch between
wi-fi, 3G, and 2G network connections to model network
conditions that end users may have.
And now let's proceed to the most exciting
part of this video.
Demos.
I will be using the laptop computer and a tablet running
Android Ice Cream Sandwich with
Google Chrome for Android.

Here we have a simple web page that draws a rotating Chrome
logo using HTML5 canvas element.
And you can interact with this Chrome logo by touching it.
You can slow down its rotation by putting your
finger on it like this.

You can also resize it by holding it with one finger and
dragging the second one like this.

Let's see what can be tested on your desktop by using
mobile features emulation, available in the latest
version of Chrome Developer Tools.
If you're a web developer, we strongly encourage you using
Chrome Developer channel releases, or Chrome Canary
releases to get access to the latest features
that we have in Chrome.
Now I'm running my page on the desktop version of Chrome.
Let's open Chrome Developer Tools,
then open their settings.
And here you can see the user agent group of settings.
By using it, we can emulate screen sizes of mobile devices
and emulate touch events using the mouse.
After I set my user agent setting to Nexus S and have
device metrics override enabled, you can see the tab
running the application will have the same pixel dimensions
as the screen of a Nexus S4.
And they can switch between portrait and landscape
orientations by pressing this button.
Touch events emulation is also pretty straightforward.
You just need to check the corresponding check
box, and that's it.
Pressing the left mouse button will generate touchstart,
touchmove, and touchend events.

Setting up for remote web debugging is really easy.
First you need to make your website accessible to your
mobile device.
To achieve this, I will connect my laptop and my
tablet to the same Wi-Fi router.
And I have a website running on my laptop.
And in order to connect it, I need to know
my laptop's IP address.
Now I'm entering the address in Chrome on the tablet, and
here is my application.
For setting up remote web debugging, we need to perform
several steps.
These steps are documented on the Google Developers site.
First, you need to connect your device to your host
machine using a USB wire.
Then, you need to enable USB debugging in the device
settings and enable USB web debugging in Chrome.
Chrome for Android will open a port for remote debugging, and
you will need to forward this port to your host machine in
order to be able to connect it.
You will need to have Android SDK platform tools installed
on your host machine.
And after that, you will be able to navigate to the remote
debugging landing page from your
Chrome browser on desktop.
So I'm connecting my tablet to the laptop by USB.

Now I'm going to the DY settings and
enabling remote debugging.

It's also recommended to enable the stay awake setting
so your screen will not go to sleep.

Now in Chrome, I'm going to the Settings panel and
enabling remote debugging there.
After that, your mobile device is all set up.

On my laptop, I'm issuing a port forwarding command, and
my local port, 9222, is being forwarded to the remote web
debugging port opened by Chrome on the tablet.
So when I'm navigating to local host 9222 on my laptop,
I'm getting straight to the remote debugging landing page,
and can start debugging.

So let's check how our application
works on the tablet.
To our surprise, the touch handling code that was working
pretty well on the desktop doesn't behave as it should on
the tablet.
Let's investigate that.

In the Developer Tools I'm going to the Event Listener
Breakpoints sidebar and setting a breakpoint on the
touchmove event.
Now when I touch the application, the debugger
breaks into my application execution at the entry point
of the event handler.
Now I'm using Developer Tools' live editing feature to insert
some logging into my event handlers.
As I press Command+S, the code is being sent to the device.

Now I'm switching to the console tab, and here I can
watch in real time how my event
handlers are being invoked.
You can see as I'm touching the screen, I see console
messages appear in the console.
Now we can see the problem.
Our application only receives a touchstart event, a couple
of touch moves, and no touchend.
I'm running a developer version of Chrome for Android,
and it seems to have a problem with following touch events.
This doesn't happen in the desktop version of Chrome.
That's why on the desktop, our application was working fine.
Actually, what you anyway need to do in the touchmove handler
is to call event.preventDefault in order
to prevent the browser from attempting
to scroll your content.
This prevents the touchmove event from being processed by
the browser, and it just passes the event to our
application.
So now after sending this change to the tablet by
pressing Command+S, the application should start
working properly.
Yes, it works, and we have finally tested the behavior in
multi-touch.
It also works great.
Now let's try to take a CPU profile of the same
application running on a desktop machine and on tablet,
and see if we can spot any differences.
As drawing a Chrome logo isn't a very CPU intensive task,
I'll add a code that displays ten thousands of points on the
screen, setting their color depending on whether they get
into the Chrome logo or not.
I'm selecting the line of code and invoking Evaluate in
Console command on it.
As you can see, the frame rate has dropped significantly.
Now I'm doing the same thing on the tablet.
Here the frame rate drop is even more visible, as the CPU
is slower than on the laptop.
Now let's take CPU profiles on both devices and compare them.
First I'll make the size of the window on the desktop
browser the same as on my tablet, 1280 by 800, with the
help of Developer Tools.
Then I'll make radiuses of Chrome logos to match.
I will look at the size in the console for the mobile side
and copy the value to the desktop side.

Now I'm starting CPU profiling for the site running in the
desktop browser.
OK, we're done.
Now I'm doing the same for the mobile browser remotely.
Done.
Let's compare the profiles side by side.

What you can see is that time shares for the same functions
are significantly different between
desktop and mobile versions.
The function named program is the native code
of the browser itself.
This may happen due to several reasons.
Different CPUs, different versions of the V8 Javascript
engine used, and differences in X86 versus code
generation in V8.
This experiment confirms my statement that running and
debugging your site on a real device provides a great
insight and reveals new aspects of the site behavior
that can't be seen while debugging on desktop.
Thanks to Chrome for Android USB debugging feature, the
experience that you have is as good as for the desktop
version of Chrome.
Thank you very much for watching this video.
For your convenience, here I'm providing some
useful links for you.
First of all, we have a page on the Google Developer site
that contains the setup instructions
for remote web debugging.
If you want to know more about using Chrome Developer Tools,
there is a section on Google Developers site for you.
If you happen to be on Google I/O, I would highly recommend
attending the Chrome Developer Tools session for a deep dive
into advanced development techniques.
That's it.
Thank you and goodbye.