dips, pixels and Scale...again

[enonod]

I have been battling with scaling and have seen so many comments regarding the importance of using dips. I do not use designer so...
is it true to say that when I declare in code 100dips for the width of a panel that looks really good on my Scale 2 device, the device has already corrected that by showing it as 200pixels by assuming I (and everybody) codes relative to a Scale 1 device?

In not using Designer, is there therefore anything wrong with finding the number of pixels on the Scale 1 device (where the design looks OK) and creating a multiplication factor to be used for every positioning number used?
I should possibly add that the outer edges of the design are a perfect square. It appears to work on two devices but the Cloud tester cannot be used for coded design and it will not work correctly to use Designer look-a-like panels to do that because dips are used anyway.

Any observations please?

 

[grant1842]

Dip means density independent pixels. They give you a standard way of measuring dimensions, regardless of the screen resolution/density of pixels a device screen has.

For example let's say you have a panel and set its width to 100dip. Now if you log panel.width it will return the "real" number of pixels wide, not 100. It'll have a different value for different device screens.

With that being said, if you want a panel created at runtime to fill the width of the activity, no matter what device it's on, you'll want to set that in the code, instead of trying to multiply some scale factor.

Panel.Width = Activity.Width

 

[enonod]

Thank you for responding. I understand what you say.
My concern is that if I have two devices with the same number of pixels but one is Scale 1 and the other 2 or even 1.5 for example, then surely the design will go off screen with device 2 because the pixels have been doubled when internally converted from dips, whereas if pixels are used with a factor that will not happen.

 

[grant1842]

Could you provide an example of what layout you're wanting? I could help a little more.

 

[enonod]

For example a square grid of squares. So if I have 30 x 30 squares. I have found the pixel count for the width of the device it is on, say 430, and use cellwh= pixels/30 gives the size of one square plus the line; that should work for any number of screens whatever the pixels and will leave a border where it is not exactly divisible. I then centre it.
All other items added fall within that grid and are relatively placed using the size of a single square as a measure or factor, i.e. a label width might be 12*cellwh wide or 3.5 cellwh high.
If I use dips I anticipate the problem I mentioned of going off screen.
So I wanted confirmation that there is not some blushingly obvious oversight.
[EDIT]Also if there are two devices both have different pixel counts but are Scale 1 then presumably no conversion takes place using dips and so on a larger device the display will be smaller. Using a factor overcomes that using pixels... as far as I can see but cannot try.

 

[grant1842]

Is the number of 30x30 squares static or dynamic?

 

[enonod]

Static for ever and ever. Only the size of each varies according to pixels on screen

 

[klaus]

Well, if you want a precise answer you should ask precise questions.
For me the answer to post#1 and to post#5 wouldn't be the same.

The answer to post#1 is : use allways dip values when refering to dimensions.
This way the dimensions of a given view will be almost the same on screens with different densities (dip = density independant pixel).

The answer to post#5 needs some more definition on what you want.
If you want spaces between the squares or not.
Without spaces :
SquareWidth = Floor(100%x / NbSquare)
With spaces :
SquareWidth = Floor((100%x - (NbSquares + 1) * Space) / NbSquare)
SquareWidth is in absolute pixels.
Then you need to take into accout if you have both orientations.
In this case you could replace 100%x by Min(100%x, 100%y)

Best regards.

 

[enonod]

Thank you for commenting klaus. I believe my questions were precise perhaps the explanations were not.

This way the dimensions of a given view will be almost the same on screens with different densities...

I do not actually want 'almost'. The requirement is precise because unmatching gaps look unsightly. You mention 'different densities'. The edit in post 5 poses a question regarding different numbers of pixels with the same density and asks whether the design will go offscreen, which I see as a problem.

The answer to post#1 is : use allways dip values when refering to dimensions.

Yet you 'seem to me' to be referring to pixels as I have. I can see that if buttons are beside a panel there is leeway, but if items are on top of each other their spacing needs to be precise not almost.

SquareWidth is in absolute pixels.

Truthfully I cannot see a flaw in what I have done, which appears to work and hence my questions, on the offchance their is a bomb awaiting.

 

[enonod]

Having spent several days reading every kind of post on the subject of dips, scales and design problems I have an observation to make (for what it may be worth, not from some higher knowledge) which may be obvious to some but not so obvious to others.

Instead of coming up with a beautiful but arbitrary design and layout that pleases you and then trying to overcome the screen size-ratio-density problems as best you can, consider that you have what is commonly called 'perfect knowledge'; when you begin you already know that this problem exists, so design for it.
Make the design require the minimum of adaptation, make it symmetrical, preferably square, and do everything within that square, using the same space repeatedly where possible because not everything may need to be seen all of the time. Make the sizes and relative positions of objects solve the problem for you, not the other way around. Dips are not the answer to everything, sometimes no dips at all is the best solution. Two large squares side by side, each containing relevant parts of the whole, can easily be changed to one above the other when rotated.