Mobile screen sizes - another naive question

[Graham Samuel]

Thanks Richard, for that typically useful reply! I have indeed written many a resize handler, but getting back into this stuff I was struck by how messy it can get. Right now I don’t even know if say a field with 12 point type in it has to be changed to a smaller or larger rectangle with smaller or larger type in it, but obviously as soon as I can start doing simulations (I have a totally different problem there!) I can experiment. I do like the idea of sending resizeControl to groups - I have used similar techniques for other purposes in the past. Powerful and encapsulated.

As to graphics, I can presumably start with the highest possible resolution and resize at startup according to the actual screen size, or do what I said before, have a little library of different versions tweaked for different screen sizes. Or possibly use SVG, but I have not yet made that work - I know almost nothing about SVG, although I have seen some sexy examples that look almost like photos etc. Wouldn’t work for say a Google Maps image though - again I need to see what happens if the grid of pixels available to display a map varies by a factor of say three.

Well, I am trying to learn, and I am grateful for all that you’ve said.

Graham

> On 9 Apr 2020, at 18:47, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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
> 
> 
> _______________________________________________
> 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