Corona, when using “letterbox”, allows you to create a virtual screen that your app will use. Nothing pixel related really matters. If you decide your app works best if you set the width to 100, then Corona will figure out the device pixels for you and handle the math behind the scene to convert your desired 100 content units to device pixels. You, the developer only have to worry about your content units.
Now every mobile device screen (and computer screen for that part) has a height and width. Rarely will that device be the same physical pixels high as it is wide. The difference between a screen’s width and it’s height is known as “Aspect Ratio”. Because of old school devices like the original iPhone, developers got used to a screen that 1.5x pixels taller than it was wide (i.e. 320 x 480, the size of the original iPhone). Apple then came out with the iPhone 4 at 640x960, This was still a 1.5x aspect ratio device (960/640) but it had twice the pixels in both direction. The Corona config.lua of a width of 320x480 still fit that device perfectly because Corona would manage scaling things up by 2X to fit.
But devices didn’t stay at 1.5x to 1 (height to width). The iPad’s are 4:3 (aspect ratios are typically expressed as height:width or width:height – almost always a landscape representation). HDTV is 16:9 (which is common now for many phones). It’s now impossible to make a config.lua that will let you define the width and height in a way that your virtual screen is a perfect fit to the shape of the screen.
Because of this, there are two schools of thought. 1. Just give up and use a 1.5:1 (3:2) aspect ratio for config.lua and use techniques to get the actual screen size and manage positioning that virtual screen on the physical screen or 2. Compute the actual height of the screen based on a desired width. This is what the Ultimate config.lua does for you.
“So great, I’ll go #2, my virtual screen will fit the actual screen”. Well not so fast. For some apps, this makes sense, for many others it’s a horrible idea. For a game like Angry Birds, it’s critical that the distance from the sling shot to the pig’s tower be a fixed distance. On the other hand a card game like solitaire you might be happier spreading your card stacks out to fill the screen. Business apps may not work as well with a centered content area. It might make more sense to anchor your content area to the top of the device. No one config.lua can fit everyone’s needs.
Many of the problems with this whole setup comes down to two things. 1. People want to use display.contentHeight/.contentWidth to figure out the screen size. They don’t understand, these two values are exactly the values you put in config.lua. So if you set width = 100 display.contentWidth will be 100, period. If you use the Ultimate config.lua, those values get calculated a bit and will vary. However Corona already provides you with the numbers you really want with display.actualContentWidth, display.actualContentHeight. These values use your defined width, and return you the actual height. 2. People don’t understand that your defined content area is frequently smaller than the actual screen and there are areas outside the content area that you have to do extra work to fill.
By default, Corona will center that virtual content area in the center of the screen. So on an iPhone 4 with a 320x480 content area, it’s a perfect fit. On an iPhone 5, which has a virtual screen size of 320x568 with the same config.lua has to place those extra 88 content units some where. With a centered content area, 44 points will be above the content area and 44 will be below it. That means that the top left corner on a portrait Corona app on an iPhone 5 will be 0, -44. You end up having to place edge based items like navigation bars using the constants display.screenOriginX and display.screenOriginY. Those will return where the screen starts.
As a business app, you don’t really want this. You want 0, 0 to be the top left. The Ultimate config.lua makes this happen. But you could also change the yAlign value in your config.lua “top” instead of “center” (and xAlign = “left”). So if you did this and used display.actualContentHeight to reference the bottom of the screen, you would be golden. “Oh that’s perfect, lets do that”. Not so fast, it has it’s drawbacks too. If you want to center items, display.contentCenterX, display.contentCenterY may now longer be the actual center of the screen (you moved your virtual content area up the screen!) so you have to compute your own center (display.actualContentHeight / 2).
Now to add a lot of fun to this problem, the poster above talked about a scaling option called “adaptive”. This is a pretty cool feature. You no longer have to figure out any of this. You don’t set a width or height at all. Something really cool happens.
If you take an iPhone app and run it on an iPad, you should get about the same number of rows out of a tableView with each row being visually larger. Text will be larger. A display.newSwitch() will be significantly larger. You are taking a phone screen and scaling it up to a tablet screen without giving the app any extra space. With an adaptive config.lua, on a phone you pretty much get a 320 content unit width on an iPhone 4/5. For an iPhone 6 since it’s a larger screen, you will get a 375 point wide content area and on an iPad, you will get a 768 point wide screen. The virtual area will adapt better to larger screen sizes. If you put a iPhone 4, 6, 8plus and iPad on the same table, that switch will be the exact same size on each of them. Your tableView rows will be the exact same height, the fonts will be the same size. You just get more real estate with bigger screens. This is a great option for business apps.
The config.lua gets simplified to this:
application = { content = { scale = "adaptive", fps = 60, imageSuffix = { ["@2x"] = 2, ["@3x"] = 3, } } }
You might want to give this a try and look at different devices.
Rob
