What is the best approach?

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

user#606
Posts: 217
Joined: Sun Jan 27, 2008 12:25 pm
Location: Alderney, Channel Islands
Contact:

What is the best approach?

Post by user#606 » Mon Feb 12, 2018 8:53 pm

I am starting an application that will run on android devices.
At this time, I have no interest in I phones, although I should plan for that option in terms of screen sizes
I need to allow for pc's and Mac size screens as well.

Should I allow for the smallest phone screen with my layout, or different layouts for phone, tablets and laptops?
All points of view would be carefully considered.

I am aware that the layout can be scaled, though I have not discovered how, yet. Obviously, phones and laptops are beyond scaling.

The app is a city guide, with pics and text.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: What is the best approach?

Post by FourthWorld » Mon Feb 12, 2018 9:46 pm

Mobile devices range from ~4" to ~13". Generically, the planning of content that adjusts itself to fit screens of various sizes is commonly called "responsive design". As with web development, this can be achieved in LC by deciding on size limits, using a resizeStack handler to adjust controls as needed for different categories of devices.

The Material Design Lite framework and many others use width boundaries of 480, 839, and 1024 to differentiate layout decisions. The exact range of layout options that work best for your app will of course depend on the specifics of your app's design.

You needn't worry about retina, super-retina, or other marketing slogans related to different pixel densities, as LiveCode follows OS guidelines for allowing us to work in reasonably consistent logical pixels regardless of the physical dot pitch on any given screen.

In short, the strategies used by the rest of the world for responsive design can also be applied to LC, with the main difference being that rather than defining positioning in CSS with LC we define positioning using absolute coordinates in script.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

user#606
Posts: 217
Joined: Sun Jan 27, 2008 12:25 pm
Location: Alderney, Channel Islands
Contact:

Re: What is the best approach?

Post by user#606 » Tue Feb 13, 2018 11:21 am

Thank you ForthWorld, that is a most helpful answer.
It gives me a clearer direction to plan my app. A bit of lateral thinking is required to resolve the detail.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: What is the best approach?

Post by jacque » Tue Feb 13, 2018 6:00 pm

Automatic scaling can be done by using one of the fullscreenmode options, which I much prefer over manual scripting in a resizestack handler. In fact, fullscreenmode was implemented to help us avoid scripted scaling.

I suggest using a smaller screen dimension for development and using automatic scaling to adjust for larger devices. You can deal with images in two ways. The easier way is to create images of a high resolution and resize them down for the smaller development size (just resize the image in the IDE) so that when they are scaled on larger devices they will still be sharp. The second way is to create images at different resolutions, named according to Android conventions, and LC will choose the most appropriate size automatically. This method can add some size to the app so I usually use the first method.

You don't need to worry about resolution for anything other than images, all native LC controls will scale automatically. If you will be getting your maps from Google then they should be fine without alteration, since they will be at fairly high resolution.

Also, use SVG widgets where possible for icons because they scale very well at any size without any effort on your part.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: What is the best approach?

Post by jacque » Tue Feb 13, 2018 6:09 pm

BTW, however you decide to scale the app, it will work identically on iOS as well if you ever decide to support that platform. And it works on phones and desktop too.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

user#606
Posts: 217
Joined: Sun Jan 27, 2008 12:25 pm
Location: Alderney, Channel Islands
Contact:

Re: What is the best approach?

Post by user#606 » Tue Feb 13, 2018 6:40 pm

Thank you Jacque, I will work on my old Samsung S4 screen size to see how things develop, before making a final decision.
I had planned to explore layout dependent on phone/tablet/laptop, though not in the initial concept stage.
I have only written design software for laptop + screen sizes, so this is a new programming dimension for me. (pun intended)

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: What is the best approach?

Post by FourthWorld » Tue Feb 13, 2018 9:15 pm

LiveCode's fullScreenMode is similar to using the scaling options in CSS to shrink or stretch the layout as a whole. It's certainly easy to use and can be very useful for certain types of apps. But as we see in the web world and in other development tools, there is no single solution for all the types of apps people use.

