Mobile screen sizes - another naive question

Richard Gaskin ambassador at
Mon Apr 27 16:29:24 EDT 2020

Graham (and Brahmanathaswami may enjoy this too):

I've been itching to write a tutorial on using specific object placement 
("Responsive Design", as the kids call it) to compliment the Lesson 
we've had for years on the other mobile layout option, FullScreenMode.

I had a few minutes over the weekend, and a discussion with a new 
developer prompted me to craft a simple example of how groups can be 
used to handle common design patterns with little code.

This may be fleshed out more fully in the future, but for now at least 
it's more than the zero tutorials we've had on it thus far:

  Richard Gaskin
  Fourth World Systems

-------------- original post from 9 April ---------------------

Graham Samuel wrote:

 > Folks, yet again I don’t know where to look for an answer in the LC
 > documentation.
 > The issue is the enormous variety of screen sizes on smart phones.
 > For example the iPhone XS Max has 1242 pixels width, the iPhone 5 has
 > 640. And there are many many more before we even get to tablets…
 > The question is, how do most of you tackle this, and does LC help?
 > Obviously an object taking up a fixed number of pixels on one phone
 > will look absurdly large or small on another one, or of course may not
 > fit on the screen at all. Not all objects can be vector drawings, and
 > the ones that are still have to be resized according to device
 > Is there anything better than the obvious trick of resizing everything
 > in sight when the app is being initialised, including substituting the
 > more sensitive graphics from a library of appropriate sizes? Seems
 > tedious.

Is it all that tedious?

Computers have had resizable windows since Mac 1.0, and even HyperCard
stacks could be resize after its first version.

True, in the very olden days we all enjoyed the simplicity of knowing we
never had to accommodate any screen size other than 512x342.  Ah, those
were the days! :)

But 640x480 came along not long after, and it caused much concern among
developers. Suddenly we had to become aware of screen metrics, and
rearrange our layouts to make good use of the available space.

Then 1024x768 came along, and then we had THREE(!) screen sizes to
contend with. Oh the humanity! :)

Then by the early 90s we got over it.  Anticipating multiple screen
sizes became the norm, new tools like SuperCard, OMO, and MetaCard came
along offering true resizable windows, and we learned to respond to
notification that the window had resized so we can adjust our interior
contents nicely.

Flash forward to 2010: iPhone comes out, with the presumption that one
size will satisfy all tastes.  That didn't last long.  History doesn't
always repeat itself, but it often rhymes. :)


As with desktop software, I find it instructive to observe how the best
apps on mobile behave, and then - because those establish user
expectations - do what they do.

And what we see is not all that different from how designers handle
resizable windows on the desktop: some objects stay where they are,
those that make sense to enlarge enlarge, those that make sense to
remain adjacent to something next to them remain adjacent to something
next to them, etc.

If you've written resizeStack handlers at any point in the last 28 years
since MC premiered, you've already learned most of what you need to know
to handle a resizeStack message on a mobile device.

The specifics of how this plays out in your layout will of course depend
entirely on your layout.  But I have found a few things that have
greatly simplified my UI work, chiefly:

- Use Groups Smartly

Relatively recently (a few years ago) the engine now sends a
resizeControl message to groups whenever they're resized by any means,
either user interaction with the pointer tool (as had always been the
case) or via script (the new addition).

This allows us to work with our UIs very cleanly, recognizing that an
app is ultimately a set of rows, and that some rows are divided into
blocks.  When we group controls by their location/purpose logically, we
get to take advantage of a wonderfully simplifying cascading effect with
regard to resizing, which allows us to keep control adjustments local to
their containing group.

Imagine a simple message form, where the rows are:

- Icons for navigating to different screens

- Message, which includes three rows:
    - Subject field
    - Body field
    - Send button

With that, our card script need only bother itself with the general
placement of the two main goups:

on resizeStack x,y
     set the rect of grp "Nav" to 0,0,x,40
     set the rect of grp "Message" to 0,40,x,y
end resizeStack

And because the groups will get a resizeControl message when that card
script adjust them, each can contain its own handler to take care of its
interior contents.  This might be the script for the Message group:

on resizeControl
     set the rect of fld "Subject" to the left of me, the top of me, \
       the right of me, the top of me + 40
     set the rect of fld "Body" to the left of me, 40, the right of me, \
       the bottom of me - 60
     set the bottomRight of btn "Send" to x-20, y-10
end resizeControl

Encapsulating resizing within the group not only keeps the logic simple
and tidy, but by using the group bounds as its basis rather than the
card (e.g., "the left of me") the group is maintainable and even
portable - the card script that sets its rect can change at any time,
and the group's resizeControl handler will continue to work well.

There are probably other tips and tricks worth considering, but none
have radically streamlined the process of delivering the UI I want my
user to enjoy as much as using groups as containers for
logically/geometrically related controls.

As you explore these and other ideas in the crafting of your UI, drop
back in here with questions.  There are always many ways to skin cats in
LC, and the diversity of experience on this list can help solve anything.

   Richard Gaskin
   Fourth World Systems

More information about the use-livecode mailing list