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 the size of the entire screen, how does it know where to draw itself? In this way, the custom view then has to know where to draw itself! (i.e., width-48, height-48)
Why are individual views always passed a canvas object the size of the entire screen? -Matthew On Thu, Feb 12, 2009 at 5:33 AM, Dianne Hackborn <[email protected]>wrote: > I don't think we have an example in ApiDemos of writing a custom layout > manager, but you can certainly look at the code of the ones included with > the platform. > > At any rate, you don't look at the Canvas for any kind of layout, that can > be arbitrarily sized for whatever reason. Currently it is big enough to > cover the status bar as well, since you can hide the status bar at any time. > > So yes, the size of the view is reported to it during the layout process. > > > On Wed, Feb 11, 2009 at 10:41 AM, Matthew LeMieux <[email protected]>wrote: > >> 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 is >> passed a canvas that is bigger than the viewable area. The canvas I am >> passed when using the AbsoluteLayout is 320x480 in portrait mode, but the >> 480 is obviously too big due to the status bar. Unless this is a bug, it is >> still not clear to me where the correct viewable area (the dynamic one from >> right now) is reported. >> Your suggestion, though that I should make my own Layout is well taken. >> Is there an example of subclassing ViewGroup that you can point me to? >> >> It looks like I only really need to override: onLayout(boolean changed, >> int l, int t, int r, int b) >> >> (it is unclear in the documentation whether or not I need to override the >> dispatchWindowFocus... methods... all others appear to be optional) >> >> This is great if those dimensions are indeed the actual viewable area. >> Correct? >> >> Getting back to the original question, is this the place where the >> viewable area is reported to the application? >> >> >> Thank you for your help, >> >> Matthew >> >> >> On Tue, Feb 10, 2009 at 5:32 PM, Dianne Hackborn <[email protected]>wrote: >> >>> 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 >>> to resize to account for that? Or if someone does a device with a little >>> larger screen but some kind of system controls that can be placed in that >>> area, wouldn't you like your UI to grow to use that space if those controls >>> are hidden? >>> >>> Assuming that you can just look at the screen dimensions when you >>> initialize and count on that being constant for the rest of your life just >>> doesn't work. It isn't even true on Windows where the use can drag the >>> taskbar up to make it larger and stuff. >>> >>> So the right approach is to use what the system gives you, write a layout >>> view that does its layout based on the size it is given, and then whenever >>> the display configuration changes you will just get called again with a new >>> size and can layout to that. >>> >>> On Tue, Feb 10, 2009 at 5:13 PM, Sundog <[email protected]> wrote: >>> >>>> >>>> "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! >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> [email protected] >>> >>> Note: please don't send private questions to me, as I don't have time to >>> provide private support. All such questions should be posted on public >>> forums, where I and others can see and answer them. >>> >>> >>> >>> >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
