hello, EGHDK!

how can I help you today?

Hello. I was wondering if there was any easy way of finding out the width of a view after I scale it. For example. I Log the getWidth of a view. Then I do view.setScaleX,Y(2) and then log the width again, but its exactly the same.

um, divide by 2?

:-)

or multiply by 2

not sure of your syntax there

Same thing for if I set a But why is my view on the screen clearly doubling in width. but when I request width, it gives me the original width.

But why is my view on the screen clearly doubling in width. but when I request width, it gives me the original width.

because otherwise you get into an infinite scaling loop

now, you could argue that there should be getWidth() and getScaledWidth(), or something like that

in fact, I thought maybe they offered that, but it doesn't look like it

but there has to be a way for the View itself to know is "true" width

Ugh.

you're not changing the intrinsic size of the View by scaling it

you are changing its *effective* size, for how it is drawn, how it handles touch events, etc.

That doesn't make any sense to me.

I need to dynamically tell what the size is of the view.

so what's my best bet.

Holding onto the scale factor ?

call getScaleX(), call getWidth(), and do the math

likewise for getScaleY() and getHeight()

Okay, so that may seemingly solve the first part of my problem.

The second, is that. I want to get the correct coordinates from getLeft, getTop, getRight, getBottom

but after I scale them, I get the original points.

after I scale the view, I get the original points.

Let's say view.getBottom gives me 100, but then I scale the view(2) and I getBottom again, it gives me 100.

short of running the calculations yourself, I don't see an easy way to get those values

While the bottom coord has definitely changed

So can I just change the height and width of the view instead of scaling it?

you can change the LayoutParams that govern its intrinsic height and width

instead of doing view.setScaleX(2) can I just do view.setWidth(view.getWidth*2)

and doing that will affect getWidth(), getLeft(), etc.

setScaleX() is designed for animations

short-lived stuff

Will that change the "instrinsic" size?

changing the LayoutParams? yes

Not the layoutParms? just height and width

you change the height and width by changing the LayoutParams that govern the height and width

there is no setHeight() on Vierw

er, View

there is no setWidth() on View

so I have to do view.setLayoutParams();

yes

LayoutParams params = (height, width)? is that a thing?

I've never had to do that programaticallt before I think.

what is the parent container of this view that you are scaling?

RelativeLayout, but thats just because I don't know what to use.

I think absolute layout would work, but thats depracated.

if you don't know what to use, what you are trying to accomplish?

what is this view that you are scaling?

why are you scaling it?

Okay, so essentially, the app is a blank canvas with one imageview (100 x 100) that starts at 0,0. I want to be able to touch the imageView and drag it around the canvas.

I'm unsure of what to make the root layout. but relativelayout has worked so far.

sounds like that should be done by directly working with the Canvas, rather than mucking around with views

Hrm.... how would I do that?

well, I don't have any code for that, as working at that level is something I generally don't do much

Gotcha.

but, in essence, what you described is a "fingerpaint" scenario, except you are dragging an image rather than drawing a line

interactive elements like that are usually their own widget, working with the Canvas under the covers

for example, a SeekBar (slider) is not made up of a bunch of widgets -- it *is* a widget

the touch events, the movement of the thumb, and so on are drawn by the widget itself

it's not like that's a RelativeLayout holding onto ImageViews or something

Gotcha.

there are books, blog posts, and the like that get into that sort of stuff

Interesting stuff.

my book doesn't

Thanks.

though I dip my toes in those waters a bit here and there

I haven't had a need to get down-and-dirty at that level, so while I know that's the direction to head in, I can't get you there

sometime this year(?), I hope to add a signature capture sample to the book and use that to get more into this level of stuff

now, you *can* accomplish what you want using views the way you are

but you'll find it to be a bit clunky

and keeping the frame rate up (i.e., no jank) may get interesting in spots

So I'm trying the layoutParams route of resizing instead of scaling.

um, well, you have no choice but to lose precision

I mean, you can't force Android to use floats just because

sizes are integers

there are some rounding methods somewhere (Math?)

yeah, Math.round()

I don't know if casting a float to an int rounds or not -- you'd have to look around for that

but round() should work fine

Yup. Round. Cool. No need to typecast afterwards either.

Thanks

I think the whole size instead of scale will solve my problems.

because I'm polling for getLeft and getX and it gets thrown off because of scale.

Do you know of any definitive lifecycle chart for android? for activities and fragments? I'm finding it increasingly difficult to understand how and when to do stuff in fragments. it feels like learning a brand new whacked out version of an activity lifecycle.

So does oncreate and onStart and all of the matching activity lifecycle commands happen at the same time?

the activity's onStart() calls onStart() of its fragments

and so on

So if my activity has three fragments, and the activity calls onStart, then it wont move on until onStart of the three fragments is called?>

that's my understanding

that's easier to see in FragmentActivity from the support package: https://android.googlesource.com/platform/frame...

(starting line 1034)

whoops, sorry, starting line 552

Gotcha. Alright. Thats it for me. Thanks again. as always.

you are very welcome

that's a wrap for today's chat

the transcript will be posted to http://commonsware.com/office-hours/ shortly

have a pleasant day!