2012-09-06 Android Developer Lab+ - Density Independent Pixels

[Hangout dings]
>>Ankur Kotwal: Hello and welcome everyone to another Android Developer Lab+. We will
be getting started in just a minute. I'm just setting up the Google Developer's live link
so just bear with us and we'll be right back.
>>Tony Chen: Yeah, hi everyone. [Typing on keyboard]
>>Ankur Kotwal: Okay and we're good to go. So if you're tuning in online live right now,
then you should be able to go to developers.google.com/live and go to ADL+. So, let's start off with the
usual introductions. I am Ankur Kotwal and I'm joining you from Sydney, Australia. I'm
also joined by my colleague and friend.
>>Tony Chen: Hi, I'm Tony Chen from China.
>>Ankur Kotwal: Tony is muted right now so we can't hear him but he'll fix that up in
a second. [Laughs]
>>Tony Chen: Okay, can you, can you hear me now?
>>Ankur Kotwal: We still can't hear him. So let me introduce Tony in the meanwhile it's
Tony Chen from Hong Kong and one of our regular viewers, Andrew, has just joined us as well.
Hi, Andrew.
>>Andrew Kelly: Hi.
>>Ankur Kotwal: Okay. Alright, Tony. I cannot, Andrew are you able to hear Tony?
>>Tony Chen: Can you hear me?
>>Ankur Kotwal: Now we can.
>>Andrew Kelly: I can, yep.
>>Tony Chen: Okay, yeah, so I'm Tony Chen joining the hangout from Hong Kong and today
we have the special topic for today is density independent pixel. Before that let's talk,
uh, let me share my screen. Hopefully this time we're doing it right. Just give me a
second.
[Pause] >>Tony Chen: So, can everyone see the slide
alright?
>>Ankur Kotwal: Yep, looks good here, Tony.
>>Tony Chen: Okay, great. So, let's talk about, um, before we get to the DP subject today,
let's talk about news. So, for this week we have ADT 21 Preview 3. It's mostly bufixes
and no new feature but if you want to check it out, as always, like, just go to tools.android.com.
In other news this week is our colleague, Roman Nurik has made a G+ post about chips
and recipient text field. So this is what you guys usually see on the Google Plus client
and Roman has some details, information about how, where you can get the code from the AOSP
website. So check that out. I have a Google short link here, so, check it out.
>>Ankur Kotwal: just to give you a background on that, we call it 'chips' but it's basically
when you, when you complete some contact information, rather than have the email address or the
phone number show up, you get a nice little rectangular box with an image of the avatar
of that person in that box and their name. So instead of just having an ascetic email
address, it's a much more pleasant piece of UI and you can, you know, select that whole
chip, if you wanna clear it or if you wanna add a few more people and drag it around,
that sort of thing. So it's just, uh, just a nice bit of polish to add to your apps and
those are the little subtle differences that really make your app stand out compared to
others. So Roman has basically, in his post, shown you where you can find it in the Android
Open Source projects so the source code is already there he's just showing you exactly
where to look.
>>Tony Chen: Cool. Alright, so, let's get to the topic of today, density independent
pixel. So before we get to the details about what that is and what DP is let's start with
an overview, um, to just get everyone on the same page with some definitions. So, screen
size is actually the physical size of any devices, any Android devices. So we have four
categories, small, normal, large and extra large. And then when we talk about screen
density it's really the, it's the quantity of pixel within a physical area of the screen.
So, a lot of people use dot per inch, this is the common terminology. And for resolution,
it's closely related to screen density but it's really talking about the total number
of physical pixel on the screen. So when we talk about screen density and resolution is
really the, in proportional, the higher the screen density, the higher the resolution.
So what is the problem with pixel? Because, as like you guys already know, we introduced
something called deep density independent pixel in Android and we highly recommend everyone
when you design layout using DP style pixel but was this really the problem with pixel?
Well, turn out pixel has many meanings. And what I'm really mean by that is like, let's
go to the pixel, like the definition of pixel. It's really based on the contraction of pix,
which is coming from picture, and the E-L is coming from element. So it's really an
element of the smallest addressable element for display. But then when we talk about printer,
pixel can be an ink droplet or even a unit of carbon particles. So, as you can see, there
are many different meanings based on the context. And in camera, pixel is really represent an
image sensor element. So it's really different meaning depends on the terminology or context.
Pixel can also have different size and representation because a pixel in CRT monitor is different
from a pixel from a LCD screen. So, if you want to know more about the detail of pixel,
you can go to wikipedia to find out even more detail. So, now we have density independent
pixel. So, the key here is DP is really a physical length unit, so, just like centimeter
or meter. So you have a physical length in the real world. And, of course, like one thing
we, in the very beginning we use, actually, dip as shorthand but now it's dp and dip is,are
interchangeable and you can still identify things in your layout with both shorthand.
Pixel is also a physical point but then it doesn't have a fixed dimension. So it varies,
depends on technology and how a particular device has, it may have many pixel in the
same length. So, we have a definition or a formula to trans-, um, to translate between
pixel and dp and the formula is here is a pixel is equal to dp star times the dpi over
160. And 160 is really kinda like the magic number because that is the density for mdpi.
So in Android, we have different screen densities listed here below here, its ldpi, mdpi, hdpi,
etcetera. And the one I highlight in red, the tvdpi, is particularly interesting at
the moment because it's the, well first of all it's the tvdpi for Google TV and also
as well as like the latest Android tablet, Nexus 7, density as well. So, now after we
learn all these, like, concept, let's get to some exercise. So, how many pixels are
there in 1dp for our first Android phone, the G1 phone? Can someone make a guess? It
turns out the answer is 1 pixel and the reason is we used the G1 as the baseline for everything
basically the G1 phone is the normal, is a normal screen size and also have the mdpi
resolution, sorry about the typo there. Let's get to another exercise. How many pixels are
there in 1dp for an xhdpi device? Guess what? The answer is, it depends. [chuckles] Because
for xhdpi is, actually, it's a range and in most cases xhdpi is 320 but it depends on
what device, could be, some device could have like 325 or things like that so that's why
it depends. And that actually makes this coming exercise easy because now I specified the
density of this xhdpi device to 320 and, of course, the answer here is 2 pixel. Um, okay,
so another exercise, so, what are the dimensions in dp for the following rectangles? So if
you look at these rectangles and if you remember our definition of a dp which is, I actually
put the formula up there for convenience and if you remember the mdpi is the baseline,
which is 160, the answer is, will be obvious and the answer is 4dp. And because we are,
for the rectangle of an mdpi we have 4 pixels on each side and because that's the baseline
and we have 4 pixels and the answer, and that makes the answer 4dp. Okay, so, another thing
I want to talk about is the dpi ratio because as you can see from the formula, it's really
the current density of your device divided by 160 and because of the, there are actually
ratio between these different density and just a convenient thing to remember is like
3 to 4 to 6 to 8 so you can use these ratio easily to do the proper conversion to get
pixel or dps based on these, like, ratios. Okay, so, let's talk about the problem of
using pixel, px, in your, in your layout. So here is an example of the effect of defining
a 2x2 box in pixel in your layout. So, as you can see, if you do it, if you define something
with pixel, in the ldpi device, it occupies the entire rectangle but as you move to different
devices you see the graph, the box actually is shrinking because you define things in
pixel and in the higher density device, the pixel is actually smaller and that's the reason
why things are not scaled properly in, in, when you define things in pixel. So now let's
take a look at the effect when you define things in dp. So, in this case, because you
defined things in dp, and as I mentioned before and hopefully you'll already remember dp is
a physical length unit, so if you define something with two dp, the representation across different
resolution is the same, it's going to be the same. And that's what we meant by resolution
independent. Okay, so, what about bitmap assets? So the Android framework actually is quite
intelligent and it will scale bitmap drawables appropriately when using dp. But there is
a big caveat here. The graphics here, as you can see, it doesn't matter whether you're
scaling up or scaling down because there's no algorithm, actually, perfect algorithm
that would produce to scaling images. So if you scale up you will, because you don't have
enough information, you have to do interpolation and that will create an image that is not
sharp. But, at the same time, if you're scaling down your image there's a potential running
into something called aliasing which also can make your image not sharp at all also.
So, the conclusion here is you should create bitmap resources for each dens-, uh, density
of device you're targeting. So, what is sp? Because besides dp there is also sp in Android.
So sp is something we designed specifically for text. In the Android framework there is
accessibility option to allow user to enlarge fonts even they are specified in dp. So, in
that case, the formula is really, sp is really dp times some scaling factor determined by
the user, what kind of font, uh, scale they want to scale their fonts to, to larger fonts
or smaller fonts. So it's still somehow [indistinct] the dp, make the text a kind of independent
of resolution but at the same time if the user decides to scale it up for accessibility
reasons there is an [indistinct] scaling factor for user to specify. And after all these,
so I hope by now you have a, kind of a good grasp of what dp is and because of all these,
like, problem that pixel and that's why we kind of introduced a new size qualifier to
do, to do resource classification. And this new qualifier allows more control over different
specific, like, screen sizes to support your application. So, the old size qualifier which
is small, normal, medium, large, extra large, and turns out because of the resolution issue
it's no longer good enough to classify things like tablets. So, for example, a seven inch
tablet has a size large but so, that makes actually tablet not necessarily equals extra
large which is, breaks a lot of things and by introducing these new qualifiers, so there
are three of them, so one of them we call it smallest width so the syntax is right,
is like sw and then the number and then the dp. So the nice things about this smallest
width is you don't need to care about the orientation of your device so all, all you
are specifying here is for a particular device, for the smallest width size of the tablet
or the device, it has to be at least 600dp in this case. So, in that case, the resource
under this resource folder will be selected for creating your lay-, um, rendering the
layout. There are two other qualifiers, one is specifically for width and another one
for height but it's tricky because, it really ups to the [indistinct] like to find which
size is the width and which size is the height and we usually see and recommend people using
the smallest width and that should take care of a lot of the cases. Um, so, one thing about
compatibility, so, before we introduce, uh, before Honeycomb 3.2, these qualifiers doesn't
exist, right? So, in that case, we still recommend developer, especially if you are targeting
pre Honeycomb devices, you still need to specify a bucket to take care of selecting tablets
using extra large, for example. But in this case there's one problem, you can, as you
can see, there are two files, actually having the same tablet layout, the main activity
xml is actually duplicate. So, how to solve this problem, so, one thing you can do is
you can abstract out the tablet layout into a different user, uh, using a different name,
uh, in this case I call it main activity tablet.xml. And for, in your, in your resource folder
under, using values, you can specify layout pointing to that particular xml. So I understand,
like, the layout xml is still duplicates but your content, your true layout is only defined
once, so, which is the key here. Finally, let's talk a little bit about screen support.
So in, we have a tool tags in the Android framework to allow multiple screen support
so one of them is support of screen and in this case here I want to filter out small
and normal screen size. So, this is the, kind of the, the specification I need to do to
set small screen and normal screen to force. So, how bout this one? So, is this the configuration
to filter out small, only make the, your application available for small or normal size screen?
Well, it turns out the answer is wrong because the support screen doesn't mean that your
application will not be available but for large and extra large device. It just mean
that they're running in something we call compatibility mode for these two form factors.
So, how to filter out large or extra large screen devices? We have another tag that actually
can really do this, so, in this case here you are using something called compatible
screen tag and you have to specify all the screen you would like to support. So that's
the one big caveat and that's kind of the reason why we are not recommending developer
to use this because you, if you don't specify all the different combination you'll, your
application will not be available for those you didn't specify. And another thing is after
all, in Android we always looking for application that support all devices and that should be
your ultimate goal. So that's pretty much for density independent pixel and so we can
switch to Q and A or Ankur if you have anything to add to this feel free to chime in.
>>Ankur Kotwal: No, that was quite comprehensive. [chuckles]
>>Tony Chen: Cool.
>>Ankur Kotwal: So at this stage I guess we can, given that we've just had a topic that
we, that Tony presented are there any questions on the presentation from any of the live audience
or anyone tuning into the stream even?
>>Tony Chen: Yeah?
>>male #1: Hi, I would like to ask you about pictures and images loading from the internet,
for example, Facebook. So if Facebook has a large image, say, 180 pixels, on large devices
with hdpi they will be displayed as twice, so it will be like 90dpi? Any way to, any
strategies to like scale them?
>>Tony Chen: Oh, so, I think in that case, back to the presentation, is if you define
your image dimension using dp, the Android framework will automatically actually scale
the image up for you. But then, again, you run into the issue of interpolation, you may,
you will not have a perfect image and that's why we suggest developer to create different
accents in the right resolution for that particular density.
>>Ankur Kotwal: As a just general strategy, though, if you're pulling, and in your situation
you said you were pulling down assets from the net and you might not have, you know,
a different, um, resolutions of those images, consider whether you think stretch, stretching
that image is really the right thing to do and certainly consider whether you wanna stretch
it to as big as you can get. There might be a middle ground that makes more sense like,
you know, 1.5 times in every dimension where it doesn't look too blurry but, you know,
it is what it is. So if your source image is low resolution there's only so much that
you're gonna be able to do with it.
>>male #1: Okay, thank you.
>>Ankur Kotwal: There was a question, there was a couple of questions on the moderator
that have been added, Tony, on this topic so let's deal with those ones first then today.
"Is it possible and how to provide different graphics, except 9 patches for two different
devices running, for example, 800 by 480 and 540 by 960 on Android two and 2.3 without
checking the resolution via Java source and setting the proper graphics." So, my understanding
of this question is the person is asking how do I make it scale without having to manually
do it myself. Is that your understanding, Tony?
>>Tony Chen: Uh, yeah, based on what the question is.
>>Ankur Kotwal: Yeah, so what I would suggest is actually just if you're just going to render
it in a view just use, like, an image view, just use the properties that we provide there
that allow but you can specify whether you want it to stretch to fit or you want it to
scale or you want it to crop. There's a couple of options there that you should really have
a look at and see what makes sense. So, in that case, the Android framework is doing
the work for you. So, just keep in mind, however, though as I, as we just said to Constantine
that it may not make sense to always stretch to low res image to a bigger [inaudible].
In terms of providing the best user experience cause that's the goal at the end of the day,
you might have to have some logic in there that says hey if I'm pulling down some image
from an online source and I don't know what resolution it will be do I wanna make it bigger
than it is or do I wanna shrink it so on and so forth. If you're providing your own assets,
um, as long as you're kind of reasonably in the ball park I would probably try and render
the image slightly higher than it needs to be and then put it in the, in the relevant
resolution bucket and then just size my UI based on dp's just like Tony described today.
>>Tony Chen: Yeah. I think the second question we have on moderator is, "Whenever we read
the dimension of device screen, example, 480 times 800, 1024 times 600, in the device specification
is that valid in pixel, dp or dip?" So, uh, wow, my understanding those number are in
pixel and also the other thing is dp and dip is the same thing. Yeah, so, um.
>>Ankur Kotwal: I think that was a trick question to try and catch us out, Tony. So we picked
it up.
>>Tony Chen: Exactly. [Laughter]
>>Tony Chen: Yeah and one thing I want to, I want to comment is when we've talked about,
like, designing layout in dp, it's really, what we are talking about is we want the experience
on a particular physical size consistent regardless of resolution. So, we are not saying, like,
using dp in your layout will scale properly in different size device. That actually is
a misconception. So what we are talking about here is if you design a 7 inch layout for
a 7 inch device and if you are specifying all these dimension in dp, it will guarantee
to work on all the 7 inches devices regardless of resolution and that's the power of dp.
It's not, we're not saying if you define a 7 inch layout using dp it will work in the
10 inch device, that's not true and you have, uh, what you should do is you should define
a layout for a 10 inch in form factor and you may choose to use, like, using more [unclear]
or using different design and things should still be done in dp so that your layout will
work on 10 inch device with a different resolution. So that's the, that's the key concept here.
>>Ankur Kotwal: Yeah, I might just add to that, Tony, I think in general-, my experience
has been that 7 inch devices and 10 inch devices you can actually reuse the same layout, in
general, and it works really well and it scales nicely. I mean, assuming you're building nice
scalable user interfaces. One big differentiating factor that I find between 7 inch tablets
and 10 inch tablets, however, is that the default orientation of a 10 inch tablet is
landscape mode whereas the default orientation for most of the, just about all the 7 inch
tablets I've seen is portrait mode. So that's something you should consider as to how, what
your layout, how your layout might change between portrait mode and landscape mode.
To me, the big differentiating factor is actually the orientation as opposed to the physical
size of the screen.
>>Tony Chen: Right. I mean, like, if you do things like write using fill_parent or wrap
con-, for, for the container so things will flow properly when you go from a 7 inch to
a 10 inch device. But one thing to remember is if you specify things in dp those assets
or controls will stay the same size regardless of the, the 7inch or 10 inch. So, but if you
do the container or the layout container properly then they will, they will, or doing, using
percentage and things will work fine.
>>Ankur Kotwal: So I think that's all the questions that we had on this week's topic
so Tony thanks for covering dps. The one thing we talked about was sort of the advantages
of dp but the big take away I think developers should really go back with is don't use pixels
in your layout. Don't specify user interfaces with pixels because that's not going to scale
across the wide ecosystem of devices that we have. You know, build scalable user interfaces
and dps are certainly one way to do that. The other way of building sort of flexible
user interfaces is using things like wrap content or fill_parent on your layouts as
well.
>>Tony Chen: Right.
>>Ankur Kotwal: Alright, so we've got three other questions on here, Tony. I'll just take
them from the top.
>>Tony Chen: Sure.
>>Ankur Kotwal: "I'm implementing in app billing but when I try to buy some item in the sample
app, I don't get a response from my app and after a few minutes I get an error of reason
took too long to deliver. This bug was in the known issues for almost a year, is there
an update?" I didn't know it was a known issue and certainly I've played with in app billing
and I haven't had this particular issue. So, I don't know if you've got more to add Tony
but it'd be great if this person, "BRNO", would contact us separately and just let us
know what the issue, if she or he has got a bug raised.
>>Tony Chen: I'm not aware that there is a bug but one thing that may cause that reason,
took too long to deliver, is some of the transaction orders is actually maybe flagged as fraud
or, you know, from a risk engine. So I think one thing developers should have expectation
is there are a certain percentage of orders that will be flagged as potential risk fraud.
And for those orders it will not process go through and that's a result, could be a result
of that took too long and-
>>Ankur Kotwal: It shouldn't happen in the test app, though, cause if he's using, he
or she are using that sample app it should be using the package names that are using
the test nomenclature.
>>Tony Chen: Okay.
>>Ankur Kotwal: So, the risk engine site shouldn't come into play but I'd love to hear from-
>>Tony Chen: But there are, there are developers, like, telling some transactions have failing
so, may not be this case here but that could be a potential problem. Sometimes if you see
these transactions didn't go through and I hate to say it, it's normal but it does happen,
like, some transactions does, won't go through for risk reason.
>>Ankur Kotwal: Yeah. Cool, so please do contact Tony or myself and we can have a deeper dive
in it. I guess we'd need to see a little bit more as to exactly what you're doing and we
can try and take it from there. Okay, "According to the Google Cloud Messaging tutorial, awake
lock is required in order to handle the registration action. How can the device handle registration
response but in sleep mode when sending a request to a third party server? Any other
examples of services requiring awake lock?"
>>Tony Chen: Um, I know of an example. So, we have an Open Source project called Prone
to Phone and there should be implementation on the things you described. In terms of getting,
handle registration responding in sleep mode, Ankur, I don't know the andswer. Do you have
any insight on this, this part?
>>Ankur Kotwal: No, I mean, I think in general it's good practice to acquire the awake lock
if you're waiting for a response because these things, your request responses are asynchronous
in nature. So if you actually wanted to make sure that you are, you know, awake so to speak,
for that duration then you should do so. Just be careful in terms of acquiring that awake
lock because you wanna try and minimize how long you've got it for because, of course,
the device is not able to sleep at that point in time so it's a drain on the battery.
>>Tony Chen: Yeah, I agree. So the third question, the last question, oh, you have a question?
>>male #1: Yeah, yeah, I'd like to add more about this question. For example, I have foreground
service which uses a website that's a connection to the server and definitely the user can
push the power button to, for the device to go into sleep mode. Does it mean that I still
need to acquire awake lock so the connection won't be broken?
>>Ankur Kotwal: If you want to maintain the persistence of your connection then I would
recommend, yes, but I would also ask you to really think about whether that connection
needs to be persistent, persisted throughout and that's one of the benefits of Google Cloud
Messaging aright, so you don't have to have awake lock the whole time or a connection
to your server you can have a notification come through or a message come through and
then you can spring to action then. It's event based rather than you having to maintain this
persistent connection.
>>male #1: Okay, thank you.
>>Tony Chen: Okay, so the last question we have here is, "Can you recommend the best
way to implement themes in Android since you point to cover dpi and other related topics
maybe you can consider having an info about themes, too." So, first of all, that's a great
suggestion and I think, like, theme itself could be another ADL+ presentation so definitely
we'll look into that and hopefully we'll have another session about themes, specifically,
in the future.
>>Ankur Kotwal: Yeah, in the meantime, though, we've actually got a fairly extensive section
on developer.android.com in the guide section on styles and themes and it walks you through,
sort of, how to style, do some basic styling. I think that's a great place to get started.
There are more, sort of, community based examples that I've seen that go to a larger extent
so I'd seen a community effort for building the hollow theme for older Android versions,
for example. So, what I suggest is to start with this guide and then go have a look at
some of these community efforts and see how people are building, you know, building advanced
themes so to speak. But yes, thanks for the suggestion. I think that's a good idea for
a future topic as well.
>>Tony Chen: Yep.
>>Ankur Kotwal: Okay, well, anyone else have any questions?
>>Andrew Kelly: I had one.
>>Ankur Kotwal: Yeah, go ahead. [Pause]
>>Tony Chen: Go ahead.
>>Andrew Kelly: [inaudible]
>>Ankur Kotwal: There you go. Now we can hear you.
>>Andrew Kelly: I just have one from the chat window there, when I'm using 9-patches, do
I need to specify a PNG file for each of the different DPI buckets or do I just need to
have one in my drawable folder that will cover me for everything?
>>Ankur Kotwal: I think you could get away with just having the one. I wouldn't put it
the drawable folder, we actually have one called the drawable-nodpi which is kind of
like the explicit one to say that this applies to every bucket. I mean, it will work but
just from a best practices point of view we recommend using the no dpi nomenclature.
>>Andrew Kelly: Cool.
>>Tony Chen: Yeah. I think using 9 patches would, it can be another topic so in the future
we can talk about it. [Laughter]
>>Andrew Kelly: I just wanted to make sure that I didn't need to have, sort of, a high
res 9 patch for high res devices in a sort of low res-
>>Ankur Kotwal: Potentially you can. Depends on how big the image is, right?
>>Andrew Kelly: Yeah.
>>Ankur Kotwal: So if you're doing it for styling, you know, UI then maybe you can get
away without it but if you're doing, you know, high res images that you're expecting to stretch
like a background
>>Andrew Kelly: Just things like buttons and things like that so at the moment I've been
using, defining them in xml using gradients and stuff and strokes so I don't have to have
a 9 patch instead and that seems to work quite well . So I was just thinking I needed a more
fancy button that couldn't be defined using a gradient then I might have to use 9 patches.
>>Ankur Kotwal: Yeah, you'd probab-, I mean, ideally you should have, you should be building
assets for each of those res-, each of those buckets, but if it's something really small,
like your 9-patch is really tiny then it might be overkill. There is no, I don't think it's
an exact science so you kind of have to use your judgment as to what, at what point you
should sort of break the cord and say no I do need to build specific nine patches for
each of those buckets.
>>Andrew Kelly: Cool. Cheers.
>>Ankur Kotwal: Alright. We've just had one other person join.
>>male #1: Can I ask one more question about the layouts?
>>Ankur Kotwal: Yeah, absolutely.
>>male #1: So going back to my question, it was a question about images from net. For
example, if I have an image 160 pixels, so is it the best option to set the maximum width
like G1 devices or 400 dpi? Otherwise it will be like more than a half screen width, and
leave it as is for hdpi devices in the image view.
>>Ankur Kotwal: So just so I make sure that I've understood your question, do you mean
whether you should scale the image down or shrink it so that it's not occupying too much
physical space on the device?
>>male #1: Yeah.
>>Ankur Kotwal: Yeah, I would, I would definitely do that. I would shrink it where possible.
I mean, where it makes sense. So there is some work that you need to do if you're pulling
assets from some remote server that, whose resolution you don't have any control over.
As to what makes sense for your UI, so if it only makes sense for your, you know, whatever
it is to be only 30 percent of the width of the screen then that's going to, you know,
that 30 percent, the actual number of, the size of it is going to differ depending on
which you're running on. So, yeah, absolutely you'd wanna scale that. Things like linear
layouts can help there because you can set weights and so on and have it done for you
but it really depends how custom built your UI is and how much control you're exerting
over it.
>>Andrew Kelly: Is that what the scale type is for on the image view to say send to fit
or send to crop? That kind of stuff?
>>Ankur Kotwal: Yeah. That's exactly right, yeah. But on top of that if you, so if you're
doing it based on weights then you need the linear layout weights to come through as well
over and above that, right? But the scale type will definitely say, you know, hey if
my view is bigger than the image then what should I do with it? So, yeah.
>>male #1: Thanks.
>>Ankur Kotwal: Alright, well, if there is nothing else thank you for joining us this
week. I suspect that we are going to, we're not going to run the ADL+ next week because
of a scheduling conflict but we will be back soon and, yeah, again keep the feedback coming.
We've had quite a few suggestions for topics that we should cover in the future and we
are definitely taking that on board and prioritizing accordingly.
>>male #2: Hello?
>>Ankur Kotwal: Oh, hi there.
>>male #2: Hi, can I have one question, one more question?
>>Ankur Kotwal: Yeah, absolutely.
>>male #2: I'm the guy with the in app billing problem. You responded before and I have one
question. My first payment was from a credit card where I don't have enough money and that
can be a problem and when I run a different card and after some more payments I've got
cancellation of this payment. Can it be DOS problem? If you understand?
>>Ankur Kotwal: Yeah, so, Tony do you wanna grab this one?
>>male #2: I can show you some screen share.
>>Ankur Kotwal: Yeah, just be careful of not showing any of your credit card details cause
that won't be a good thing. [Laughter]
>>Tony Chen: Maybe we can do this off line you can-
>>male #2: I can show, it's no problem.
>>Ankur Kotwal: No, I don't think we should, actually. I think we, I think it's better
that we don't.
>>Tony Chen: Let's do that offline.
>>male #2: Okay.
>>Ankur Kotwal: When it comes to payment that sort of stuff can be quite sensitive so what
I'd suggest is, look, we'll wrap up the ADL+ here and let's solve, Tony and I will contact
you straight afterwards and we'll continue our discussion through that.
>>male #2: Okay, thank you.
>>Ankur Kotwal: Thank you everyone.
>>Tony Chen: Thank you.