Do you have an example of using a linear layout in your app?
>> Well, even here, this cluster of three cards is a horizontal
linear layout where we just add child views like three cards.
And then we set layout width to zero dp and layout weight to one.
And essentially, it instructs the linear layout to take however much
weight it has at run time and distribute it evenly based on other relative
weights are distributed evenly between all the child views in that group.
So that's one example.
And another example would be over here, that you have new and updated games.
And the more button which is a cluster header,
it's also a simple horizontal linear layout.
So when things are simple,
you don't necessarily want to start writing custom layouts.
Don't just use relative layout everywhere
because it's more versatile than linear layout for example.
That's just overkill for simpler things.
>> So when a designer gives you a mock,
how do you go about starting to build that app?
>> So hopefully at that point, like we talked, we have not just one mock.
But rather, at least two or three that show how
the design scales between small screens and large screens.
And then I want to identify building blocks.
So, if we talk about sometime like a card which appears in a lot of places
in the app, I wouldn't want necessarily to start
implementing a lot of variants of the same card.
Based on if it needs to show a small image or a big image or
maybe show a one line title, instead of two line titles.
So I'm trying to identify these blocks and implement them as
stand-alone classes, stand-alone layouts and then start building on top of those.
So you start from text view, image view, spinner,
and whatnot to build smaller blocks.
And then hopefully you're able to keep on taking those small blocks and
build larger blocks while reusing the same basic set of blocks.
And what's nice about it is even though you spend maybe a little bit more time
up front, it becomes easier especially if the design is consistent
in how it applies its language to evolve the app and to add new features.
If the design is consistent, then you keep on seeing the same blocks being
used in different configurations again and again.
And then that's where your initial investment starts paying off where
you don't treat implementation of a new screen as a brand new thing.
But rather, maybe 50, 60, 70, however much percent is already there, maybe
it needs a little bit tweaking with color, so maybe typography or whatnot.
But hopefully, if the design is consistent, then the implementation is
also easier to move forward if you already built for that.
And it also becomes easier to apply redesign, just on the visual level.
If you want to tweak colors, if you want to tweak typography,
if you want to add maybe like we did in Lollipop where you have this ripple
effect when you press something.
If you have a few pieces that you keep on reusing, your styles, your layouts,
then you do that visual refresh in a fewer
number of places and then hopefully they get applied consistently everywhere.
So for me I want to place the focus at the beginning on getting the data right,
especially for an app that is getting its data from external sources.
And then do closer to the pixels, refine the pixels once you have
the data to do the grid, to do the typography, colors, animations,
transitions, whatnot however much time you have to spend on that,.
And I think it would be the same if you had something like a Twitter client.
You could start by pixel-perfecting your layouts with some fake data.
And then you discover that you know nothing about fetching the data from
Twitter, and it takes you the next three months just to fetch the data.
Or, just an example, so I prefer to start from the data.
I think about this as an iceberg where you see the pretty pixels as maybe 5%,
10% of above the surface, and then there's a lot of work going
below the surface, if you will, to support that.
>> You mentioned the tip of the iceberg is what people see.
So what exactly is going on below the surface?
How do you see the Google Play App?
>> So what happens below the surface is first of all to get the data from
the network, so you can authenticate to be on a server and get the data.
And then maybe to cache it locally so
that the next time you go from the stream into the details page and
back into the stream, we should be using cached data, cached images.
So that we don't put too much strain on the battery.
And also the app already shows the information that it has.
Then you have support from multiple accounts.
Then you have maybe persisting a few bits here and there in the database.
Then we have the billing flows, which is, most of that
work is done on the server to integrate with different payment methods.
And then there's the work on the client as well.
And another big part of the Play store is downloading and
installing apps and games.
We are, on the Play store side, we are in charge of downloading,
installing, updating apps.
And so that's another big chunk of, once again, pretty much all of
these have their surface bits, which are pixels on the screen.
And then there's a lot of work going below the surface to bring
that information for the right account, and to put that on the screen.
>> It's clear that you've worked on many different iterations of Google Play app.
How do you keep up to date with the latest news in Android?
>> There's a lot of information on Google+ from very active
Android developers who put out a lot of tutorials.
And, Just
from different blogs, and sometimes I don't necessarily go and
read deeply a certain series about recycler view or a view page or
what-not or how to configure the tool bar and action bar.
I kind of try to put it like
that I know that there's a lot of information in there.
And then when I do need that deep level of information,
then I go to those resources.
>> Well thank you so much for your time, Cyril.
I think our students will really enjoy hearing your perspective on
what it's like to be an Android app engineer.