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 graphical polish it is necessary to operate with some assumptions such as the target screen size or that the dimensions will not change while the game is running.
I have some ideas that may help for the questions at hand if there is good reason to prioritize pixel counting over flexibility. I haven't tried all these myself so I can't guarantee that they will work. The most rigid way to know what space you are working with is to set your window full screen and hard code the dimensions based on the device that you know you will run on (320x480 for the G1). Obviously this limits you to that one device, and you'll need to do some fancy handling of orientation change or things will go bad. If you want to let the device choose a size for you, but you want to know what this size is and use an absolute layout, try getHeight() and getWidth(). These sound like they should provide you with the correct values, however they are likely not valid until the layout is displayed. To get around this problem you can use a Handler in onCreate () to schedule a Runnable that does initialization to run sometime in the future. Or you could try extending AbsoluteLayout and scheduling initialization with a Handler (and no delay) inside of onDraw(). In this case you can also track the previous height and width and reinitialize when they change to handle screen size changes. 144 buttons is an awful lot. Makes me cringe. It will probably be unusably slow and consume gobs of memory. I totally agree with Dianne here, you need a custom layout for this. 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". Overlapping views works pretty well without any tricks. At least when using XML layouts, those layouts will draw the components in order such that the last layout listed is the one "on top". I've used this with RelativeLayout to put text on top of a background image and AbsluteLayout is also supposed to draw its children on top of each other with an order. I haven't tried moving any of the views around to see how it handles that, but my feeling is that the system will handle overlapping views for you without any work on your part. On Feb 10, 8:32 pm, Dianne Hackborn <hack...@android.com> 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 <sunns...@gmail.com> 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 > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
