Mobile screen sizes - another naive question

Tue Apr 28 08:06:24 EDT 2020

Richard, thanks for these valuable insights. I am doing my best to absorb them as quick as I can, meanwhile making use of FullScreen mode just to get my app running before it becomes redundant. You are right, it has been very difficult to gather comprehensive info on the topic until now.

Graham

> On 27 Apr 2020, at 22:29, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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:
> 
> https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
> 
> --
> 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
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode