On 2/10/12 3:31 PM, Chris Sheffield wrote:
What's the best method? Two separate stacks, one for each resolution? Or a single stack with code to handle positioning of controls?
Definitely a single stack with resizing code. That will automatically adjust to whatever resolution happens to be released in the future, and will also port seamlessly to Android if you ever go that way.
Funny you should ask right now, since it's come up twice in the forums in the last day or two. Someone posted this useful link from the Academy:
<http://www.youtube.com/watch?feature=player_detailpage&v=7gXhcsrNiZ0#t=141s> Elanor explains how to do it.
And speaking of controls, is it necessary to have two sets of everything, one for lower res and one for higher res displays? Or does it work to have one set of higher res controls? Would they display okay on the lower res display? I'm assuming they would display alright, but they would appear larger. Is that correct?
Yes, but if you do the resizing scripts then objects will remain proportional on any screen. What I did was create a single high-res image that accomodated a large resolution, and when they scaled down for smaller screens in the resizeStack script they looked pretty much okay (with some exceptions, but on Android you can't always account for everything. IPads are easier, less variation.) If the screen was large enough that the scaling ratio exceeded 1.0, I capped it to 1.0 to avoid jaggies and just allowed more room between objects rather than making them too large. That was to accomodate images; scaling buttons and other objects works okay.
Also, in the case of images, which this app makes use of extensively, is it necessary to worry about dpi/ppi when sizing them, or does that really matter? Is it okay to just leave all images set at a fairly standard 72 dpi and just make sure the dimensions in pixels are correct?
I'm not sure, but I just left mine at 72 dpi and it seemed to work okay. I had one background pattern that didn't tile correctly until I saved it at 91 dpi.
This particular app consists of several steps (cards) that the user moves through in progression. So having two separate stacks with all the same cards duplicated might not be what we not. On the other hand, I can imagine that trying to write the code to handle hiding/showing controls and repositioning them could get out of hand.
It's work, there's no getting around it, but scripted resizing is really the only way to handle the issue. I spent an inordinate amount of time on the resizing scripts and had to tweak them repeatedly until I got something that worked pretty well on any device. The simulator is a huge help for resize testing. You also have an advantage because you won't have to account for rotation or all the multiple screen resolutions that Android has.
I should probably end with a caveat that I have no idea if what I did is the "right" way, it's just how I ended up doing it. I'm pretty well convinced though that multiple stacks is a bad idea.
-- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
