[android-developers] Re: screen compatibility not quite right
I have to say that Android's screen compatibility worked out really well for me. My app specifies all positions using DIPs, and it worked on the DROID without any change (or even recompilation -- the app was built using SDK 1.1). Essentially all screen coordinates were scaled by 1.5, and bitmaps were also scaled by 1.5, in BOTH directions. The only problem I still have is with WebView + JavaScript. The coordinates returned by obj.offsetTop, etc, in JavaScript are shrunk by 1.5x when running on DROID, even if I specified the following in AndroidManifest.xml: supports-screens android:largeScreens=true android:normalScreens=true android:smallScreens=false android:anyDensity=true / That wasn't too hard to work around, but I wonder if there's a disable compability mode switch in WebView On Nov 22, 12:16 am, Dianne Hackborn hack...@android.com wrote: On Sat, Nov 21, 2009 at 4:26 PM, Mark Murphy mmur...@commonsware.comwrote: DROID has been optimized to display wide-screen multimedia (movie) content at its native aspect ratio of 16/9. This is different from the HVGA aspect ratio of 3/2, which is the traditional computer screen format. What this means is that when content is scaled up to full screen, the horizontal (X*1.5) and vertical (Y*1.77) scaling factors are different. As a result, when displaying the same bitmap as a full screen background, round circles can appear as ovals, and squares are elongated to rectangles. http://developer.motorola.com/docstools/library/Support_for_Multiple_... I have no reason to believe this is DROID-specific, but rather is how Android scales things in WVGA800/WVGA854, when you do not supply your own pre-scaled resources. I think what they are trying to say is correct, but probably misleading. First, scaling is only done based on density, and does NOT change aspect ratio. If you are on a high density device, and your assets are medium density, they will be scaled by 1.5 in both width and height, period, end of story. What this Motorola doc is describing is what I would consider a special case. If you make a layout that is fill parent for both width and height, then on a WVGA of course it will be taller than on HVGA because the screen you are filling is taller. Now if you set a drawable as its background, the View class draws its background by simply stretching the drawable to fill its contents, so your bitmap will be stretched to fill whatever aspect ratio your layout has ended up being. This is just a matter of accounting for the screen being different sizes and designing your layout to adjust accordingly. You cannot control the aspect ratio, as that is dictated by the physical parameters of the screen. AFAIK, there is no Android equivalent of letterbox that would put black bars on either side of your app and give you a smaller virtual screen with 3/2 aspect ratio. We actually do a postage stamp for apps on large screens, since we found that a significant number of them broke when given so much extra space. However, the vast majority of existing apps work reasonably well when presented with a WVGA screen, so rather than cause all of the existing ones to not be able to use that space, we decided to not provide compatibility for that and live with the small handful that did have significant problems. But for someone writing an app today, this is fairly irrelevant, because if your app really can't use anything more than an HVGA screen then you really just need to design your layout to center or whatever you want your content in whatever screen you are running on. Also in my layout I am positioning some items using pixel positions. Should I convert these to dpi? If you mean dip (density-independent pixels), perhaps. It depends on what the pixels represent. There is no hard-and-fast rule. But the vast majority of time, yes, you do want to use dpis. However! The original post showed that the app was actually saying it can't deal with densities. This means the system will emulate a medium density screen on whatever density the device is, so 1 px == 1 dip. However, you really should not be saying that you don't support densities -- there are artifacts that can happen when doing this, such as font metrics not being quite right. If you are writing an app today, you really want to not put yourself in compatibility mode, and just write the app correctly. -- 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
[android-developers] Re: screen compatibility not quite right
Thanks for the info. OK I figured out instead of using fill_parent in width and height of my main LinearLayouts, I instead hardcode the HVGA size of 320 x 480px the aspect ratio is ok. The game is looking much better in compatible mode. Except seems like in compatible mode gravity of center_vertically is not working correctly? The container of the textview I am trying to center vertically is in a LinearLayout with height = 480px however it is still centering within the WVGA screen height. What can I do to fix this? I have to rely on compatible mode unfortunately as there is too many graphics to redraw for different resolutions and no money to pay the designer :D On Nov 22, 7:16 pm, Dianne Hackborn hack...@android.com wrote: On Sat, Nov 21, 2009 at 4:26 PM, Mark Murphy mmur...@commonsware.comwrote: DROID has been optimized to display wide-screen multimedia (movie) content at its native aspect ratio of 16/9. This is different from the HVGA aspect ratio of 3/2, which is the traditional computer screen format. What this means is that when content is scaled up to full screen, the horizontal (X*1.5) and vertical (Y*1.77) scaling factors are different. As a result, when displaying the same bitmap as a full screen background, round circles can appear as ovals, and squares are elongated to rectangles. http://developer.motorola.com/docstools/library/Support_for_Multiple_... I have no reason to believe this is DROID-specific, but rather is how Android scales things in WVGA800/WVGA854, when you do not supply your own pre-scaled resources. I think what they are trying to say is correct, but probably misleading. First, scaling is only done based on density, and does NOT change aspect ratio. If you are on a high density device, and your assets are medium density, they will be scaled by 1.5 in both width and height, period, end of story. What this Motorola doc is describing is what I would consider a special case. If you make a layout that is fill parent for both width and height, then on a WVGA of course it will be taller than on HVGA because the screen you are filling is taller. Now if you set a drawable as its background, the View class draws its background by simply stretching the drawable to fill its contents, so your bitmap will be stretched to fill whatever aspect ratio your layout has ended up being. This is just a matter of accounting for the screen being different sizes and designing your layout to adjust accordingly. You cannot control the aspect ratio, as that is dictated by the physical parameters of the screen. AFAIK, there is no Android equivalent of letterbox that would put black bars on either side of your app and give you a smaller virtual screen with 3/2 aspect ratio. We actually do a postage stamp for apps on large screens, since we found that a significant number of them broke when given so much extra space. However, the vast majority of existing apps work reasonably well when presented with a WVGA screen, so rather than cause all of the existing ones to not be able to use that space, we decided to not provide compatibility for that and live with the small handful that did have significant problems. But for someone writing an app today, this is fairly irrelevant, because if your app really can't use anything more than an HVGA screen then you really just need to design your layout to center or whatever you want your content in whatever screen you are running on. Also in my layout I am positioning some items using pixel positions. Should I convert these to dpi? If you mean dip (density-independent pixels), perhaps. It depends on what the pixels represent. There is no hard-and-fast rule. But the vast majority of time, yes, you do want to use dpis. However! The original post showed that the app was actually saying it can't deal with densities. This means the system will emulate a medium density screen on whatever density the device is, so 1 px == 1 dip. However, you really should not be saying that you don't support densities -- there are artifacts that can happen when doing this, such as font metrics not being quite right. If you are writing an app today, you really want to not put yourself in compatibility mode, and just write the app correctly. -- 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
Re: [android-developers] Re: screen compatibility not quite right
On Sun, Nov 22, 2009 at 1:50 AM, rukiman ruksh...@optushome.com.au wrote: Except seems like in compatible mode gravity of center_vertically is not working correctly? The container of the textview I am trying to center vertically is in a LinearLayout with height = 480px however it is still centering within the WVGA screen height. What can I do to fix this? Compatibility mode does not hide the fact that the screen is WVGA. The screen you see is still that tall, so any layout you do will be within that screen. I have to rely on compatible mode unfortunately as there is too many graphics to redraw for different resolutions and no money to pay the designer :D Turning off compatibility mode doesn't mean you need to have graphics for every density; the system will still scale graphics if they aren't in the density of the screen (in fact it can do this better because it doesn't at the same time need to make your app think the graphics are not scaled). And the new APIs give you a lot more control over how the scaling happens -- for example you can much more easily have them scaled at load time, rather than this happening at draw time and potentially significantly slowing down your app. -- 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: screen compatibility not quite right
Compatibility mode does not hide the fact that the screen is WVGA. The screen you see is still that tall, so any layout you do will be within that screen. But in here http://developer.android.com/reference/android/view/Gravity.html it says CENTER_VERTICAL = Place object in the vertical center of its container, not changing its size. So the parent of the textview is the LinearLayout (is this not its containter?). And if the LinearLayout is hardcoded to 480px height shouldn't that textview be centered within it instead of screen height centered? -- 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: screen compatibility not quite right
I thought I'd create my own specialized LinearLayout so that I can
calculate the aspect ratio and center vertically. My game is only
designed to be played in portrait mode. However this code doesn't seem
to work. Spot what I am doing wrong?
import android.content.Context;
import android.util.AttributeSet;
import android.view.ViewGroup;
import android.widget.LinearLayout;
public class SpecialLinearLayout extends LinearLayout {
private final Context context;
public SpecialLinearLayout(Context context, AttributeSet attrs) {
super(context, attrs);
this.context = context;
}
protected void onLayout(boolean changed, int l, int t, int r, int
b) {
int width = r - l;
int height = b - t;
float aspect = 480.0f / 320.0f;
int newheight = (int) Math.floor((float) width * (float)
aspect);
if(newheight != height) {
// create top margins to center vertically
ViewGroup.MarginLayoutParams margin = new
ViewGroup.MarginLayoutParams(this.getLayoutParams());
margin.setMargins(0, 40, 0, 50);
this.setLayoutParams(new LinearLayout.LayoutParams
(margin));
}
}
}
On Nov 22, 11:26 am, Mark Murphy mmur...@commonsware.com wrote:
rukiman wrote:
This is working almost 90% for my game except when testing in WVGA
screen resolution, all my images are scaled incorrectly, it is longer
vertically than horizontally. I was expecting the screen compatibility
to maintain aspect ratios as that of HVGA.
No.
DROID has been optimized to display wide-screen multimedia (movie)
content at its native aspect ratio of 16/9. This is different from the
HVGA aspect ratio of 3/2, which is the traditional computer screen
format. What this means is that when content is scaled up to full
screen, the horizontal (X*1.5) and vertical (Y*1.77) scaling factors
are different. As a result, when displaying the same bitmap as a full
screen background, round circles can appear as ovals, and squares are
elongated to rectangles.
http://developer.motorola.com/docstools/library/Support_for_Multiple_...
I have no reason to believe this is DROID-specific, but rather is how
Android scales things in WVGA800/WVGA854, when you do not supply your
own pre-scaled resources.
Also in my layout I have a scrollview and it is designed in such a way
that in HVGA when it is not scrolled down, the items are hidden away,
however now in WVGA those things are shown. If the aspect ratio of
HVGA is maintained I won't have this issue.
How can I make sure the aspect ratio is maintained?
You cannot control the aspect ratio, as that is dictated by the physical
parameters of the screen. AFAIK, there is no Android equivalent of
letterbox that would put black bars on either side of your app and
give you a smaller virtual screen with 3/2 aspect ratio.
Also in my layout I am positioning some items using pixel positions.
Should I convert these to dpi?
If you mean dip (density-independent pixels), perhaps. It depends on
what the pixels represent. There is no hard-and-fast rule.
How do I calculate what dpi they should be?
1px = 1dip at 160dpi (i.e., traditional normal screen density).
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://twitter.com/commonsguy
_Android Programming Tutorials_ Version 1.0 Available!
--
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: screen compatibility not quite right
I just put harcoded fake values for time being, instead of centering.
I was expecting everything embedded with the linearlayout which is my
main layout to be shrunk by the top and bottom margins I specified.
On Nov 22, 1:25 pm, rukiman ruksh...@optushome.com.au wrote:
I thought I'd create my own specialized LinearLayout so that I can
calculate the aspect ratio and center vertically. My game is only
designed to be played in portrait mode. However this code doesn't seem
to work. Spot what I am doing wrong?
import android.content.Context;
import android.util.AttributeSet;
import android.view.ViewGroup;
import android.widget.LinearLayout;
public class SpecialLinearLayout extends LinearLayout {
private final Context context;
public SpecialLinearLayout(Context context, AttributeSet attrs) {
super(context, attrs);
this.context = context;
}
protected void onLayout(boolean changed, int l, int t, int r, int
b) {
int width = r - l;
int height = b - t;
float aspect = 480.0f / 320.0f;
int newheight = (int) Math.floor((float) width * (float)
aspect);
if(newheight != height) {
// create top margins to center vertically
ViewGroup.MarginLayoutParams margin = new
ViewGroup.MarginLayoutParams(this.getLayoutParams());
margin.setMargins(0, 40, 0, 50);
this.setLayoutParams(new LinearLayout.LayoutParams
(margin));
}
}
}
On Nov 22, 11:26 am, Mark Murphy mmur...@commonsware.com wrote:
rukiman wrote:
This is working almost 90% for my game except when testing in WVGA
screen resolution, all my images are scaled incorrectly, it is longer
vertically than horizontally. I was expecting the screen compatibility
to maintain aspect ratios as that of HVGA.
No.
DROID has been optimized to display wide-screen multimedia (movie)
content at its native aspect ratio of 16/9. This is different from the
HVGA aspect ratio of 3/2, which is the traditional computer screen
format. What this means is that when content is scaled up to full
screen, the horizontal (X*1.5) and vertical (Y*1.77) scaling factors
are different. As a result, when displaying the same bitmap as a full
screen background, round circles can appear as ovals, and squares are
elongated to rectangles.
http://developer.motorola.com/docstools/library/Support_for_Multiple_...
I have no reason to believe this is DROID-specific, but rather is how
Android scales things in WVGA800/WVGA854, when you do not supply your
own pre-scaled resources.
Also in my layout I have a scrollview and it is designed in such a way
that in HVGA when it is not scrolled down, the items are hidden away,
however now in WVGA those things are shown. If the aspect ratio of
HVGA is maintained I won't have this issue.
How can I make sure the aspect ratio is maintained?
You cannot control the aspect ratio, as that is dictated by the physical
parameters of the screen. AFAIK, there is no Android equivalent of
letterbox that would put black bars on either side of your app and
give you a smaller virtual screen with 3/2 aspect ratio.
Also in my layout I am positioning some items using pixel positions.
Should I convert these to dpi?
If you mean dip (density-independent pixels), perhaps. It depends on
what the pixels represent. There is no hard-and-fast rule.
How do I calculate what dpi they should be?
1px = 1dip at 160dpi (i.e., traditional normal screen density).
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://twitter.com/commonsguy
_Android Programming Tutorials_ Version 1.0 Available!
--
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
