an Alien screen resolution. best way to survive?

[vangogh]

after reading some threads, in my mind there is a mess

I am writing an app. I really would like to make it run on different devices with different screen resolution and density. (like all of us). the tomorrow alien device will have a screen res of 1234x567x89

I tried using "dip" instead than absolute coords, but I cannot use them in the emulator (that like working using layouts)
sometimes I see the views "adapt" to the device, sometimes not.


So the question is:

If you need to write an app and you don't know (or you don't want to know) the screen resolution/density of the device, and you don't want to define lots of layouts (during time there will be tons of different screen res)...
what is the best way to do?

:sign0163:

 

[nfordbscndrd]

I could be wrong, but I believe that all Android devices use a standard 16:9 aspect ratio, so your 1234x567 fear is unfounded, and if it were to suddenly come about in great numbers (highly unlikely), everyone would be in the same boat of not being ready for it (or any other off-the-wall specs).

That leaves the screen size and dpi to worry about . See
http://www.b4x.com/forum/basic4android-updates-questions/8898-xoom-1280x800-scale-dpi.html#post49532
for information about that.

Also see:
http://www.b4x.com/forum/basic...html#post45287

In theory, you could make one layout for 3.5" devices with a density rating of 1 and another with a density rating of 2 (in landscape and portrait, if needed) and let Android do the resizing for all larger devices, but you'll get a nicer layout by doing a layout for each major size (3.5", 7", 10").

 

[canalrun]

I do something very similar.

I create variants for scale= 1.0 and 1.5 making the button sizes and text input sizes what I want. Then in my Activity_Create, I dynamically (calculate) position and center all the view elements based on the Activity screen size. B4A automatically chooses the scale based on the device, if someone comes along with a weird screen size, my dynamic positioning will handle it.

Sounds like a lot of work, but if you think about it, there really is not much to position and align.

Barry.

 

[nfordbscndrd]

I do something very similar.

I create variants for scale= 1.0 and 1.5 making the button sizes and text input sizes what I want. Then in my Activity_Create, I dynamically (calculate) position and center all the view elements based on the Activity screen size. B4A automatically chooses the scale based on the device, if someone comes along with a weird screen size, my dynamic positioning will handle it.

Sounds like a lot of work, but if you think about it, there really is not much to position and align.

Yeah, I do that as well. Below is the code I use, just to show the kind of thing we are talking about. Like you say, it seems like a lo of trouble, but that's the cost of writing a professional looking app.

 ' Calculate how much of each of the player's 13 cards will fit onscreen: 
i = Activity.Width - LeftMargin * 2 - CardWidth ' last card is shown full
offset = i / 12 
' If offset is not an even number, a gap will be left on the right
' end of the cards, so divide that gap between the left and right:
j = 12 * offset + LeftMargin * 2 + CardWidth
LeftMargin = LeftMargin + (Activity.Width - j) / 2
 
offsetVertical = (Activity.Height - 20 - Cardheight) / 12
 
cardTop = Activity.Height - CardHeight
' DarkLabels are used to dim cards which User is not allowed to play:
DarkLabelLeft.Top = cardTop
DarkLabelRight.Top = cardTop
DarkLabelLeft.Height = CardHeight
DarkLabelRight.Height = CardHeight
 
' The emulator does not include the onscreen system menu of the Archos 70
' which is 40 pixels wide down the right side of the screen in landscape.
' I don't know if other 7" devices have anything like this, but here is
' an adjustment for the A70. This does not have to be done for any Views,
' such as the cards, which are already being positioned based on Activity.Width.
' This leaves most of the non-Option buttons, the score detail labels (except
' for West, where the score detail is already at max left), and the ScorePanel.
If LayoutWidth <> Activity.Width Then
    AdjustLeft = (LayoutWidth - Activity.Width) / 2
    btnOptions.Left = btnOptions.Left - AdjustLeft * 2 ' Get out of the way of East's cards
    btnHelp.Left = btnHelp.Left - AdjustLeft * 2
    btnHint.Left = btnHint.Left - AdjustLeft ' re-center from here down
    btnOkay.Left = btnOkay.Left - AdjustLeft 
    PlayerNums.Left = PlayerNums.Left - AdjustLeft 
    ScorePanel.Left = ScorePanel.Left - AdjustLeft
    LabelDetail0.Left = LabelDetail0.Left - AdjustLeft ' These are the score detail labels
    LabelDetail2.Left = LabelDetail2.Left - AdjustLeft
    LabelDetail3.Left = Activity.Width - CardWidth - LabelDetail3.Width
    LabelDetail1.Left = CardWidth
    OptionsPanel.Left = OptionsPanel.Left - AdjustLeft
    If OptionsPanel.Left < 0 Then OptionsPanel.Left = 0
    ExplainPanel.Left = btnOptions.Left - ExplainPanel.Width
End If

 

[Cableguy]

I could be wrong, but I believe that all Android devices use a standard 16:9 aspect ratio

Actually You are wrong. There are a few 4:3 devices on the market, mostly chaep tablets and a few phones, and I believe Motorola FlipOut is either 4:3 or just Squared !!!!

I guess the best way to aproach this issue is to create layouts or the highest resolution available, and let Android do the scaling down. and of course, determine if the screen is 16:9,4:3 or any other, and have some rules set for these cases, knowing ii wount be the best our app can appear

 

[nfordbscndrd]

...I guess the best way to aproach this issue is to create layouts or the highest resolution available, and let Android do the scaling down...

If someone is writing a simple little app without much on the screen, Android's resizing may work, but the app I'm working on has a lot of Views (about 100) on it which need to be positioned just so to keep from getting in each others' way, and I found that leaving it to Android to do the scaling just didn't work.

 

[vangogh]

If someone is writing a simple little app without much on the screen, Android's resizing may work, but the app I'm working on has a lot of Views (about 100) on it which need to be positioned just so to keep from getting in each others' way, and I found that leaving it to Android to do the scaling just didn't work.

I am in the same situation: I start from a layout, but then I have to move or reposition the views runtime, so the layout approach doesn't work

 

[Highwinder]

I'm taking a totally different approach to all of this.

Since this issue only seems to be getting annoyingly worse as time goes on and new devices hit the shelves, I'm going to go rogue here and offer this:

I'm a software developer for PC, Linux and Mac, and I'm most definitely bringing standard dev practices with me to this Android mess of an issue (which is begging for a solution).

That is, I simply refuse to beat myself up by attempting to support every cheapo non-standard alien screen type that hits the shelves. Unless a major industry standard appears, that will prove to become sheer madness as time goes on.

I, the developer, have decided to make the command decision to decide what screen types my apps will officially be supported on. As such, I am creating proper AVDs, Layouts and Variants for each of the industry-leading quality device screens I choose to support.

Want to run my app? Then run it on a device/screen I support, period. Otherwise you're on your own as far as how it may or may not run on your device.


Easy? Yes.
Does it work? Yes.
Reasonable? Yes.
Do you get to avoid a bunch of resizing and positioning code? Yes.
Do you get to blow off complaints from non-supported device owners? Yes.
Can you release future updates with more Layouts/Variants? Yes.
Do you get to pick & choose the devices you choose to support? YES.
Do you get to reject junk hardware? Yes.
Can customers bribe you to add support for their devices? Hell Yes.


Now go forth and do likewise - you owe it to your health and sanity.