Graham Samuel wrote:
> 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.
If it seems messy you may just be thinking about it too hard. :)
Geometry not longer differs as much between the IDE and the device as it
used to.
In the first versions of LC's mobile offering, we didn't have resolution
independence. Heck, in the fist versions we didn't even have a
pixelDensity function. Back then, fullScreenMode was offered as a
quicky workaround because while it rarely produces apps that look
exactly like the ones we most commonly use, it was easy to implement and
easy to use. The alternative involved a lot of guesswork and tedious
arithmetic to try to figure out the difference between logical and
physical pixels. Ugh.
Today, LC only uses logical pixels, and it automatically translates
those to whatever physical pixels a given phone may be using.
Want to place a button 20 pixels from the bottom-right of the screen?
Just use the syntax you've been using for years:
on resizeStack x,y
set the bottomRight of btn 1 to x-20, y-20
end resizeStack
One nice thing about this approach is that you spend a LOT less time
needing to move the stack to the device just to see what it'll look
like. Just resize the stack in the IDE and look at it. :)
> I do like the idea of sending resizeControl to groups - I have used
> similar techniques for other purposes in the past. Powerful and
> encapsulated.
It's one of the most useful enhancements added to LiveCode, making so
much about delivering pixel-perfect UIs on every platform so much easier.
> 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...
No matter which method you use for your layout, LC includes options for
including referenced images of different resolutions. IIRC the manual
covers that pretty well.
But if you can use SVG for the images you want you'll never need to
think about multiple copies at all, and will always have a rendering
optimized for the device you're running on.
> Well, I am trying to learn, and I am grateful for all that you’ve
> said.
They key to that long post is this line:
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.
I haven't seen your app so I can't say with complete confidence whether
explicit placement via resizeStack or automated approximation with
fullScreenMode is the best fit for your particular needs.
Consider what your app needs to do, and study the apps on your phone
that best reflect your design goals. Rotate the device, run the apps on
your phone and your tablet, observe how the apps adapt their layouts to
make the best use of each screen size.
As we've been doing on the desktop all these years, we can often get
results every bit as good as apps made with anything else, and usually
more easily.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
