[android-developers] Transparent background overlay of SurfaceView broken on 1.5
I believe I have found a graphics bug introduced in the 1.5 platform. I'm looking for some confirmation (or a description of what I'm doing wrong) before reporting it as a real bug. I have a SurfaceView that fills the screen and on top of that I have a LinearLayout that wraps some other components that overlay the surface. These other components are not visible most of the time, and the LinearLayout has a transparent background so that the SurfaceView is unobstructed until the other components are made visible. Under 1.0 and 1.1 this all worked with a background of # for the LinearLayout. Now under 1.5 there is a black rectangle obstructing my surface unless I give the LinearLayout background some color. I can still keep the transparency so it is still invisible as it should be but it is strange that it can't be black and invisible anymore. My layout is below. The background of #0001 works, but changing it to # results in a black rectangle. RelativeLayout xmlns:android=http://schemas.android.com/apk/res/ android android:layout_width=fill_parent android:layout_height=fill_parent android:keepScreenOn=true android:background=#000 SurfaceView android:id=@+id/surface android:layout_width=fill_parent android:layout_height=fill_parent/ LinearLayout android:layout_width=fill_parent android:layout_height=wrap_content android:background=#0001 android:paddingRight=85dp android:layout_centerInParent=true android:orientation=vertical android:gravity=center_horizontal TextView android:id=@+id/game_large android:layout_width=wrap_content android:layout_height=wrap_content android:paddingBottom=8dp android:background=# android:textColor=# android:shadowColor=#FF00 android:shadowRadius=6 android:textSize=36sp android:textStyle=bold android:visibility=invisible android:text=@string/paused/ TextView android:id=@+id/game_small android:layout_width=wrap_content android:layout_height=wrap_content android:layout_centerHorizontal=true android:background=# android:textColor=# android:shadowColor=#FF00 android:shadowRadius=3 android:textSize=18sp android:textStyle=bold android:visibility=invisible android:text=@string/paused_detail/ /LinearLayout /RelativeLayout --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Black Screen problem with graphics update using unlockCanvasAndPost()
You definitely need to do your game loop on a different thread. If
your game loop is running in the main UI thread then while it is
running the screen can't update and you can't get input events. The UI
thread is what does these things.
On Apr 15, 10:25 pm, Warren warrenba...@gmail.com wrote:
Sarnoth, I appreciate you taking the time to comment.
Does that matter - if the thread isn't different?
Just in case there were problems with the thread, I rewrote the
program not to use a second thread and just execute the drawing loop
in the view.
In the code sample, I also changed draw() to drawSprites(), as I
described in an earlier post. Neither of these things helped.
== Begin Code ==
package com.baltz.scorched;
import android.content.Context;
import android.content.res.Resources;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.graphics.Canvas;
import android.util.AttributeSet;
import android.util.Log;
import android.view.SurfaceHolder;
import android.view.SurfaceView;
class ScorchedView extends SurfaceView implements
SurfaceHolder.Callback {
private Context context;
private SurfaceHolder holder;
private Bitmap backgroundImage;
private Bitmap foregroundImage;
private Bitmap spriteImage;
private Resources resources;
private ScorchedTerrain terrain;
private Engine engine;
public ScorchedView(Context c, AttributeSet attrs) {
super(c, attrs);
// register our interest in hearing about changes to our
surface
holder = getHolder();
holder.addCallback(this);
context = c;
resources = context.getResources();
// load background image as a Bitmap instead of a Dable b/c
// we don't need to transform it and it's faster to d this way
backgroundImage = BitmapFactory.decodeResource(resources,
R.drawable.earthrise);
foregroundImage = BitmapFactory.decodeResource(resources,
R.drawable.foreground1);
spriteImage = BitmapFactory.decodeResource(resources,
R.drawable.sprite1);
terrain = new ScorchedTerrain(foregroundImage);
engine = new Engine();
Body body;
body = new Body(spriteImage);
body.setLocation(50, 50);
engine.addBody(body);
body = new Body(spriteImage);
body.setLocation(40, 100);
engine.addBody(body);
}
/* Callback invoked when the surface dimensions change. */
public void surfaceChanged(SurfaceHolder h, int format, int width,
int height) {
holder = h;
}
/*
* Callback invoked when the Surface has been created and is ready
to be
* used.
*/
public void surfaceCreated(SurfaceHolder h) {
holder = h;
gameLoop();
}
/*
* Callback invoked when the Surface has been destroyed and must
no longer
* be touched. WARNING: after this method returns, the Surface/
Canvas must
* never be touched again!
*/
public void surfaceDestroyed(SurfaceHolder holder) {
}
private void gameLoop(){
Canvas canvas;
int i=0;
while(i30){
canvas = null;
try {
canvas = holder.lockCanvas(null);
engine.update();
drawSprites(canvas);
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (canvas != null) {
Log.w(dbg, unlocking canvas + i);
holder.unlockCanvasAndPost(canvas);
}
}
try{
Thread.currentThread().sleep(300);
}
catch(Exception e){
}
i++;
}
}
/**
* Draws the sprites and background to the provided
* Canvas.
*/
public void drawSprites(Canvas canvas) {
// Draw the background image. Operations on the Canvas
accumulate
// so this is like clearing the screen.
canvas.drawBitmap(backgroundImage, 0, 0, null);
//draw the up-to-date, deformed foreground
terrain.draw(canvas);
//draw all bodies (players, projectiles, etc) on the screen
engine.drawAll(canvas);
}
}
On Apr 15, 4:47 pm, Sarnoth jesse.st...@gmail.com wrote:
I can't really say without seeing more of the code, but based on your
description of the problem I wonder if your thread is in fact a
separate thread or if the run method is simply being executed in the
main UI thread. Something worth checking. You can log
Thread.currentThread().getName() from inside your run method and from
[android-developers] Re: Black Screen problem with graphics update using unlockCanvasAndPost()
I can't really say without seeing more of the code, but based on your description of the problem I wonder if your thread is in fact a separate thread or if the run method is simply being executed in the main UI thread. Something worth checking. You can log Thread.currentThread().getName() from inside your run method and from inside your activity's onCreate method to make sure they are different. On Apr 15, 9:57 am, Warren warrenba...@gmail.com wrote: I may have found my problem. The SurfaceView class implements a function called draw(Canvas). I unwittingly created my own function draw() with the same signature, overriding the original. I'm guessing that the SurfaceView probably calls draw() during unlockCanvasAndPost(). But instead of executing its original draw() method and doing what it is supposed to do, it calls my function - simply overwriting the canvas buffer without affecting the Surface at all... thus the black screen. I'm still confused about why it eventually shows. Perhaps some final cleanup code... I will test this tonight when I have access to my development computer and post my findings. On Apr 15, 8:48 am, Warren warrenba...@gmail.com wrote: Thanks for the comment ellipsoidmobile. If I remove the sleep, I still don't see anything until the very end. I don't need that sleep in there for the application. I only put it in so that, hopefully, I could see what was happening a little better. Also, I thought that the SurfaceView allowed you to write to the screen at your own pace, whatever that may be. So in this case, there would be nothing from the outside that's causing a screen refresh. The screen should stay how I left it until I post a new canvas. Am I misunderstanding this? What really confuses me is why the last call to unlockCanvasAndPost() does work. It seems like if an error prevented the first calls from functioning, then it would also prevent the last. On Apr 15, 3:09 am, ellipsoidmob...@googlemail.com ellipsoidmob...@googlemail.com wrote: The problem is your line Thread.currentThread().sleep(1000);//sleep for 1000 ms I believe with SurfaceView you have to draw your whole view on everyscreenrefresh. You just need to loop as fast as possible and the system will throttle the speed in the calls to lockCanvas(). By sleeping for 1 second you are failing to provide a canvas for every refresh so thescreenappears blank. What I don't know is whether there is any guidance on how quickly you have to get through your loop, i.e. what the maximum refresh rate is --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: How the use same instances when launching application twice
Haven't we been over this before? http://groups.google.com/group/android-developers/browse_thread/thread/bd020f8b809a6e56/e8b9520e43410abd On Apr 14, 2:53 am, Neo mobi.liub...@gmail.com wrote: My app has 4 activities on the stack A-B-C-D (top) If you press home and re-enter the application, another instance of A is started, so the stack is A-B-C-D-A (top). I know this because when I press BACK, A is popped off and I now see D (instead of going to the Home screen). What I want is that when the user re-enters the app, they re-enter on the same activity they were in before (D). function Intent intent; intent = new Intent(); intent.setClass(this, LoginActivity.class); startActivity(intent); finish(); i tested add the android:launchMode=singleTask no changed ?xml version=1.0 encoding=utf-8? manifest xmlns:android=http://schemas.android.com/apk/res/android; package=com.pica.msn android:versionCode=1 android:versionName=1.0.0 uses-permission android:name=android.permission.READ_PHONE_STATE/ uses-permission android:name=android.permission.INTERNET/ application android:icon=@drawable/icon android:label=@string/app_name activity android:name=.SplashActivity android:launchMode=singleTask android:label=@string/app_name intent-filter action android:name=android.intent.action.MAIN / category android:name=android.intent.category.LAUNCHER / /intent-filter /activity activity android:name=.LoginActivity android:launchMode=singleTask android:label=@string/app_name /activity activity android:name=.MainActivity android:launchMode=singleTask android:label=@string/app_name android:theme=@android:style/Theme.Light /activity /application /manifest --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: How the use same instances when launching application twice ?
I posted with this same problem before and then it just seemed to disappear so I replied to my own post with a never mind, it works now and no real resolution. Well, as I've continued to develop I've run in to it again and figured out what is going on. There is a problem with the development environment that causes this. When an app is run through the IDE either on a real device hooked up to the USB port or on the emulator it will exhibit this behavior as follows: 1. Hit run in IDE 2. App launches with activity A 3. Navigate to activity B 4. Press the home button 5. Click the app icon to return to the app 6. App appears with activity A on top 7. Press back and activity B is revealed, back again returns to activity A, and a third back returns to the home screen This problem is present for every combination manifest and activity launch options that I have tried. The problem is avoided by exiting the app after hitting run in the IDE: 1. Hit run in the IDE to load the new version of the app but DO NOT use it when it runs 2. Hit back to exit the app and return to the home screen 3. Launch the app from the icon, activities will work properly now 4. Navigate from A to B 5. Hit home 6. Click the app icon, you are turned to B as expected On Apr 4, 9:58 pm, Dianne Hackborn hack...@android.com wrote: As I've said, what you are saying you want is the normal behavior. To everyone, you must give -detailed- information about exactly what you are doing for there to be any hope of someone being able to help you. In particular, provide: (1) Your complete AndroidManifest.xml (2) The exact code you are using to build your Intent objects that you are using to start your activities. (3) Likewise exactly how you are constructing any PendingIntent being used with notifications etc. (4) The exact sequence of activities you are seeing started, and what you instead expect to have started; supplying the Starting activity logs as you do the steps can also help a lot. (5) It also would tremendously help to supply the output of adb shell dumpsys activity immediately before you are going to get in to the problem state, along with the code you are executing to get in to the problem state, and also the Starting activity log statement at the point where the problematic activity launch happens. On Fri, Apr 3, 2009 at 11:05 PM, Lovell hodayath...@gmail.com wrote: I think I have the same question, but I'm going to try to explain it a little better: My app has 4 activities on the stack A-B-C-D (top) If you press home and re-enter the application, another instance of A is started, so the stack is A-B-C-D-A (top). I know this because when I press BACK, A is popped off and I now see D (instead of going to the Home screen). What I want is that when the user re-enters the app, they re-enter on the same activity they were in before (D). How do you do that? On Mar 20, 12:05 pm, Dianne Hackborn hack...@android.com wrote: Um, what you are requesting is the normal behavior. When you tap on an app's icon in home, it brings the current task of that app to the foreground if it is already running. And services are singletons so you can only every get a single instance of a service running. On Tue, Mar 17, 2009 at 2:26 AM, Derek cram.de...@gmail.com wrote: Hi, Is it possible to re-use all the instances of Activities and Services when an application is launched twice. For instance: 1/ I start my application APP1. Some activities are launched and a service is started. 2/ I click Home device button 3/ I can see the icon the launch again my application APP1 4/ I click on it and the APP1 is launched twice I would like to re-use the existing the instances of Activities and Services from the first launch. I guess it is related to SingleTop or SingleTask but it doesn't seem to work. Any suggestion ? -- 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. -- 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, and so won't reply to such e-mails. 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
[android-developers] Re: how to color key 2d sprite backgound?
I tried this out and unfortunately it is not a good solution. AvoidXfermode is implemented very inefficiently such that each pixel is converted to 32 bits, run through an alpha calculation, and then converted back to 16 bits. Based on the documentation of the tolerance parameter I was hoping for a shorcut mode when it was set to 0 that simply did a compare and write with no conversions. On Mar 24, 4:20 am, Tazzer arjenvanha...@gmail.com wrote: A very interesting idea :) although I have my doubts that drawing with AvoidXfermode is not slower then drawing with alpha. Especially when drawing the complete background in this mode. If I have the time I certainly would like to try it. I now have the alpha issue working using the solution above. Cheers On Mar 23, 3:35 am, Sarnoth jesse.st...@gmail.com wrote: I have been frustrated by the lack of support for sprites, but I came up with an idea that is backwards (literally) but might work. I haven't tested it to make sure it works as expected or to evaluate its speed. If you try it yourself I would be interested in the results. Use the same key color for all of your sprites. To draw a frame, clear the canvas to the key color. Then draw each sprite starting with the front most and ending with the back most, and finally draw the background image. When drawing use AvoidXfermode with opColor set to your key color, tolerance set to 0, and mode set to TARGET. Drawing bitmaps of format 565 (no alpha channel) is by far the fastest way to draw, so hopefully drawing color keyed bitmaps of this type will produce nice results. On Mar 19, 2:23 am, Tazzer arjenvanha...@gmail.com wrote: Hi, I am working on a 2d library for creating a game including sprite collisions, sorting and animation converting (.spr to Java classes/ bmp's). At first I used png's with the background color being transparant (24 bits png image) but I want to use 256 color bitmaps with the background color being transparant. Is this possible to do color keying in android? I looked at several other threads about this topic but the all ended without a solution. Also I am now using the canvas.drawBitmap to render my sprites, but will using opengl be faster? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: how to color key 2d sprite backgound?
I have been frustrated by the lack of support for sprites, but I came up with an idea that is backwards (literally) but might work. I haven't tested it to make sure it works as expected or to evaluate its speed. If you try it yourself I would be interested in the results. Use the same key color for all of your sprites. To draw a frame, clear the canvas to the key color. Then draw each sprite starting with the front most and ending with the back most, and finally draw the background image. When drawing use AvoidXfermode with opColor set to your key color, tolerance set to 0, and mode set to TARGET. Drawing bitmaps of format 565 (no alpha channel) is by far the fastest way to draw, so hopefully drawing color keyed bitmaps of this type will produce nice results. On Mar 19, 2:23 am, Tazzer arjenvanha...@gmail.com wrote: Hi, I am working on a 2d library for creating a game including sprite collisions, sorting and animation converting (.spr to Java classes/ bmp's). At first I used png's with the background color being transparant (24 bits png image) but I want to use 256 color bitmaps with the background color being transparant. Is this possible to do color keying in android? I looked at several other threads about this topic but the all ended without a solution. Also I am now using the canvas.drawBitmap to render my sprites, but will using opengl be faster? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Using ColorFilter to remove image background?
I was expecting to find a way to handle sprites with a color-keyed background but I haven't found a way. This is certainly on my wish list for future SDKs. There is AvoidXfermode but it does the opposite of what we want, keying off of a color on the destination instead of on the source. I've had to work around this missing feature by using sprites with an alpha channel, but this has a significant impact of speed. I believe that what you are doing with a ColorFilter is actually transforming the colors of your bitmap using your specified color as the source and your bitmap as the destination in the PorterDuff calculations. The result of this color transformation is then drawn on the canvas. On Mar 2, 7:33 pm, Bill sax...@gmail.com wrote: I have some 2d character sprites, with a greenish background, that I'm trying to display, without the background. Since the background is a consistent color, I assumed there'd be a way to filter it out, thereby making the background transparent. I wonder if I'm right in assuming this... Here is my code: Drawable d = mContext.getResources().getDrawable(R.drawable.queen); d.setColorFilter(Color.parseColor(#585C38), PorterDuff.Mode.DST_IN); d.setBounds(0, 0, 100, 100); d.draw(canvas); I've tried all of the PorterDuff modes and none of them seem to do the right thing. In fact, it looks like the color is ignored all together. Any ideas what I might be doing wrong? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: surffaceHolder.lockCanvas(dirtyRect) help?
I've been playing around with various drawing techniques myself and came across a few things that might help you (and others). It seems that the preferred color mode of the G1 is RGB_454 if you don't specify another type for your surface, and it runs much faster in this mode. When drawing on such a surface it is much faster if your bitmaps are RGB_454 or ARGB_. To take advantage of this as much as possible I keep an in-memory RGB_454 bitmap the size of the screen that has the background and anything that is relatively static already drawn on it. Drawing the entire screen from the static bitmap only takes 3ms which leaves plenty of time to draw your dynamic pieces on top and you don't even have to worry about fencing off dirty rectangles (although I'm sure that would help speed things up even more). On Feb 26, 11:58 am, snctln catlin.s...@gmail.com wrote: Thank you very much for this reply, your advice about not using a high quality png seemed to make all of the difference... My problem wasn't with the png really but was more the way that I was working with the png I was loading the png into a bitmap, and then resizing that bitmap as needed for the background, BUT I was going about it all wrong Old Attempt m_backgroundBmp = Bitmap.createBitmap(backgroundWidth, backgroundHeight, Bitmap.Config.ARGB_); m_backgroundPngDrawable.setBounds(backgroundRect); Canvas c = new Canvas(backgroundBmp); m_backgroundPngDrawable.draw(c); New Attempt (from lunarlander) m_backgroundBmp = BitmapFactory.decodeResource(context.getResources(), R.drawable.background); m_backgroundBmp = Bitmap.createScaledBitmap(m_backgroundBmp , backgroundWidth, backgroundHeight, true); I didn't change any of my actual drawing code, just this bitmap loading/sizing code, and I went from about 24 fps to 60 fps, I guess that is teh difference between with with a 24 bit bitmap and a 32 bit bitmap I know I need to do some more profiling and work on my timestep code, but this definitely helps a lot, thanks. So in summary I am still not sure why I was seeing flickering when using very small rectangles, probably just errors in my code and not drawing the whole rectangle I guess. I am using the lockCanvas(dirtyRect) on a large region of the screen and am getting a nice performance increase over redrawing the whole screen Thanks again ---snctln On Feb 26, 3:05 am, Stoyan Damov stoyan.da...@gmail.com wrote: On Thu, Feb 26, 2009 at 5:53 AM, snctln catlin.s...@gmail.com wrote: Stoyan, I appreciate the reply (especially because I believe we have competing games up on the paid market). np :) It's not that I'm sharing a trade secret here. I will go back and look at my code again, I am probably doing it wrong... currently I have 4 approaches to updating the screen Approach #1 - (Original Approach) Update the whole surface, this works ok (30 fps) when I just have a solid color background , but once I add in a complex bitmap to the background the performance falls to about 18-20 fps Are you doing too many updates (as opposed to drawings)? 30 fps doesn't look right. With 50 blocks and music (not sfx) turned off I'd get ~60 fps. Now here's a trade secret ;) -- careful with the background, I wouldn't use a high quality .png. You need to time the time you spend in updates and the time in drawing - if it's something like ~70 (drawing) / ~30 (updates) you'll probably get high fps. Approach #2 - Specify A large dirty rect that encompasses all possible areas of update (things that can change multiple times a second), this yields great results for solid color background (60 fps), but still only gives me 24fps or so for a complex bitmap background This is the approach I use although a bit modified because of the specifics of my game - I have 2 dirty rectangles which I switch every now and then - one is bigger than the other and encompasses it. Approach #3 - Draw the current screen state to a bitmap member variable, and make multiple calls to lockCanvas(DirtyRect) and specify only the areas that have changed and then do a drawBitmap and copy the regions from the screen bitmap member variable to the canvas, this approach seems to be the worst as it has the most flicker and artifacts I wouldn't do that. How many fps have you squeezed using this approach (if you do use it)? Approach #4 - Draw to a bitmap like in approach #3, but rather than doing multiple lockCanvas calls, just add all of the rectangles together to get one large rectangle that encompasses all of the areas that need to be updated and call lock canvas on that then draw to that area from the bitmap, this seems to work better the #3 but stil leaves artifacts Haven't tried that either. Did you take any of these approaches? I probably have holes in my code and will be going over it all tonight. You need to profile your game
[android-developers] Re: viewable area
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 -~--~~~~--~~--~--~---
