Layout problems: AbsoluteLayout deprecated, how to do it now?

by Arron » Sat, 30 Jan 2010 18:10:19 GMT


Sponsored Links
 Well that's exactly the reason why absoluteLayout was deprecated.  It
works for only one screen size.

I will say use various layouts with sp margins to space out the
buttons correctly.




--



Layout problems: AbsoluteLayout deprecated, how to do it now?

by theSmith » Sun, 31 Jan 2010 03:28:44 GMT


 


You should be able to use a relativelayout or a linearlayout and just
add padding in dip (density independent pixels) to the sides of the
buttons.  For small screen devices you probably want to create a new
layout with smaller buttons so it displays properly.

-theSmith



--


Sponsored Links


Layout problems: AbsoluteLayout deprecated, how to do it now?

by kaasinees » Tue, 02 Feb 2010 02:07:56 GMT


 try making a new view that is centered in the layout than use the
margin attributes like mentioned before to position the buttons inside
that  view.

this way it could work on all screen sizes.




--



Layout problems: AbsoluteLayout deprecated, how to do it now?

by James Wang » Sat, 27 Feb 2010 12:30:43 GMT


 I think you can do anything with Framelayout like absolutelayout.

--



Other Threads

1. core tests coverage report 0%

We ran core tests by the command "/development/testrunner/runtest.py  -
v --coverage core" and got coverage report successfully. But the
reports says all are 0%.
We ran apidemos and got coverage report which looks good.

Below is the console output for core tests:
-------------------------------------------------------------------------------------
No private recovery resources for TARGET_DEVICE dream-open
make:  `/usr/forCurl/android1.6r1' make: `files' 
make:  `/usr/forCurl/android1.6r1' Syncing to device...
about to run adb  sync
syncing /system...
0 files pushed. 377 files skipped.
syncing /data...
0 files pushed. 8 files skipped.

Waiting for device package manager...
about to run adb  wait-for-device
about to run adb  shell pm path android
about to run adb  shell cat init.rc | grep BOOTCLASSPATH | grep
emma.jar
Waiting for instrumentation to be present
about to run adb  shell pm list instrumentation | grep android.core/
android.test.InstrumentationTestRunner
Running in coverage mode, suppressing test output
am instrument -e class 'android.core.CoreTests' -e coverage 'true' -r -
w android.core/android.test.InstrumentationTestRunner
about to run adb  shell am instrument -e class
'android.core.CoreTests' -e coverage 'true' -r -w android.core/
android.test.InstrumentationTestRunner
Failure in android.webkit.CookieTest:testPath:
junit.framework.AssertionFailedError
        at android.webkit.CookieTest.testPath(CookieTest.java:191)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:164)
        at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:151)
        at android.test.InstrumentationTestRunner.onStart
(InstrumentationTestRunner.java:425)
        at android.app.Instrumentation$InstrumentationThread.run
(Instrumentation.java:1520)


Tests run: 312, Failures: 1, Errors: 0
about to run adb  shell ls /data/data/android.core/files/coverage.ec
about to run adb  pull /data/data/android.core/files/coverage.ec /usr/
forCurl/android1.6r1/out/emma/framework/core/core.ec
EMMA: processing input files ...
EMMA: 2 file(s) read and merged in 503 ms
EMMA: writing [html] report to [/usr/forCurl/android1.6r1/out/emma/
framework/core/core.html] ...
Coverage report generated at /usr/forCurl/android1.6r1/out/emma/
framework/core/core.html
----------------------------------------------------------------

So I wonder why core tests's coverage report says 0% and how can I
make the report make sense.

Thanks in advance.

James

-- 

2. Screen density & screen layout size

Hi,

I am having problems getting Android to use the correct resources.

I am trying to have it pick the correct resources across all densitys
and screen layouts & orientations.

So I have created the directory structure as follows


drawable
drawable-large
drawable-large-land
drawable-large-port
drawable-normal-hdpi
drawable-normal-mdpi
drawable-normal-ldpi
drawable-normal-land-hdpi
drawable-normal-land-mdpi
drawable-normal-land-ldpi
drawable-normal-port-hdpi
drawable-normal-port-mdpi
drawable-normal-port-ldpi
drawable-small
drawable-small-land
drawable-small-port

Since large screen layouts are always hi res screens (480x800,480x848)
and small screen layouts are always lowres(240x320,240x400 etc) i did
not include density descriptions in the directory naming.
And likewise since normal can be low,medium of high resolution
screens, I have included all the different density markers.

I am not sure if android likes me naming the directories like this
since when I load up the normal 320x480 screen,
It is selecting Hi-res resources and down-scaling them. I can see
nowhere in documentation that says this is what it will do so im am
quite confussed as this is what it seems like it is doing.

I am using

 <supports-screens
          android:largeScreens="true"
          android:normalScreens="true"
          android:smallScreens="true"
          android:anyDensity="true" />

Yet I am positive it is resizing the resources automatically for me.
Testing with 2.0 emulators.

When using the WVGA emulators, it uses the hdpi resources unscaled,
when using the 320x480 emulator, it is using the hdpi resources down-
scaled.

Any ideas on where I am going wrong?


-- 

3. Delivered: Xl unlimited error

4. HTC Eris update

5. Build Path Errors

6. Error in helloandroid tutorial

7. Video From Youtube in Emulator Android 2.1 Eclipse Gallileo/ Unable to play video