Read the Dictionary entry for fullScreenMode carefully, and consider the screen shots in this Lesson on using it:
http://lessons.livecode.com/m/15262/l/5 ... ll-devices

Because screens differ in both size and ratio, any automated whole-layout alteration can only result in over- or under-sized controls, distortion, unused space, or some combination thereof. For some apps, esp. games and multimedia, stretching the content and having empty edges is exactly what's best. But not all apps benefit from that. Reviewing what we see with each of the fullScreenMode options illustrated in that tutorial shows us how these play out for each:

empty: Stretches the layout to fill the screen, cropping any portion where the ratio doesn't match. Even if we overlook the cropping (accounted for with other options described below), a normal finger-sized button that looks like users expect on your S4 will become a giant fist-sized blob on a 13" tablet.

exactFit: Keeps everything on screen by stretching content and distorting it to fit the different screen ratio. A circle on one screen, for example, becomes an oval on a screen with a different ratio.

letterBox: Many video player apps like Netflix use this, stretching the content to fill the screen and accounting for differences in ratio by blacking out either the top and bottom or the sides. For games, video, and other multimedia presentations this can be great, but for a productivity app the user may wonder why the controls are now so unusually large, and why the app doesn't make full use of the screen.

noBorder: This is most useful in contexts where the layout has a lot of unused space around the edges. The content is enlarged (again, great for images and videos, confusing for text fields and buttons), and ratios are maintained so it avoids distortion by taking a different approach from letterBox, cropping space outside the screen rather than fitting it and blackening out the other edges.

noScale: Maintains all controls at the same size, centered on the screen with the card enlarged to provide empty space around the controls on larger screens.


Ultimately, whether you enjoy the ease of fullScreenMode or responsive design through scripting will be best determined by the specifics of your app. FullScreenMode is especially useful in layouts where you don't need to make full use of all screen space, but many productivity apps strive to make full use of the user's screen with meaningful content or controls.

Consider this screen shot of Evernote on three different form factors:
Image

There the designers support user expectations of OS-spec text and control size consistently across the different screens, altering the layout to show dynamically-resized elements to make full use of the user's scarce screen real-estate. And given the significant differences between small phones and big tablets, the designers went even further to show an additional content panes on the tablet, an element represented on the phone as a popup.

No fullScreenMode option can do that, but a little scripting can.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: What is the best approach?

Post by jacque » Tue Feb 13, 2018 9:41 pm

Richard and I disagree slightly on this in some respects. I do agree that some scripted placement may be required if the layout needs to change by orientation. Otherwise, fullscreenmode adjusts all font and control sizes correctly and there are easy workarounds for the "blank" edges around the card on devices that do not have the same screen ratios. There is no distortion as long as you choose the correct fullscreenmode, which for mobile is either "showAll" (for portrait orientation) or "noBorder" (for landscape orientation.) It is possible to change these on the fly if you want to support both.

But if you don't mind the tedium of scripting every control on every card, it's true you will get more control that way. For me, the differences aren't worth it. I dropped scripted resizing the minute we had fullscreenmode, and I won't go back. My first Android app required days to script all the resizing and placement for only five cards. FullScreenMode is a one-liner. I've used it in several professional products without issues.

I'd suggest starting with fullScreenMode and see how it looks. If you don't like it, do the scripted thing.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: What is the best approach?

Post by bogs » Tue Feb 13, 2018 9:49 pm

jacque wrote:
Tue Feb 13, 2018 9:41 pm
I dropped scripted resizing the minute we had fullscreenmode, and I won't go back.
<Assuming my best Darth Vader voice from the 80's> Come back to the dark side, Jacque... we miss you! :twisted:
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: What is the best approach?

Post by FourthWorld » Tue Feb 13, 2018 11:30 pm

jacque wrote:
Tue Feb 13, 2018 9:41 pm
Richard and I disagree slightly on this in some respects.
Maybe not much. We both recognize that fullSceenMode is great for some things but not everything.
The biggest difference seems to be just our own respective personal preferences, and even that's likely because we make different types of apps.
...fullscreenmode adjusts all font and control sizes correctly...
Which fullScreenMode option will give us this on a phone:
smallWirefame.png
smallWirefame.png (2.65 KiB) Viewed 7839 times
...and this on a tablet?:
bigWirefame.png
bigWirefame.png (4.42 KiB) Viewed 7839 times
My own experience with it seems more akin to the screen shots provided at the LiveCode Lessons site, in which we can either have controls resized or have lots of empty space, but not both.

