I'd like to change the code for the LayoutParams to increase the box area for the header image, so the image actually fills the header area. Can someone point me in the right direction with sample-code snippets that would/might do the trick? (that would certainly be a treat! excuse the seasonal pun:-) OR... Is there another work-around for this non-scaling header image issue for Android in 1.5? (Seems like more members would be mentioning the funny looking small header image) For example, does 1.5 support full screen-shot backgrounds? Maybe that would be a place to start... ANY IDEAS??

Hi in Tampa... I'll give this a shot and try to put some things into simpler terms. Starting with some key concepts. I type fast to keep up with my thoughts so ignore the typos... a) Imagine an layout params object as a box. A box with a width / height / position. Width and height are easy, position is like Left, Center, Right. b) A Layout . XML file is used in many cases to describe this box. Everything on the screen is in it's own box. Buttons, lists, images, etc. All have their own box, their own layout params. c) JAVA class files written in java are compiled code that run when the app is running. Every screen in the app has it's own unique java class file. d) Every screen in the app shares some common things (like a background) so instead of creating each individual java class file (for each screen) starting from scratch, we start them all from a sort of parent class, this is called BT_activity_base.java So, when a screen loads, looking at it in a step-by-step manner....the app first loads the code in the BT_activity_base.java file then the code in the screens own unique class, BT_screen_menuList.java in this case. So, menu screens are really two things, an underlying instance of the BT_activity_base.java file then the BT_screen_menuList.java file. Think of the menuList.java file as being 'overlayed' on top of the base.java file. This is the same approach for all the screen types. BT_screen_webView.m loads 'on top' of the BT_activity_base.java file, map.java, on top of the base.java....you get the idea. On with layout...So, the screen loads the java..but how does it get displayed on the screen. First, starting with the BT_activity_base.java class, because it loads first, it loads up several different views, or boxes, each with their own layout rules. This happens on line 154 of the BT_activity_base.java file where it does setContentView(R.layout.act_base) That is code-speak for...'Hey android, go look at the XML file in the /res/layout folder called act_base.xml and add all the 'boxes' in that file to the screen. We are not yet to the view that goes on top, only the base. It's the job of the act_base.xml file to add a few 5 or 6 empty 'boxes' on the screen that are nothing more than containers. Eventually these containers may get colors, background images, etc. It's the job of the individual screens to determine this. So far, still have an empty screen, with some containers waiting for a possible color or background image, etc. Next, the onCreate method runs for the individual screen type. BT_scren_menuList.m in this case. onCreate for the BT_activity_base.java has alreay run, now Android runs the onCreate in the screen's .java file. That method does several more steps. First, it runs a method called updateBackgroundColorsForScreen, that method is in the BT_viewUtilities class. It's job is to look at the individual screens data, the data in the control panel (the data in the config.txt file) that describes what it should do. It may need to do nothing at all, or it may need to add color, image, etc. to the empty boxes setup earlier. Go ahead and have a look at that method. BT_viewUtilitiies.java > updateBackgroundColorsForScreen. It's pretty straightforward. It finds all the empty boxes and applies colors as needed. On to the header image....so far we have a screen with some background colors / images. Next, we need to determine what parts the individual screen's layout .xml file has layed out. IN this case, a possible header image. Have a look at the screen_menulist.xml file. This is the file that explains in simple terms what goes on the screen. In the case of the header image you'll see it described in the screen_menulist.xml file and named headerImageView You'll also see where the layout is described. layout_width, layout_height, etc. This is in the XML. However, because not all screens use a header image, we may end up hiding this header image 'box' in the java code if we need to. The layout rules for the header image are also going to be different in many cases so we need to create a new layout paramaters object to then OVERWRITE any rules we previously described in the .xml file. Yes, we overwrite these rules in the XML if we have a header image. We do this because not all images are going to be the same size. Have a look at line 278 in the BT_screen_menuList.m file, this is were we create a new RelativeLayout.LayoutParams object. Again, we make this thing so we can apply it to the headerImageView. When we apply it to that view we are in esseence saying 'igore the xml rules for this image view and instead use this new Relative Layout thing. We the relative layout is created, in java terms, we call a thing called a constructor. Constructors take arguments. In this case two arguments, one for with, one for height. Said differently...in order to create a new relative layout object we need to tell it the width / height and we do this in the parenthesis when creating the object. All this happens on line 278. Line 283 is where we actually apply it, after setting it up. Width / Height / Center. In your case, becuase you can do whatever you want with the project and know exactly which screens should do what, you could easily change this logic. You could IGNORE the layout object we create in java altogether and use the XML rules. Or, you could create your own layout object. All this in an effort to figure out how to get your image scaled / sized the way you need. The scale / size issue is still on our priority list (near the top actually) but we do have some other pressing issues with the newly announced bt server release coming in a few days. WE haven't done much in the last few days with this but will re visit it and lots of other Android beta stuff that has surfaced as soon as we can. I think you can get this layout thing figured out yourself for your individual project. Sincerely hope this helps shed some light on some otherwise mysterious stuff about how Android handles it's layout management process.

Very well stated David, but with that said, is it possible to show us sample code snippets that could be used for a Header Image in Android 1.5 for a header that is 320w x 150h? I've dinked with this one for a couple of days to NO avail. Nevertheless, thanks again for EVERYTHING! BuzzTouch is awesome...