Mobile screen sizes - another naive question

[Richard Gaskin]

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
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com