LiveCode Forums.

Hi there,
I used LiveCode awhile ago.. so I've to ask: Is it possible now to build an App an LiveCode will resize it automatically but with correct geometry to the different screen-resolutions?

I used a tool in the past called altMobileResize or something like that, this was slow but it works. It would be much better if there would be a faster solution for it

Some ideas?

See the property fullscreenmode: http://livecode.wikia.com/wiki/Fullscreenmode

No, thats not geometrically correct or with borders. Both is not acceptable for professional products. The App have to look great on every device. Not stretched, no borders or something else

Is there no other way?

There have been very long discussions about how to appropriately design and use the fullscreenMode property. It does work. In almost all stacks, showAll is the method that works best (noBorder coming in second) but you need to lay out your stack with the fullscreenMode in mind, and design for it.

The showAll mode basically preserves the aspect ratio (no stretching) and shows as much of the stack as will fit on the screen. If the stack is smaller in any dimension, you will see black bars in those areas. To prevent that, create a stack that is larger than you think you will need for any device you will support, and put all the objects the user needs to see within the rectangle of the smallest screen you will support. On small devices, the user will see only the "active" area. On larger screens, the user will see the active area with the stack's background around the edges instead of the default black bars. Generally you'll want to provide a large image, or set the stack's backcolor to something that blends in with your overall color scheme. That is what they'll see if the content area of the stack is smaller than their display.

The advantage of using fullscreenMode is that on high-density displays, everything will scale appropriately; text gets larger, images are automatically scaled, etc. Mostly all you need to worry about is what to show around the edges on large screens.

It generally works best to create your stack at the smallest size and let the engine scale it up for other devices.

DevBoyLars, there is indeed a challenge with fullScreenMode in one of the criteria you mentioned: "no borders".

I can see using it for very specialized media presentation apps and perhaps some games, but I don't mind working a bit harder to use the full screen real estate on the user's device.

The difficulty with attempting to automate resizing isn't resolution as much as ratio. LC generally abstracts coordinates similarly to CSS, such that specific locations do no necessarily equate to physical screen pixels, in a good way. It varies by screen density, and in the cases I've tested appears well managed.

So while the trickiest aspects of handling multiple resolutions are generally automated, screen ratios are a very different matter. How do we design a single layout that's optimal for 9x16, 10x16, and 3x4? And what do we do when the user turns their device so the ratio becomes 16x9, 16x10, or 4x3?

Developers accustomed to software design on the desktop have already acquired the habit of making very few assumptions about window size. It's rare that windows are of a fixed size, and both resolutions and ratios have been greatly varied for decades.

So we write resizeStack handlers, so we can put things exactly where we want them, regardless what the user does with the window rect (or with mobile, regardless which device or orientation they may be using at the moment).

If we were to try to make a tool to automate that, personally I find my own imagination too limited to conceive of anything very useful. How would it know which objects I want to reposition, and which objects I want to resize? How do I specify that this object should be 80% of the window width, while this other one should always remain 48px, and this one over here is whatever size remains after I adjust the one next to it?

If I had a point-and-click tool to make all those settings, by the time I'm done learning it and click click click click clicking my way through telling it what I want, I'm not sure I'd save much time over the few minutes it takes to just write a resizeStack handler.

Sure, it means coding. But we're programming - what doesn't?

A few minutes coding a resizeStack handler gives complete assurance over the placement of every element in exactly the way you want it. Seems time well spent when you have requirements as specific as the ones you laid out.

Thank you both

What is the difference between a custom resizeStack handler and altMobileResizer (http://www.gadgetplugins.com/altplugins ... esizer.rev)?

If I would write a resizeStack handler, it should get the values of the objects on the card and recalculate the percentage-values to get the right new placement/dimension?

DevBoyLars wrote:What is the difference between a custom resizeStack handler and altMobileResizer (http://www.gadgetplugins.com/altplugins ... esizer.rev)?

I haven't used it myself but Chipp does great work so it's worth trying to see if it'll so what you need. In talking with Chipp about when he first wrote it it seems like a slightly more efficient version of some other point-and-click tools: rather than requiring you to embed a library that figures things about at runtime it writes a resizeStack handler for you. Or at least that's what I recall; that conversation was a while ago.

If I would write a resizeStack handler, it should get the values of the objects on the card and recalculate the percentage-values to get the right new placement/dimension?

These may help:
http://lessons.livecode.com/m/4069/l/28 ... esolutions
http://lessons.livecode.com/m/15262/l/1 ... -densities