The way I expected it to work is that my custom view is passed a Canvas
object on which it can draw itself. I expected the canvas to be the size of
the custom view. Lets say 48 by 48. The custom view draws itself in the
range of 0 to 48. However, if the custom view is passed a canvas that is
Because all Views draw on the same canvas, it would be unnecessary and
wasteful to give each View a different Canvas. Also, since they all
end up drawing on the same screen, it makes more sense that they all
share the same Canvas.
Instead of relying on the Canvas' dimensions, simply use the
This is precisely why I want to know the dimensions of the screen. When I
redraw anything I have on the screen, I want to be able to get an accurate
size (exactly so that I can dynamically put things in the right place as it
changes). The challenge is that the onDraw() method in my custom View
I agree with Dianne about trying to use what is available to make your
application as flexible as possible. But I also get the impression
that people are asking these kinds of questions because they want to
write games, not standard apps. There can be cases when for purposes
of speed or over all
144 buttons is an awful lot. Makes me cringe. It will probably be
unusably slow and consume gobs of memory.
Creditably to the Android developers, you are incorrect. It runs
blindingly fast and has a very small footprint. So far 84,000 users
like it just fine.
If you knew what the app was, you'd
I'll go one farther and say
you probably need a custom view object so that you can draw the entire
area for the buttons as one object and map touch event coordinates to
the correct virtual button.
Heh. Surely you're not saying Java doesn't scale? ;)
The answer is you don't use AbsoluteLayout. Seriously. It is trivial to
place a button at the bottom right corner of the screen with various other
layout managers, and those will take care of doing the right thing for the
actual screen space.
On Tue, Feb 10, 2009 at 1:03 PM,
Believe me, I see your point, but there are applications this simply
won't work for. Mine, for instance, requires up to 144 precisely
positioned, size-changing, overlapping-but-not-colocated buttons on
the screen (not in a grid), and there simply isn't any other way to do
it. I certainly
Then just write your own layout manager that does your own special
positioning algorithm. This is likely to be faster than using
AbsoluteLayout, anyway, especially if the screen dimensions change on you
and you need to do a relayout.
On Tue, Feb 10, 2009 at 3:15 PM, Sundog sunns...@gmail.com
This seems to be a very hot topic.
It turns out, if I only had that single button in the app, I would not have
a problem. :) I have an app with several overlapping views. That button,
(or actually a custom view) needs to sit on top of something else that can
move behind it. Is there a layout
Great suggestion, thanks.
On Feb 10, 4:47 pm, Dianne Hackborn hack...@android.com wrote:
Then just write your own layout manager that does your own special
positioning algorithm. This is likely to be faster than using
AbsoluteLayout, anyway, especially if the screen dimensions change on you
Could somebody on the thread perhaps explain why this is so rigid?
So many
people are asking for such a very simple thing. I'd really like to
understand.
It's a Java thing. ;) You VILL fit ze paradigm! Resistance is futile!
--~--~-~--~~~---~--~~
You received
It's not that, it's that making assumptions about you having all of the
available space on the screen and that it will never change after you start
will make your application very rigid. For example, in the future when
there is a soft keyboard that gets shown, wouldn't you like your application
13 matches
Mail list logo
