supporting multiple mobile device resolutions

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com