Hi guys.
I’m having an issue with listview in that when I transition it off to the left or right, it moves over the “black vertical bar” area that’s created when scale=letterbox. This looks ugly as the status bar (top) and tab bars (bottom) exist within these “black bars”
Is there a way to prevent this? It’s just a simple text based “business app” - works fine on iphone, but ipad has the black bars.
Hi @dax,
How are you transitioning it off? With your own positional transition, or with a Composer scene change effect? If you’re doing your own transition, you probably need to just check for the width of these letterbox bars and send the object that extra distance so it goes fully off screen on the iPad. Or actually, it would probably be more simple to just send it a further distance on all devices, so it won’t even be necessary to check the letterbox bar width.
Take care,
Brent
thanks
I’m using:
transition.to( tableView, { x = - tableView.contentWidth, time = 400, transition = easing.outExpo }
the table view is scrolling off the side of the screen “through” the black bar area, which it shouldn’t - it should get masked off surely so it doesn’t appear on the black bars at all ?
You could make your background image a little wider on iPad so there aren’t any black bars…
I always make my background 384 x 576 (based on a 320 x 480 setup) so it’s both wide enough for the iPad and tall enough for IP5.
Ah, so I’d have to widen my status bar, tab bar and background for the listview? I’ll try that thanks!
What about using display.pixelWidth instead of 384? (as in 384 x 576)
You could do that but the image will stretch depending on the device, which may or may not look undesirable.
I just have ‘bleed areas’ on backgrounds, status bars etc which I don’t mind being off-screen on iPhone 4 but will show on iPad, iPhone 5, Android etc.
Hi @dax,
The content area is not “masked” around its edges, so with letterbox, things can appear inside the black bars region. Ultimately, you’ll want to eliminate the appearance of these bars entirely by filling them with content… the markets have been known to actually reject apps if they seem to not be designed for “modern devices” and they don’t fill the entire device screen.
Another option is to use the “zoomEven” scale mode, which will always fill the screen but some areas will be pushed off the edge of the screen on some devices, which you’d also need to handle for elements that must be fully visible on the screen.
Brent
So. with a multitude of devices, would I be correct to infer that there’s no “one universal app” these days and that it’s probably best to have, say, one version for ios tablet aspect ratios and another version for ios phones?
Incidentally, Is there a Corona guide on this? I’ve looked but can’t see anything appropriate. I would think it’s an increasingly relevant topic.
Hi @dax,
Actually, in almost every case, your app should gracefully adjust to various aspect ratios, instead of you building two versions. We don’t have a “guide” on this because there are too many options that developers use to accomplish this (and other scale settings like “zoomEven”), not to mention the design thinking varies considerably by developer/app.
When using letterbox scale, I like gathering the width/height of the letterbox bars with the following formula, which I place near the top of my code so it’s accessible throughout:
[lua]
local offsetX = (display.actualContentWidth-display.contentWidth)/2
local offsetY = (display.actualContentHeight-display.contentHeight)/2
[/lua]
With these, I know the width/height of the letterbox bars on any aspect ratio, and I can use these variable to add (or subtract) to the position of display objects that I want to tuck against a screen edge, push off the screen edge, etc. For example, if I want to push a UI bar to the bottom of the screen in a portrait-oriented app, I just add “offsetY” to its Y position. To tuck something up against the left edge in a portrait-oriented app, I subtract “offsetX” from its X position. And so forth… you’ll see how it works when you experiment. 
Hope this helps,
Brent
Hi @dax,
How are you transitioning it off? With your own positional transition, or with a Composer scene change effect? If you’re doing your own transition, you probably need to just check for the width of these letterbox bars and send the object that extra distance so it goes fully off screen on the iPad. Or actually, it would probably be more simple to just send it a further distance on all devices, so it won’t even be necessary to check the letterbox bar width.
Take care,
Brent
thanks
I’m using:
transition.to( tableView, { x = - tableView.contentWidth, time = 400, transition = easing.outExpo }
the table view is scrolling off the side of the screen “through” the black bar area, which it shouldn’t - it should get masked off surely so it doesn’t appear on the black bars at all ?
You could make your background image a little wider on iPad so there aren’t any black bars…
I always make my background 384 x 576 (based on a 320 x 480 setup) so it’s both wide enough for the iPad and tall enough for IP5.
Ah, so I’d have to widen my status bar, tab bar and background for the listview? I’ll try that thanks!
What about using display.pixelWidth instead of 384? (as in 384 x 576)
You could do that but the image will stretch depending on the device, which may or may not look undesirable.
I just have ‘bleed areas’ on backgrounds, status bars etc which I don’t mind being off-screen on iPhone 4 but will show on iPad, iPhone 5, Android etc.
Hi @dax,
The content area is not “masked” around its edges, so with letterbox, things can appear inside the black bars region. Ultimately, you’ll want to eliminate the appearance of these bars entirely by filling them with content… the markets have been known to actually reject apps if they seem to not be designed for “modern devices” and they don’t fill the entire device screen.
Another option is to use the “zoomEven” scale mode, which will always fill the screen but some areas will be pushed off the edge of the screen on some devices, which you’d also need to handle for elements that must be fully visible on the screen.
Brent
So. with a multitude of devices, would I be correct to infer that there’s no “one universal app” these days and that it’s probably best to have, say, one version for ios tablet aspect ratios and another version for ios phones?
Incidentally, Is there a Corona guide on this? I’ve looked but can’t see anything appropriate. I would think it’s an increasingly relevant topic.
Hi @dax,
Actually, in almost every case, your app should gracefully adjust to various aspect ratios, instead of you building two versions. We don’t have a “guide” on this because there are too many options that developers use to accomplish this (and other scale settings like “zoomEven”), not to mention the design thinking varies considerably by developer/app.
When using letterbox scale, I like gathering the width/height of the letterbox bars with the following formula, which I place near the top of my code so it’s accessible throughout:
[lua]
local offsetX = (display.actualContentWidth-display.contentWidth)/2
local offsetY = (display.actualContentHeight-display.contentHeight)/2
[/lua]
With these, I know the width/height of the letterbox bars on any aspect ratio, and I can use these variable to add (or subtract) to the position of display objects that I want to tuck against a screen edge, push off the screen edge, etc. For example, if I want to push a UI bar to the bottom of the screen in a portrait-oriented app, I just add “offsetY” to its Y position. To tuck something up against the left edge in a portrait-oriented app, I subtract “offsetX” from its X position. And so forth… you’ll see how it works when you experiment.
Hope this helps,
Brent