Best approach for app with fixed no scrolling layout that is display dimension ratio proof

Business Apps
#1

what is the best approach to ensure an app will display sufficiently on multiple aspect ratios (limited to portrait).

I have an interface with a number of widgets , buttons and text displays. it was designed so that it all fits on one screen. If i use the top of the screen as the reference point, on some devices it my cut off the bottom or leave too much space , like wise if i use the bottom of the display and work up.

i could also reference center and layout above and below from that point.

or i could do a meet in the middle approach, but end up with overlaps or too much space again.

how do i best attack this? have i missed something fundamental in app/corona UI design?

I figured i could have multiple layouts for the extreme cases: short height, long height. but that is too much work.

or do i need to compromise and move some of the interface to a another screen as secondary inputs, to ensure that it never exceeds the boundaries.

#2

If your content is larger than the smallest screen can accommodate you’re going to have to allow some form of navigation to get to it.

If that’s not a problem and the issue is simply layout you could set the top left to be your 0,0 for all devices (config file) and then use the display.actualContentWidth and display.actualContentHeight to work out where to put everything. The positions of your elements will be worked out by % of screen dimensions.

The great thing about display.actualContentN is that it will always give you the screen dimensions in Corona units for the dynamic device scaling you’ve configured for your app but will adjust it to include, for example, letterbox space if your app is getting letterboxed. i.e.: you always know exactly how much real screen space you’ve got and can place within it - you don’t need to worry about stretching or borders. You can also continue to make use of newImageRect to have images loaded appropriately and not getting silly huge/small values for the real world pixel sizes, etc.

#3

To expand on what I just posted, what I’m saying is that I always use the mid-range iPhone screen size in my config. I then decide where I want my button etc elements. So, a button which should be near the left edge will be maybe

btn.x = display.actualContentWidth\*.02 + btn.width / 2

but near the right edge it would be

btn.x = (display.actualContentWidth - display.actualContentWidth\*.02) + btn.width / 2

With this method, you do always need to make sure that buttons (or whatever) are always placed relative to other elements.

This is fine for me, because I try to write apps where every single element is generated and the only image file I provide is the splash screen. For others it might be a bit of overkill.

If you really want to fit everything in and make full use of the screen, edge to edge, you might want to consider this. Another approach would be clustering interface elements in groups which get placed against the edge you want them near and just make sure they won’t overlap on the smallest device. (I would still use display.actualContentN though.)

#4

There are different strategies you can employ. For instance you could use a grid system where you divide your screen based on display.actualContentHeight and space things based on what row it’s in:

local rowHeight = display.actualContentHeight / 5  – 5 rows

Then if you want button1 to be in row 3:

button1.y = 2 * rowHeight

In this case, row 1 is actually 0. You would probably want to have anchor points for Y as 0 to position them from the top of object. As long as your objects were not bigger than “rowHeight” including a minimum padding, you would be okay. On short devices the objects will be closer together. On taller screens they would be spread out more, but because you’re dividing the extra space out it will look proportional.

I know you said no scrolling, but its super easy to drop things in a scrollView and not worry about it.

You could position objects relative to the center of the screen and just never exceed the minimum height device you plan to support. You will have extra space at the top and bottom with this, but the layout will be consistent from device to device.

Rob

#5

Thanks for the suggestions guys. 

I was using relative positioning using display heights and widths for laying out some of the ui and then some fixed to a group just 

so i could move it around easily.

but if i go for the a relative positioning approach for everything it should be a better solution.

Initially i was worried about the widgets not scaling, and having the UI fit with fixed sized graphics in the background.

but maybe i will just remove the images.

#6

If your content is larger than the smallest screen can accommodate you’re going to have to allow some form of navigation to get to it.

If that’s not a problem and the issue is simply layout you could set the top left to be your 0,0 for all devices (config file) and then use the display.actualContentWidth and display.actualContentHeight to work out where to put everything. The positions of your elements will be worked out by % of screen dimensions.

The great thing about display.actualContentN is that it will always give you the screen dimensions in Corona units for the dynamic device scaling you’ve configured for your app but will adjust it to include, for example, letterbox space if your app is getting letterboxed. i.e.: you always know exactly how much real screen space you’ve got and can place within it - you don’t need to worry about stretching or borders. You can also continue to make use of newImageRect to have images loaded appropriately and not getting silly huge/small values for the real world pixel sizes, etc.

#7

To expand on what I just posted, what I’m saying is that I always use the mid-range iPhone screen size in my config. I then decide where I want my button etc elements. So, a button which should be near the left edge will be maybe

btn.x = display.actualContentWidth\*.02 + btn.width / 2

but near the right edge it would be

btn.x = (display.actualContentWidth - display.actualContentWidth\*.02) + btn.width / 2

With this method, you do always need to make sure that buttons (or whatever) are always placed relative to other elements.

This is fine for me, because I try to write apps where every single element is generated and the only image file I provide is the splash screen. For others it might be a bit of overkill.

If you really want to fit everything in and make full use of the screen, edge to edge, you might want to consider this. Another approach would be clustering interface elements in groups which get placed against the edge you want them near and just make sure they won’t overlap on the smallest device. (I would still use display.actualContentN though.)

#8

There are different strategies you can employ. For instance you could use a grid system where you divide your screen based on display.actualContentHeight and space things based on what row it’s in:

local rowHeight = display.actualContentHeight / 5  – 5 rows

Then if you want button1 to be in row 3:

button1.y = 2 * rowHeight

In this case, row 1 is actually 0. You would probably want to have anchor points for Y as 0 to position them from the top of object. As long as your objects were not bigger than “rowHeight” including a minimum padding, you would be okay. On short devices the objects will be closer together. On taller screens they would be spread out more, but because you’re dividing the extra space out it will look proportional.

I know you said no scrolling, but its super easy to drop things in a scrollView and not worry about it.

You could position objects relative to the center of the screen and just never exceed the minimum height device you plan to support. You will have extra space at the top and bottom with this, but the layout will be consistent from device to device.

Rob

#9

Thanks for the suggestions guys. 

I was using relative positioning using display heights and widths for laying out some of the ui and then some fixed to a group just 

so i could move it around easily.

but if i go for the a relative positioning approach for everything it should be a better solution.

Initially i was worried about the widgets not scaling, and having the UI fit with fixed sized graphics in the background.

but maybe i will just remove the images.