Android Question DIPs, how independent are they really?

SayCheese

Member
Licensed User
Thinking about Device Independent Pixels I thought this must be the best thing since sliced bread. However, when I was playing around with listviews I noticed that a 85dips high layout loaded in a 85dips high listview item didn't fit. Although I thought it was a bit strange, I didn't think of it as a huge problem and just added a few dips extra height.
The problem grew when I installed the program on a few other devices just for testing purposes. The layout loaded in the listview items reflected not the same situation as on the development phone. So the big question is: how device independent are dips really? And even more important: how can I overcome this problem in general? Or am I missing something?
 

Semen Matusovskiy

Well-Known Member
Licensed User
Device Independent Pixels ? Actually, Density Independent Pixels.
160dip = 1 inch. This is true for any device, like 1 inch = 72pt or 25.4 mm.

Views have styles. Even, if you did not specify them. These styles include margins, paddings etc.
Specify Appcompat theme in manifest, add additional place for views according your visual feeling.
I also distribute "own" fonts to be sure that the text will look the same.
 

emexes

Well-Known Member
Licensed User
when I was playing around with listviews I noticed that a 85dips high layout loaded in a 85dips high listview item didn't fit
Note that the coordinate system and the pixel row/column numbering are two different things. For the top-left pixel on the screen, ie row 0 col 0, the edge coordinates of that pixel are:
- top edge: y = 0
- bottom edge: y = 1
- left edge: x = 0
- right edge: x = 1

and so if you specify a rect of (5, 7, 11, 17) which:

(i) if those numbers were pixel addresses, you'd think that the rectangle was x columns 5..11 and y rows 7..17 ie 7 pixels wide and 11 pixels high, but:

(ii) because they are coordinates, it refers to the pixel area: x columns 5..10 and y rows 7..16 ie 6 pixels wide and 10 pixels high.

The best analogy I've come up with is graph paper: the blue lines are the coordinates, and the squares they enclose are the pixels.

Anyway, where I was heading is that the graphics functions usually draw objects (lines, rectangles, circles) with a pen of a specified stroke width (which is fair enough: because a stroke width of zero would imply drawing nothing). This stroke is centered on the specified coordinates, and so if you draw a horizontal line at coordinate y = 5 of width 1, then what it actually does is draw half-a-stroke-width each side of the line, and thus the line is half-a-pixel on pixel row 4 and half-a-pixel on pixel row 5, ie from coordinate y = 4.5 to y = 5.5. The pixels have an alpha (opacity) of 50%, to represent that they are only half-filled. So if your ListView has a border drawn this way, then it will be one stroke-width larger than the .Width and .Height properties. Or, if you clip the ListView to the specified width and height, then the border will be thinner.
 

SayCheese

Member
Licensed User
Thank you all for your reply.

I understand that there are a lot of influences that can disturb the layout. But if the space given to the item and the space needed for the layout are equal then at least it should fit the height. At least that is my thought. Otherwise it will be different on every single device when there is styling involved the developer can't change. That's why I rather do my own styling/coloring/etc although it is a lot more work from a maintenance point of view. If the user chooses to have a bigger font then it will only affect the individual views (again, at least that's my thought).

In this screenshot you can see the top of the last view in the layout is 85dip
In this screenshot the height of the item is set to 85dip
In this screenshot the height of the item is set to 95dip

This wouldn't be a problem if the difference added (10dip) is consistent on all devices which it isnt.

Now I have this few lines of code to overcome this problem, but I am almost sure this isn't the right way to do.

B4X:
Dim ItemHeight As Int
    If lv.ApproximateScreenSize < 4.6 Then 'note 3
        ItemHeight = Alg.IFFI(ckbHideToeslag.Checked, 66dip, 93dip)
    else If lv.ApproximateScreenSize < 4.9 Then 'A2 lite
        ItemHeight = Alg.IFFI(ckbHideToeslag.Checked, 68dip, 95dip)
    else If lv.ApproximateScreenSize < 5.5 Then  'note 7
        ItemHeight = Alg.IFFI(ckbHideToeslag.Checked,71dip, 100dip)
    else If lv.ApproximateScreenSize < 7 Then 'tab 8
        ItemHeight = Alg.IFFI(ckbHideToeslag.Checked,78dip,110dip)
    End If
 
Last edited:

SayCheese

Member
Licensed User
The AutoScaleAll was the cause. Obviously I Didn't fully understand the meaning of this default setting which I also overlooked.
So the views on the layout were scaled but the absolute (dip) height of the item (of course) was unchanged.
I tested 2 devices and they both looked similar now. Thanks.
 
Last edited:
Top