Google I/O 2012 – So You’ve Read the Design Guide; Now What?

Google I/O 2012 – So You’ve Read the Design Guide; Now What?

November 9, 2019 6 By Peter Engel


RICHARD NGO: Hi, everyone. My name is Richard,
I’m designer and I design Android apps. DANIEL LEHMANN: Hi, everyone. My name is Daniel, and
I build Android apps. TOR NORBYE: And I’m Tor Norbye,
I work on the tools for developing Android apps. So in this talk, we’re going
to assume that you all know how to build Android apps. And we’re also going to assume
that you’re familiar with the Android design guide. There was a talk immediately
prior to this that, hopefully, most of you caught. And if not, you should
definitely go check out the YouTube recording of that. So while that talk focused on
the theory of the design guide, in this talk we’re hoping
to focus on practical implications of how to implement
this and help you polish your apps. So assuming that you have this
beautiful design that we’re going to show in the slides,
our goal is to help prevent you from ending up with
something like this. [SAD TROMBONE] TOR NORBYE: So Richard, are
you happy with how we implemented your design? RICHARD NGO: Definitely not. So, before I get started on the
spacing alignment details, I want to step back a little
bit and talk about screens. There’s been an insane time
right now where mobile devices are just completely saturating
the spectrum of screens. It’s really hard to get started
on where to begin designing for these things. As Nate mentioned, most people
usually start with whatever they have in their pocket. It’s a really good way gain a
lot of momentum and energy towards thinking about
structuring your app and knowing how to structure
your content. So when you start there and you
have to go somewhere else with a different screen size and
density, that momentum can kind of slow down. So I’m going to go through a few
things that our team has gone through to go over
those hurdles. The first thing is to really
standardize a lot of this to some sort of standard measure. In Android, we actually have
something that’s a standard unit of measure for screens. It’s called DPs. A DP is basically a virtual
unit that describes dimensions. it’s something that
you should use to define all of your layouts. And the frame [INAUDIBLE]
usually scales it up or down to the density bucket
of the device. This makes all of the physical
sizes of the UI consistent across, or approximately
consistent across, all the devices. So this is an example
I like to use. These three devices are
radically different and they’re all different densities,
but they’re approximately the
same resolution. And when you work on a computer
monitor, you can see that these things are completely
different because you’re stuck on a specific
density and you have to hop back and forth. And it’s really hard
to design for. So it’s really important
to standardize your measurement here. This is how it works
on Android. Think of it kind of like the
Android metric system. It was really hard for me,
because I’m an American. DANIEL LEHMANN: Yay, metric! [LAUGHTER] RICHARD NGO: It’s basically
a bunch of math. What you want to do is plot all
of your devices on there and bring it back to MDPI,
because MDPI is like the magic land of where one
pixel is one DP. An example of that is, the
Galaxy Nexus is an XHDPI advice and if you want to bring
it back to MDPI, it’s that ratio of 4:8, so
it’s 50% reduction. That’s 1280 by 720
to 960, 640 DPs. So when you standardize all of
these things, you can kind of see the spatial relationships
between all of these. And what’s great about this
is it’s actually using the measure that the framework
is actually interpreting. It’s really, really good to
engineers, developers, and designers because we can
all start talking and communicating in DPs. And that’s really, really
good so that you don’t really make mistakes. Something that we use is a
four DP grid on top of everything, once you’ve
standardized all that stuff. All of the Holo widgets are
actually designed on a really strict grid. It really makes it really
easy to see when things are out of whack. Here’s an example of how you
would do this in Photoshop is just change the grid
lines to four. And the advantage of that is you
can actually snap a lot of these things to the
four DP grid. And you kind of see where
things fall into place. It’s really easy to make things really uniform and nice. You can kind of see where all
the 48 DP rhythm lines land. The great thing about this is,
once you’ve standardized all this stuff in DPs, you
can use a stencil. If you haven’t checked
it out, it’s on the Android design site. There’s a bunch of good
stuff in there. But once you get that set up you
can quickly make mockups. A lot of the flows and stuff are
really, really easy to do because you can just start
plopping things on the page. Once you get a lot of these
components together, you can start thinking about transitioning into other screens. It’s really just an adjustment
of width and height. This is an example
I like to show. This is a G1 device. This is a Nexus S, Galaxy Nexus,
and a Galaxy Note. The white part is where your
content mostly lives in, and when you standardize in DPs you
can really see the spacial relationship between that. Now that you’ve standardized it
all in DPs, how do you make it full-res so that you can
see it on the device? If you use the stencils, you
can just blow it up. In even numbers it works
out pretty well. Everything turns out pretty
nice and sharp. If you use odd numbers, you
have to do a little bit of pixel hinting here and there. But a tool that we like
to use is the Android design preview tool. It’s basically a
mirroring tool. So if you’re on your desktop,
you can select a mirror region, connect your devices
through USB, and preview a lot of your designs on a device. You make a lot of quick
tweaks, color changes, and all that. TOR NORBYE: So a very common
pitfall when you’re trying to implement a UI design into
actual layout XML file, is to attempt to do it with nested
linear layouts. So here I’ve added colors to a
bunch of nested linear layouts you can see here. The effect is a bit exaggerated,
but you can see here that, across these two
columns, these are not aligning properly. Even if they did align
perfectly, if I were to change the label of this check box
here in some other locale, suddenly they would
no longer line up. Likewise, you can see that we
don’t actually have proper baseline alignment across these
two columns here that are separate linear layouts. So what you should do
instead is to use a more powerful layout. So, for example, a relative
layout lets you express these constraints. I’m just going to quickly drag
some things here to show you. I’m going to try to reproduce
what I have up here quickly. So we put a label down. And then I can place a
button next to it. And I can express that these
should be baseline aligned. Likewise, the check box next
to it is supposed to be baseline aligned with
the button. Then we have a radio button
right below it, and then there’s a check box over here on
the left that’s supposed to be below the radio button,
and so on. Basically, you can express,
across your whole layout, constraints, and the layout
manager will make sure that these things actually adjust
based on the labels and everything in the layout. This is also very good for
performance, by the way. So it’s not the only reason
why you would do this. We’re also working on a layout
called grid layout, which is shipping with Ice
Cream Sandwich. But it’s also been backported
so you can use it in older applications. The advantage of grid layout is
that it’s a very simple to understand user model. It’s what newspaper editors
have used for centuries to basically layout the design
with rows and columns and column spans and everything. And this is used, I think, for
the lock screen and various other stuff in Android now. The tool support is not done,
but I just want to show you a few things that relate
to the design guide. So we’re working on adding these
spacing guidelines so you can see that, hey, you
probably should have a margin. Likewise, we’re trying
to offer you some suggested spacing. So what we want to do here is
to help you enforce that visual rhythm that the design
guide tells you to use. This is not done, but we’re
going to try to put those red lines into all of our
existing layouts. So avoid linear layouts for any
kind of nesting of your large layouts. But they do have their place. If you are creating a button
bar, the linear layout is what you have to use. It’s the only way to actually
get that correct proportional distribution of space. Another common area for
it is if you’re doing a tablet layout. So you want to, say, put 30% of
the content on the left and then 70% for the remainder. That’s when you [INAUDIBLE]
the layout. There is one pitfall, though,
and I’m going to show you that now. So here I have two buttons, A
and B. They are supposed to be distributed evenly, 50-50. Looks great, right? Well, turns out that weights
do not work the way you might think. They are not distributing the
space of the whole layout . They are distributing the space
of the remainder of the layout, after you’ve assigned
the intrinsic sizes of all the widgets. So right now, these buttons
happen to have the same intrinsic size, so the space
gets divided evenly. But look what happens if I
change the label of button B here to something longer. Suddenly, my even distribution
ends up not looking even. The reason for that, again,
is that we now have more intrinsic size on one of them. And the workaround
is very simple, but maybe not intuitive. What you do is you set
the width of all the children to zero. The width is only used for this
intrinsic computation. And when you have weight, it’ll
use all of the weights for that remainder
of sum of zero. So if I click on our Distribute
Weights Evenly button, that’s going to
do precisely that. It’s going to actually set the
width to zero, as you can see. It’s very subtle, but it’s one
of those things that can look not exactly right. You thought it was 30%. Turns out it’s wider because
something in there was wider. That’s just a little, small
pitfall to look out for. RICHARD NGO: So, on the topic
of stencils, another great thing that this allows you
to do is to really make your app yours. Holo was always built to be
extensible with third parties. There’s a lot of opportunities
to express through customization of
certain parts. Holo is really the bones to
start your application. It’s really up to you
to make it special. It’s really about spacing and
metrics and a few hints of color and character. A good place to start
is with themes. We have light, dark, and light
with a dark action bar. What I like to do is really
start out with the action bar, since it’s the most prominent
bit of UI. And it has a lot
of impact here. I like to look at color and
the contrast and what that really sets the tone for
your application to be. So you can get a feel for, if
you pick a really dark thing, it’s kind of more media-centric,
or white’s like a productivity app. So here’s some quick tweaks
on color alone. And it really changes the
feel of the application. There’s a lot of other places
where you can do that. Of course, the split action bar
tabs and a bunch of other places and backgrounds. But when you look at the action
bar, this is kind of the easy thing to do is to
change the background color. But the thing that you need to
keep in mind is that there’s a highlight and a shadow. You need to adjust that
accordingly to whatever color you’ve selected. You can play with material
qualities here a bit more, but just don’t go too nuts. The action bar also allows you
to put a different app branded icon here. So you can use a longer logo
type, different shapes, and that stuff. You don’t have to use
your app icon. But just make sure it doesn’t
really clash with the action bar itself. A thing to note is, there’s a
bunch of states associated when you press. Make sure that doesn’t clash
with the color you’ve selected, too. We have this idea of making
users powerful with a lot of our states. So the pressed state is the
highest elevated color, and normal is just the bare
geometric form. And then there’s stuff
in between. So if you do customize some of
these things, make sure to respect some of those rules. DANIEL LEHMANN: So Rich said
that you can recolor the whole application. And it can have a very
powerful effect. I did a little exercise, and
I changed the color of this application to red. And you can see, it immediately
feels like a completely different kind
of application. It has a very different
feel for it. You can do that with the
whole application. The problem, however, might be
that we have a lot of controls and if you forget one, it
might feel a little off. So this is an example of the
editor, and what I forgot to change is– the blue underline of the text
is not changed here and it sticks out a little bit. You can recolor everything in
your app, but it can be a little bit of work, especially
because we have a lot of controls. Multiply those by all the
different densities that we provide and all the
different states– can be a lot of work. It can certainly be done. What we recommend you to do is
to change the main screen of your application. YouTube is a very
good example. In this screen, it is mostly
the default style that we use in Holo. But there are three things
that were customized. The HD button has a red
underline, the thumb that’s used to track in the video
is red, and also the tabs are red. So this makes the whole
application feel much, much more like a native YouTube app,
but it also feels like a native Android app, even though
not that much was really changed. Now when you get your designs
from your designer– I would hope you have
a designer– you usually get static images. But keep in mind, views
have states. And every time, when I touch
a view and it doesn’t react in any way– kind of like the sad trombone
that you heard before, this is kind of what’s playing
in my head every time when I see that. Keep in mind there are states. When I push an item, I want
to see a pressed state. I want to see that the
control is really responding to my touches. So you see, the tabs already
have two states. If you add the pressed states,
you have two states more. So we’re already
at four states. Now if the user has a keyboard
and the user can focus the item, you have two additional
states. So we already have six different
states on an item. This is what those look like. We have normal, focused for
keyboard, and pressed. The focused, this design–
focused is an outline. When you push Enter on the
keyboard, it’ll just fill out. So the combination of focused
and pressed looks exactly the same as pressed. So you might think we would need
eight states because we have three different flags,
but in fact it’s only six. Now let’s say you’ve
got all of those bitmaps from your designer– how do you tell Android
that you want to use those in a view? Let’s see how we can
build a selector. This is what solves
this problem. A selector is a set of
conditions that is evaluated from top to bottom. Let’s look at an example. We have pressed equals true,
and selected equals true. We say in that case, we want
to show this bitmap. Now, if that condition is not
met, Android will fall back to the next line. Pressed equals true, and
no test for selected is essentially a test for selected
equals false, because we already tested for selected
equals true. So now that we have the pressed
states, we can do the two focused states. Again, we have selected
and unselected. And notice how the order
here is important. If I moved the focused before
pressed, I would not get the right combination state, which
is focused and pressed together, which should
look like pressed. If I move them at the top and I
push Enter on my keyboard, I would not see any effect. So now with those, then
all that’s left are the regular states. So selected equals true, and
the fallback case where no special condition is met. Now that you’ve identified those
conditions, you put that in an XML file. You create a selector file
and you store it in the drawable folder. And then you can use this
drawable just like you use a regular bitmap. I think we’re also working
on getting those kinds of transitions into our tools. So now that we’ve talked about
the bitmaps, it’s also important to keep the
shape of an item– you want to communicate
the shape. This is a screenshot of
the clock application. If you push that alarm on an Ice
Cream Sandwich phone, you will notice there is
no visual feedback. You don’t get feedback
as a user when you’re pushing the item. In Jellybean, we fixed that. There’s a nice blue outline. And this has a couple
of advantages. The first one is you get
immediate touch feedback, because the item is only
responding when you release your finger. But now you already get
visual feedback when you touch the item. It makes the phone feel
more responsive. Another advantage is you see
the outline of the control. Next time, when the user pushes,
they have a little more confidence what exactly
the size of the item is, because you only see
the text otherwise. It’s a little more
relaxed to tap. And the last one is, you know
exactly what you’re actually pushing, because you see the
control and you see exactly this corresponds to set alarm. So this is something
very important. If the user just taps, nothing
is happening, it’s always a little bit of a challenge
to figure out what the app will do next. So many cases, you don’t want
to supply your own bitmaps. You just simply want to use
the systems default. But, if you have a button, you
don’t have to set anything. Android will already do
the correct thing. But sometimes you have a more
complicated situation. You might have a nested view
hierarchy, and you maybe want to push the pressed states and
those kinds of things on a more higher level control. Or you build your
own custom view. In that case, this is what
you need to know. Selectable item background– if
you set this on any view, it will get the system
standard behavior. So how can you test
all of this? It’s actually very simple,
but I’ve seen many people do this wrong. When you push an item, actually
you should hold it. And you should have a look, what
is the real outline that you’re seeing here? So if I touch the bitmap, I
should see a rectangle. Make sure the shape is correct,
make sure the color is correct. And also, if you have blue
on blue, it’s usually very hard to see. So push and hold. How do you test keyboard
support? One option is, of course, you
get a device with a keyboard. There are a couple
on the market. If you don’t have a keyboard,
there is a very useful thing that you can get, and that
is a Bluetooth keyboard. A Bluetooth keyboard works with
every Android device out there, almost every Android
device, and it’s one of the most useful things that you
should have in your toolbox. You can use this with
every device. You can make sure that keyboard
support works. RICHARD NGO: On to icons. So, with iconography, it’s
actually one of the most challenging things for
developers to do because it requires some artistic
ability. TOR NORBYE: What are
you trying to say? [LAUGHTER] DANIEL LEHMANN: So we have
actually kind of done a lot of stuff for you. And in the icon kit there’s
actually all of the core icons and app menu icons in Holo
dark, Holo light and all resolutions. So if you’ve actually pulled
something from framework base core res, make sure you find the
equivalent in here and not some random thing. Also, really be aware of
our core system icons. There’s a sheet inside the pack
that explains all of its uses and examples. Don’t reinvent them. And if you’re going off the
rails and need to do something, this is all of
our vector sources. It’s also included
in the pack. And this is a good place to
start, because you can kind of see the form and the shapes
that we’ve used. A good place where I like to
start is to plot a bunch of stuff that we’ve already done
and draw kind of like these grade school lines, kind
of like learning cursive over again. It helps you, really, to
optically balance these things and see which one’s
the odd one out. The idea here is to really
get most of mass in the center box. It’s not really about getting
it mathematically perfect in the box. This is kind of a sample sheet
that we’ve done in Gmail. The good thing here is that if
you put everything together, you can spot inconsistencies and
other weird artifacts that you might have not
seen before. The general approach here is
kind of the opposite of laying stuff out. You want to get the highest
resolution that you possibly can. So fidelity matters. And then fill in the holes
downstream, when you can. The way it actually works in
the framework is it always tries to get the highest
possible. If you don’t supply the target
density that your device is running on, it’ll pull
the next one up. If there’s none above that,
it takes the lower one and blows it up. And you don’t want your
assets blown up. TOR NORBYE: All right, so we
have a few features in the tools to help you with
your icon work. So the first one is the
integrated assets studio. So if I go to create a new icon,
and/or icon set, you get into this wizard. So, for example, creating a
launch icon, you can go in, pull up a project logo,
and paste it in. And this lets you create
different shape treatments and things like that. If you already have an HDPI
version of your icon, you don’t actually have to
provide all these other scaled versions. The platform will
do that for you. But this is more where you want
to make sure that you have the right shape, or
possibly if you have a really high resolution image. This is really useful when
you’re trying to create other types of icons So let’s take a look at
notification icons. So here I have a paste icon. Let’s say this is my
notification icon. I want this to appear
as a notification. If I go through the
wizard now and I point it to this graphic– actually, I forgot
to do something. I have to select an
older project. Let me make sure that
I choose this one. This one’s targeting
older platforms. This is a very important
point I want to make. So let’s go create our
notification icon again. Going to choose an image. OK, I’m obviously making
a mistake here. What I wanted to show you
here, unfortunately– this will create an icon that
will look correct across the different platforms. So in pre-Gingerbread, your
notification icons needed to have a dark background and
a light foreground. In Gingerbread, they
turned gray. And as of Honeycomb, they’re
supposed to be white. Now, because the products I’m
targeting here are only targeting Honeycomb, this wizard
knows to only generate the white version. But what I wanted to show, and
I don’t know what mistake I made here– AUDIENCE: [INAUDIBLE]. TOR NORBYE: Oh, that’s right. I closed YouTube project. Duh. This was from my demo yesterday,
and I was like, I’ll just clean this up. It’ll start faster. All right. Let’s try it again now. I’m sorry about this. Glad we have smart people
in the front row. Here we go. All right, now I’m just
choosing text. I’m not going to waste
more time on this. But you can see now, I get
different versions of the icons from version 9 and up,
version 11 and up, and the pre-version. So this is really useful,
because if you’re just sitting in Photoshop, you might
not think of this. And then your icons could look
out of place if you’re targeting older or newer
versions of Android. The other thing I want to show
you is that we have a lint tool, which will help you look
at your icons and make sure you’re not making
big mistakes. So I run lint here, only
focusing on the icon things. And we can jump, for example,
down to the icon duplicates check. And here you can see, it’s
saying that the following unrelated icon files have
identical content. So there’s one called Droidman
closed and one called Droidman open. And they are identical. Clearly that was not
intentional, right? They should have probably had
a different state, and so either the graphic designer
checked in the wrong files, or maybe we made a mistake and we
put it into the repository. So the icon check let’s
you look for that. It also looks for things
like the spacing. So you’re supposed to have some padding around your icons. And we, for example, know that
dialog icons are supposed to be 48 by 48 DPs and here
they’re 32 by 32 DPs. So this checks for a wide
variety of issues like putting bitmaps in the nodpi folder,
and things like that. I mean the drawable, not
drawable density folder. Lint is definitely useful for
checking your icons, as well as various other
polish issues. DANIEL LEHMANN: We saw the
dynamic behavior of selectors. We saw icons. We talked about spacing. Now at some point you want to
put all of this together. You might have heard about the
fragment API, and maybe never bothered to learn it, because
something that many people wonder is, why would
you learn it? You can simply use container
views, and they do a lot of the things that fragments
also do. I would like to show why using
the fragment API can be a really, really valuable tool. But before I do that, I want to
show how we use it in the systems context app to
make it aware of multiple screen sizes. So here we see the context
application on a 10 inch in portrait. You see there is a list
on the left and the details on the right. This is what we call
a two-pane UI. When we switch to seven
inch, we have essentially the same layout. It has a few tweaks, but again,
it’s the list on the left and the details
on the right. Now, on phone it’s a very
different layout. We show the list
in full screen. When I tap an item, I’m being
sent to the details screen. Now of course, as a programmer,
I don’t want to reimplement my app twice. So what I want to do is, I want
to say that this and this part, that those
are equivalent. So how can I use that? How can I do that? So if I don’t know about
the fragment API, a straightforward implementation
would be simply to use a container view and activities. So then it would look
something like this. So you have a list activity
and you put a very big ListView inside. You have a detail activity,
and you put the big DetailView inside. Now this is the phone. Now, once we go to tablets,
well, you reuse those two views. Put the ListView on
the left, put the DetailView on the right. And you put it all in
a common activity. You might reuse the list
activity or maybe you create a completely new activity, like
true pane activity. So this looks all fine. No need to learn about
fragments, right? Well, there’s one problem. And that is, at some point you
want to add functionality. So let’s say we want to
launch the camera. So when the user clicks this
icon, we want to send him over to the camera, allow him to snap
a picture, and then use the picture. Now, the picture comes back on
onActivityResult from the intent that we sent. Which is great, except that
onActivityResult is something that is implemented
by the activity. So detail activity has to
implement onActivityResult and then forward the result back to
DetailView, which is good. But we also have to do the
same thing now in list activity, because we’re
not hosted by detail activity anymore. So we need a lot of boilerplate
code to just send this in. And activities are not
the only reason. There are a few more things. For example, option menus. You want them to be handled
inside of the view, because the view knows the state. So, for example, if you have a
Delete button or a delete menu item, you might want
to have this disabled in certain places. The view knows about this,
not the activity. Lifecycle, onResume, onPause,
data fetching. You want to load data
from a database, you want to process settings. Those kinds of things, they
all live in the activity. But they don’t really
belong there. You want them to be
part of the view. So we actually tried this. In early Honeycomb, the context application is a good example. It was implemented like this. And it was a lot of
boilerplate code. We had to forward things
from the activity down into the views. And every activity had
to know what kind of things the view does. So if I add a new functionality
to the view, I have to change two different
activities to support that. We needed something better. And that is why fragments
were invented. So fragments, basically– if you think about them
visually, they basically take the place of the full
screen view. So in the phone layout, you
would use a full screen fragment for your panes. And on the tablet, again, one
pane is one fragment. Now this solves many
of those problems. So, for example, option menus
can be handled by fragments. You can get the result from the
activity that you called to get the camera result. You can get that back
in the fragment. Also, you have lifecycle
events. It is very much like
a simple activity. If you go through with this,
you will end up with activities that are
very, very thin. You probably have seen that
activities tend to get really messy and big. Once you do something like this,
your activities will be simple host fragments. They will configure fragments,
respond to intents, and coordinate how the fragments
communicate with each other. But apart from that, most of
your logic will live inside of the fragment. So this is not the only thing
that you can do with fragments, but I think it is
the most powerful and it really helps you to make
things easier. So great. So once we know how we can
use fragments to assemble different panes, you then
wonder what should the frames look like? Well, you probably all have
the Nexus 7 by now. The Nexus 7 is an interesting
device. A seven inch screen is
somewhere between a phone and a tablet. So you might wonder, what
should it look like? Should it behave more
like a phone? Or should it more behave
like a 10 inch tablet? So we tried both. Here is an example of what the
people application looks like if we make it behave
more like a phone. This is a full screen list. It actually looks decent. Could maybe tweak it a little
bit, make the pictures a little bigger, but it
mostly is good. Now, when we opened a contact,
it still looks pretty good, because the seven inch device
is very narrow and it feels very much like a phone
in portrait. Once we look at landscape,
things get a little uglier. So here, like 3/4 of the
screen are not used. Similar in the detail screen. This one could probably
be tweaked. But the list is really
a problem Let’s try the other approach. So, this was the single
pane approach. Let’s try the dual
pane approach. It looks really good
in landscape. But if we try to do the same
thing in portrait, things get very cramped. So, the left pane doesn’t really
have a lot of space, and the right one either. So here’s an example of a long
name, and it’s clipped. So you can’t really read it. Now at this point, you might
be tempted to say, hey, why don’t we combine the two? So in portrait, we use the phone
layout, and in landscape we use a two pane UI. That’s the problem with that. So let’s look at the
portrait screen. And now we rotate it
into landscape. So this looks good. Now we rotate back. Rotate back, we’re back
into the list. So this looks good so far. But if we start from the detail
view, we would rotate into the exact same screen. And now when the user rotates
back, what do you rotate back into? So, the naive implementation
would probably go back to the list. But now what happens is that
the user might even accidentally just rotate
the device, and you’re suddenly lost. He’s not in the same screen
anymore, and they have to navigate there again. Rotations can really be– like, you might be using
your tablet in the car. There’s a little pothole, and
suddenly your device rotates for a second. So this is something that you
should try to prevent. What we try to achieve is, we
try to optimize the screens. For example, the left side in
the people application, we made it so that it works. We removed the pictures there,
but we keep the pane configuration. This is a concept that we call
rotational stability. So the number of panes should
not change while an application is running. It should only be based by the
physical size of the device. So that is rotational
stability. How can this all be tested? As you know, Android devices
come in a lot of different forms. One thing, obviously, is you
could buy all of them. First of all, thank you. It can get very expensive. We think there is a cheaper and,
in some ways, better way. So one thing that you can do is,
if you have a big device, you can always simulate a small
device inside of it. If you run this command, which
works on, I believe, Honeycomb and up, you can run
zoom in something like a nine inch mode. It is now suddenly
a 4:3 device. You have a different aspect
ratio, you have a different screen resolution. And you can do a lot of
development in there. We actually, at some point,
developed a lot of the seven inch work on a device like
this, on a modified Xoom. You can even go further. You can take a Nexus 7 and make
this run like a phone. You cannot make phone calls
with it, but it works like a phone. You get the single pane
UI, and so on. There’s some limitations
to this. First of all, you cannot
change the density of a device. If you have a HTPI device
before, it’ll still be an HTPI device afterwards. And also, Android does not
natively support changing the resolution at runtimes. So there’s some caveats that
some applications might crash. The most common one that you run
into if you do something like this is actually
the system bar. So worst case, you lose access
to the Home button. There’s some ways to
get around that. One is, you don’t switch
between device buckets. If you change a 10 inch
device to a nine inch device, you’ll be fine. If you change a 10 inch to a
phone, suddenly the system has to reconfigure so much that it
usually doesn’t survive it. Another way is, if you have
a Bluetooth keyboard those keyboards have Back
and Home buttons. Then you can use your device
again, of course, for development. There’s also a way out of this
which is pretty useful, because then you can use
your device again. TOR NORBYE: Another alternative
to buying hardware is to use the emulator. And hopefully you saw the tools
[INAUDIBLE] yesterday on some of the work we’ve done
to make it faster. With the emulator, you can
create virtual devices. So you can basically
create any hardware configuration you want. Pick the resolution, pick
the density, and then you can test it. And as we showed yesterday,
we’re working on a feature where we also are pre-populating
the list with a bunch of existing hardware. So if you know you want them to
target a particular device, we can basically look up the
resolution for you and you can then test it. Now in many cases, you don’t
even need to run the layout to see that there’s a problem. You can actually do
some tweaking as you’re designing it. So in the layout editor, we have
this configuration bar where you can very quickly see
how something is going to look in landscape mode, and you can
go and make tweaks to it. You can also check across
different languages, so you can see what something’s going
to look like with a different message catalog, for example. So a feature we’re working on
for an upcoming release is going to let you sort of get
to do this in parallel. So I can actually turn
on a preview of all the screen sizes. And as it’s doing this, I can
then make edits and I can instantly see that, for example,
if I were to add this logo, this does not look good in
a two inch QVGA screen, but it looks OK from a
Nexus One and up. And I can use this to not just
check screen sizes, I can also check across locales, for
example, and see how this will look with different languages
and so on. When we’re done with this, this
will hopefully be an even better way to very quickly make
sure that your layout doesn’t have some big snafu
in a particular locale or hardware configuration
or orientation that you care about. DANIEL LEHMANN: Isn’t
this awesome? [APPLAUSE] DANIEL LEHMANN: So the last
thing I want to mention is the targetSdkVersion. So targetSdkVersion is
an attribute that you set in your manifest. It’s a very important number
to set, but we noticed some developers don’t really
know what it is. A very common misconception is
that targetSdkVersion is the minimum version of
the SDK that your application needs to run. But it isn’t. There is another one, and it’s
called, surprisingly, minSdkVersion. That is the minimum version. There’s also maxSdkVersion,
which is the maximum version, which we usually recommend not
to use, because if the user gets an update of their device
and they’re really happy, suddenly they can’t get
your app anymore. So what is targetSdk? TargetSdk is the highest version
of the SDK that you have tested against. The highest version that
you are aware of. If you set this to something
that is older, Android will put you in a compatibility mode
for all of the things that we change. So, for example, if we change
the color of notifications, there is a good chance that if
you set the target SDK version to something too low, that your
notifications will look out of place. I built a little application
here with targetSdkVersion=8. And you can see there are some
things that are wrong here. First of all, there’s this
menu button that we don’t really want any more. Also on the right corner,
there is a Zoom button because– and zoom, with a z. So this is pixel
doubling mode. This is intended for
applications that are not aware of tablets. And lastly, the dialog
looks really old. This is Gingerbread style. And also, the Yes button is on
the left side, but it’s a confirm button, which should be
on the right now, which we changed with Ice
Cream Sandwich. If I change the targetSdkVersion
of this application, it’ll suddenly
look much, much better. The Menu button is gone. Instead we have an action bar. We have an Overflow
button up there. The Zoom button is gone. And also the dialog
looks much better. OK button is on the right,
Cancel is on the left. The one number that is important
that I would like to end with is your new friend,
this number. This is the targetSdkVersion
of Jellybean. If you set this, we will
not apply any kind of compatibility modes, and your
application will feel like a really new application. To wrap it up. RICHARD NGO: So to
close, for me– do the DPs. And really use the Holo widgets
and stencils as a building block to make your
application sing. DANIEL LEHMANN: Yeah, so from
my side, please make your UI items interactive. If you press an item, there
should be a pressed state. If not, think of the
[INAUDIBLE]. Also, use the fragments. They really help you to turn
your application parts into components that you can
reuse and reassemble in different ways. And 16. TOR NORBYE: For me,
I would say, learn how to use the tools. We’ve only, I want to say,
scratched the tip of the iceberg, but I think I
mixed the metaphors. But I’m only showing the tip
of the iceberg in terms of what we have in the tools. Consider yourself
tradespeople. You want to really learn how
to use the tools, learn the key bindings, learn what
features are available. It’s really going to come back
and pay off in spades. I think the thought I want
to leave you with is 16. So I think at this point we’re
ready for questions? [APPLAUSE] TOR NORBYE: Yes? AUDIENCE: Thank you
for the lecture. I want to ask about the
[INAUDIBLE] attribute. I don’t see anything in the
article complete when doing a question mark and then the
value of the attribute. You show an example
in the lecture? TOR NORBYE: You’re asking about
code completion of theme attributes? AUDIENCE: Yeah, in XMLs. So there are attributes with a question mark at the beginning. TOR NORBYE: Yeah, those
are theme attributes. In ADT 20 we’ve added support
for navigating, but I don’t think code completion
works with it yet. So hopefully we’ll get that
into the next version. AUDIENCE: OK. Thank you. TOR NORBYE: Next question. AUDIENCE: Hi. Are the tools that you’re
working on available in beta or current release or
anything like that? TOR NORBYE: Yes. We develop all the tools
in the open. So we have the adt-dev Google
group you can go to. You can see our discussions. And we are checking into the
external Garrett AOSP tree. This particular feature
that I showed from multi-configuration editing
is not checked in yet. It’s sitting on this
hard drive. Hopefully it won’t crash. But it’ll be in soon. AUDIENCE: Thank you. AUDIENCE: My question is about
the revenue menu as seen in the Google+ application. I’ve done a simple
implementation of that, where I just have a frame layout and
two list views, and then I translate the top list view
to reveal the one below. My issue was with the action
bar, and how to get that to translate along with
the top list view. DANIEL LEHMANN: To be honest,
I’m not the right person to answer that question. Is Adam still in the
audience here? RICHARD NGO: Yeah,
Adam Powell would probably be the best person. TOR NORBYE: I think maybe you
can come up afterwards so we can put you in touch with the
right person to answer that. Because none of us actually
know the answer. AUDIENCE: He’s in the
next session. TOR NORBYE: He’s in
the next session. So apparently if you go to the
next talk– is it here? It’s here! All right, so you should ask
that question in an hour. AUDIENCE: Hi, I’m one of two
designers on a really big engineering team. I work with great guys, they’re
super interested in putting out a great product. But I just want to know what
style of collaboration have you found is really valuable,
especially with some of these tools you’ve shown. Like, do you see these as
things that primarily engineers would use? Or kind of both of us? I don’t like emailing
Photoshop files and just going outside. RICHARD NGO: For the most part,
we usually work really collaboratively. We sit really close to
each other and just show each other stuff. But most of our engineers
actually don’t really know how to use Photoshop. DANIEL LEHMANN: And we have
[INAUDIBLE] machines. RICHARD NGO: And it’s mostly
in GIMP, which you can see what the results are
out of GIMP. But it’s really, really
beneficial to have everyone sit together and just work
together, and put most of the design work that’s on your plate
and just really talk about it all the time. Because you’ll get iteration
cycles that are just much more tighter. TOR NORBYE: And most of the
tools that the tools team is working on is primarily aimed
at developers, but we would like to bridge the gap a bit
more so that there isn’t that hole between your Photoshop
assets and your nine patch files. DANIEL LEHMANN: The last thing
I would recommend is have a real process of how you get the
assets from the design to the developers. For example, the problem’s now
have to give this back. You can use a version control
tool, which is very useful, but then the problem is you have
to tell the designers how to use GIMP. That turns out to be a
problem by itself. AUDIENCE: So we actually
use GIMP too. It’s been a little rough at the
beginning, but it totally helps us out because we
actually can have some accountability from the
exchange of the files back and forth. AUDIENCE: Thank you. TOR NORBYE: Next question. AUDIENCE: Hi. Going back to the earlier part
of the talk, about the light and dark theming– I’m curious as to whether you’ve
done any usability testing on if an application
is meant to mainly be used outside, as to what the best
kind of theming is. RICHARD NGO: So the default
themes are pretty much in the middle the entire time. It’s meant to be a foundational
point. So it’ll look OK on LCDs,
and OLEDs, it’s kind of already crushed. But to really crank that up, you
should really set your own styles and themes. AUDIENCE: Thank you. AUDIENCE: Hey, I was wondering
if you guys ever planned on releasing either stencils or
just general themes for the other primary colors that you
guys want in the style guide, like the red, the purple,
and the green. Because having to go through
and make that green highlighted button. RICHARD NGO: We can do that. We’re really tight on just
getting the release out, but a good way to get a lot of that
work done is trying to push these guys to do it in code. But yeah, we’ll work
on something in the future, hopefully. But for now, it’s really
not that hard. Spend like an hour or two just
to get familiar with it. It will probably take you
two or three days. AUDIENCE: Thanks. AUDIENCE: Hey, guys. I got a selector question. My XML files work beautifully,
but when I create selectors in runtime, I’m just pulling down
three separate images– focused, normal, pressed– off the web. The only state that doesn’t work
for me is the focused. I was wondering if that was
a known bug or something. DANIEL LEHMANN: I’m not aware
of any bug there. Are you sure it’s not about the
problem of the ordering in the selector? AUDIENCE: I think I got it all
right, I did double, triple. TOR NORBYE: You’re
saying you’re constructing these at runtime? They’re not XML files? AUDIENCE: Yeah. TOR NORBYE: I don’t know
if we do a lot of that. Maybe you should file a
bug just to be safe. AUDIENCE: All right,
guys, thanks a lot. AUDIENCE: Hi, thank
you for lecture. Just a question about
the targetSdk. If I make it to the 16th and the
dialogues are compatible to the Jellybeans, what is this
version going to be on the Gingerbread, for instance,
where their buttons are in different order? DANIEL LEHMANN: So the dialog
will still look like Gingerbread on Gingerbread
because Gingerbread doesn’t yet know about the fact that
the buttons were reversed. So the targetSdkVersion is
something that Android interprets at runtime. The IPK itself is basically
the same as before. TOR NORBYE: So what
you need to do if you’re supporting both– we have a lint check
which tells you when this is the case. And it tells you what
you have to do. You have to create a v14
specific layout where you change the order so that you
can actually have both. There’s no automatic reordering,
as far as I know, of your own dialogs. AUDIENCE: What would you
recommend to make them compatible, meaning what
is the priority? Setting the targetSdk? Or creating those
custom layouts. For instance, if I started
with the Gingerbread. TOR NORBYE: What you want to
do, is you want to try your application on the latest
available version. If it works, set the
thing to 16. That’s going to be better in
many ways, even though there might be more tweaks you want to
do to take advantage of the Ice Cream Sandwich and
Holo look and feel. You’re still going to be better
off, because it’s going to get rid of some of the older
compatibility modes. The next step is then to go and
say OK, well what can I do to make this even better? And that would be where you
would do a custom layout if you want to, for example, change
the order of confirm buttons and things like that. AUDIENCE: I see. Thank you. AUDIENCE: Hi. Very simple question. Do you have an exact canvas size
that you use in Photoshop that you always start with? RICHARD NGO: I actually
make it super big. So I do 2560 by 1600. And then I actually have the
screen sizes all laid out and stacked up on top of each other,
just so that I can see the differences between
each kind of device. And I start that way. AUDIENCE: You design multiple
versions of a single layout? RICHARD NGO: Yeah. It’s because we’re working on
the entire platform release, so we’re launching
on everything. So we have to design for
that entire spectrum. TOR NORBYE: So you have a
layer for each different device on top of each other? RICHARD NGO: Exactly. AUDIENCE: Do you start
with MDPI? RICHARD NGO: I usually start
there just to get the general layout right. If you are pretty experienced
you can actually do all of that math in your head. And it gets really natural
because they’re all the same numbers over and over
and over again. So some of the team members
on our team start in XH. But as a beginner, you should
really start in MDPI, just to get the hang of it. Once you get pretty skilled, you
can move up to doing the native resolution of the device
you’re working on. DANIEL LEHMANN: So the advantage
of MDPI is that one pixel is one DP, so you can
directly use the bitmap. Just put it on the device and
see how it looks like. AUDIENCE: Are you guys going
to upload some sort of template like that to
the design guide? RICHARD NGO: I actually worked
on something like that. I’m trying to push it out. So look for it in the future. AUDIENCE: Awesome. Thanks. AUDIENCE: Hi. The dot 3 or DPIs generally have
support for most of the resources, but is the
expectation for LDPI to get obscured by the framework? Or do you plan to update
them as well? DANIEL LEHMANN: Could you look
repeat the question, please? AUDIENCE: LDPI. Missing LDPI resources. DANIEL LEHMANN: LDPI. Yes, so the reason is that the
platform, the devices that we target, they are not targeting
an LDPI device at the moment. If you don’t supply an LDPI,
Android will at runtime downscale the MDPI
asset for you. But in the platform,
we don’t create customized version for LDPI. TOR NORBYE: We actually have a
screen, like a usage chart, that’s based on, I think,
[INAUDIBLE] or check ins. I’m not sure exactly where
the data comes from. But it shows you the prevalence
of different screen sizes, and LDPI is a very small percentage at this point. I think it’s like 2% or 4%. But it’s pretty small. AUDIENCE: Thanks. AUDIENCE: I noticed that for the
buttons and the difference selected states, it seemed
like you were using images or PNGs. I know that you can also
create– especially for simple backgrounds like that– you can
create these through XML. I was always wondering about
the performance of that. Which would give you
better performance? Is there any preference
between the two? DANIEL LEHMANN: Usually
bitmaps. Simply because there are
less things that have to be done at runtime. But it might depend on the
concrete thing that you’re trying to do. RICHARD NGO: Best person
to ask is Raman. TOR NORBYE: m his sidekick
is here. Did you hear the question? AUDIENCE: I didn’t hear
the question. TOR NORBYE: OK, sorry. AUDIENCE: I’m a developer
and I want to play nicely with my designers. RICHARD NGO: That’s
a good cause. AUDIENCE: I’ve showed them how
to use the layout editor in Android, but when they look at
my layout XML files, a lot of times they just see a lot of
nothing, because the text and images are layered at runtime. So is there a way that I can
provide placeholder stuff that won’t [INAUDIBLE] my runtime APK or give
me lin errors about little text or things? TOR NORBYE: Yeah, that’s
something we’d like to do more of. So what we do now with certain
widgets like list views and fragments, where we know it’s
going to be populated at runtime, we put some
sample data in. But we have gotten some requests
for the ability to do this with, for example, labels
where the people don’t want to see the text attribute, but
they want to have a design [INAUDIBLE]. That’s something we’d
like to work on. If this is important to you, one
simple thing you can do is to subclass the view. And then, basically, there’s
actually a method you can call to see if you’re running in a
tool or if you’re not running in real runtime. I think it’s view.isineditmode. So you can basically, like in
the paint method, just do something custom there, just
to work in the tools. But clearly that’s not
a great solution. So we definitely want to try
to address that better. AUDIENCE: It comes up a
lot in views that are inside the list views. You know, the converter
things. TOR NORBYE: So you want to
preview your list views? AUDIENCE: I want to see my real
views that are going into my grid view or my list view. TOR NORBYE: One thing you can do
is, at design time, you can set up which layout to use
for the list view items. You can make your own layout
that is only meant for design time, and just do that as
a preview rendering. AUDIENCE: Hi. You guys earlier mentioned
something about problems you had with landscape orientation
for Peoples app. I noticed that launcher
supports portrait orientation only. Could you provide
an insight why? DANIEL LEHMANN: [INAUDIBLE] do
you have an answer to that? You heard the question? AUDIENCE: [INAUDIBLE]. TOR NORBYE: I got the impression
that it had to do with usability, something about
sitting sideways and reading or something
like that. But I don’t know the details. I’m kind of making it up. Sorry. We have people in the front
row– but yeah, we don’t have a good answer. AUDIENCE: OK, thanks. TOR NORBYE: All right,
so no more questions? DANIEL LEHMANN: Any
other questions? All right. TOR NORBYE: Thank you. [APPLAUSE]