Mobile screen sizes - another naive question

Tue Apr 28 08:55:03 EDT 2020

On the MobileDemo stack, there are a couple scripts that would be useful.
https://github.com/bwmilby/mobileDemo/tree/master/mobileDemo_Scripts
stack_MobileDemo_button_id_1024
stack_MobileDemo_card_id_1002

The button script is a behavior applied to 2 groups on the card.  There are
6 buttons that will change how they are laid out depending on the width of
the screen (2 rows for narrow, 1 row for wide).

The card script has the resizeStack handler that positions the 2 groups.
It will adjust the second one based on the first (so if the buttons unwrap,
then it moves up).

This will show an example of handling a couple of the issues brought up.

(I jump through some hoops in other pieces of code trying to handle the
arbitrary change of fullScreenMode which would not be necessary in a real
application since you would normally pick a mode and stick with it.)

Thanks,
Brian

On Tue, Apr 28, 2020 at 8:07 AM Graham Samuel via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
>
> _______________________________________________
> 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
>