Mobile screen sizes - another naive question
alex at tweedly.net
Mon Apr 27 21:26:52 EDT 2020
On 27/04/2020 21:29, Richard Gaskin via use-livecode wrote:
> 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,
> 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:
Interesting, and as you say, a good start can be made easily. But it has
many built-in assumption that may come back to bite you ....
> on resizeControl -- Allow the user to enjoy whichever orientation --
> they prefer with responsive design: -- put item 1 of the loc of me
> into tMidX put item 2 of the loc of me into tMidY -- if the width of
> this cd < the height of this cd then -- Portrait: set the loc of grp
> "UserInfo" to \ tMidX, tMidY - (the formattedHeight of grp "UserInfo"
> div 2) set the loc of grp "MembershipInfo" to \ tMidX, tMidY + (the
> formattedHeight of grp "MembershipInfo" div 2) else -- Landscape: set
> the loc of grp "UserInfo" to \ tMidX - (the formattedWidth of grp
> "UserInfo" div 2), tMidY set the loc of grp "MembershipInfo" to \
> tMidX + (the formattedWidth of grp "MembershipInfo" div 2), tMidY end
> if -- end resizeControl
In Portrait mode, this assumes that the two groups are the same height
(or nearly so). If they're not, one or other of them will finish up
bumping against the top (or bottom) of the card.
Similarly, in Landscape, it assumes they are same-ish width, otherwise
one of them will stick out the side.
*AND* it assumes they are the same height, otherwise the tops will be
mis-aligned and potentially ugly.
( you could add lines like
put the min(top of grp "MembershipInfo", the top of grp "Userinfo") into
temp if temp < the top of me + 10 then put the top of me + 10 into temp
set the top of grp "MembershipInfo" to temp set the top of grp
"UserInfo" to temp
to the end of the Landscape case).
And there are other assumptions
1. the fields are sized suitable to fit in the width of the narrowest
device. If a narrow device is small enough, maybe the labels should
slide around to above its field, rather than be beside it.
2. assumes that you don't want to widen the fields on not-very-narrow
devices - whether stretching the fields, or increasing spacing between them.
3. In landscape, there may well not be enough width to allow the two
groups side-by-side (say, on a phone), and you would really prefer to
have the stacked vertically, even though in Landscape.
4. (perhaps the hardest) if you have text areas (i.e. multi-line
fields), how do you decide whether to expand vertically depending on the
height of the card, versus simply allowing vertical scroll bars within
In summary - I absolutely agree that LC has everything needed to provide
responsive layouts, and that with even a modicum of effort (which might
seem tedious the first few times :-), it can produce layouts which are
MUCH more responsive than a typical web page/app. But there is a danger
of thinking it is too easy, and producing semi-responsive designs which
are not quite good enough.
Things that would help:
1. either a widget or a compound-control for labelled field which wold
allow the encapsulation for the sizing options for label+field; and
would allow for labelling above or beside the field depending on
context, space available and kind of field.
And there are others -library functions or behaviours that will help
with the common cases - more thought on that tomorrow.
More information about the use-livecode