But then again their last screen shot there isn't accurate, so maybe there's another option I've not yet found which will both fill the screen and also keep standard control sizes. I'd be happy to be wrong there; if they're able to automate layout intelligence with a one-click property setting I'd be able to use it more and script less.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: What is the best approach?

Post by jacque » Tue Feb 13, 2018 11:48 pm

Your examples fall into my category of "layout changes" so yeah, you'd have to script it. In my experience, the different screen ratios are insignificant enough in general that enlarging the controls doesn't make much difference, it's only a few pixels. That may change with the advent of the new tall-and-skinny phone factors (ick) but so far the appearance on a tablet is pretty much the same as on a phone. Even if a project is targeting phones, I often use my tablet because it's easier to see and work with there.

There will be empty borders around some edges to take into account though. On my tablet the borders amount to maybe a quarter inch or so (portrait) and don't bother me. If you set the backgroundColor of the stack, that's the color the borders will acquire so it just looks like you've provided some white space in the layout which isn't unattractive.

If you want your layout to go all the way to the edges, then yeah, you'll have to script it. The tradeoff isn't worth it for me. I'm in the "it's good enough" club and so far no one's complained.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: What is the best approach?

Post by FourthWorld » Wed Feb 14, 2018 1:45 am

jacque wrote:
Tue Feb 13, 2018 11:48 pm
Your examples fall into my category of "layout changes" so yeah, you'd have to script it. In my experience, the different screen ratios are insignificant enough in general that enlarging the controls doesn't make much difference, it's only a few pixels.
The ratio affects cropping/empty space, but for controls my concern is size. A 4" phone is less than half the size of a 10.1" tablet, so if I make a button sized appropriately for a small phone any scaling of the layout as a whole will make the button scale along with it. If the scaling is more than twice as large, the button would become twice as large.

If I choose the noScale option, that centers the layout without scaling so I get the controls sized normally, but it's then laid out in a phone-sized app in the middle of a large empty tablet screen.

At least that's what I see, and what's reflected in the screen shots at the LC Lessons site. Am I doing it wrong? Is there an option to let fullScreenMode merely reposition some controls but not scale them as it scales other controls?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: What is the best approach?

Post by jacque » Wed Feb 14, 2018 5:27 pm

In that case you're right, you'll have to continue scripting that. Fullscreenmode does scale everything. My test tablet is 7 inches where the difference isn't very noticeable, and none of my client work has targeted large tablets.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

user#606
Posts: 217
Joined: Sun Jan 27, 2008 12:25 pm
Location: Alderney, Channel Islands
Contact:

Re: What is the best approach?

Post by user#606 » Wed Feb 14, 2018 7:03 pm

I have listened to what has been said and for the moment, I will hold them in the back of my mind. No right or wrong answers there.
On thing was clear to me. The actual app and its purpose/content will affect the approach. I had, sort of, thought of this. I expect there will be 3 versions of layout in the end, when everything is working well on the S4 size.
Because this is an 'in the field' type of app, Phones and Tablets are the target devices. The PC/MAC version will have data management added on, so the content will still have to be designed to fit the smaller device. A bit like a screen simulation.
To conclude, all your advice and points of view have been greatly appreciated and will help me shape the project at this early stage.
I will have more posts to write, as I get back up to speed with LC after nearly 5 years away from it. A lot has changed, I can assure you.

teriibi
Posts: 254
Joined: Mon Nov 13, 2017 3:49 pm
Location: Bolivia

Re: What is the best approach?

Post by teriibi » Mon Mar 12, 2018 10:17 pm

Hi,
sharing this that could be usefull to some - not perfect though, see comments below:
https://docs.microsoft.com/en-us/window ... ive-design

Post Reply

Return to “Getting Started with LiveCode - Complete Beginners”