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.com>wrote:
>
>
>
>
>
> > "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
http://groups.google.com/group/android-developers?hl=en
