supporting multiple mobile device resolutions

[Chris Sheffield]

Thanks for all the responses everyone. It sounds like the consensus is to use a single stack with resizing/repositioning code in order to make it compatible with any device/resolution. Not what I want to do, but probably worth it in the long term. Does anyone know if NativeGeometry is compatible with mobile apps? Would that be beneficial in this case?

Ralph, like Jacque I'm also curious about your routine(s) that are generic and app-independent. If you can share a little more info, I'd be very interested.

Thanks again,
Chris



On Feb 12, 2012, at 4:52 PM, Ralph DiMola wrote:

> Chris,
> 
> I was in your boat a few months ago. I thank all the folks for their advice
> back then. I am creating only Android and iOS apps.
> 
> My goal was one card for all resolutions, aspect ratios and both
> orientations. After starting in epub land and making 2 layouts one for each
> orientation, one card was a must.
> 
> Try # 1.... In the resizestack handler (resizeStack
> newWidth,newHeight,oldWidth,oldHeight) in the stack script I looped thru all
> the cards/controls and used the old/new parameters to move/resize every
> object from where it was/size to a new place/size using the old/new
> positions. This actually work well if the size only changed once/twice maybe
> 3 times. I did not investigate but I think that rounding errors started to
> creep in. This was very obvious in the IDE when resizing the card. As I
> dragged the corner and made the card bigger/smaller/different aspect ratios,
> controls started to drift and eventually move off the screen or overlapped
> other controls. Worked for a proof of concept for my customer when I
> disabled orientation changes. SO...... back to the drawing board.
> 
> Try # 2....I created a handler to place and size control(s) based on the
> card size and relative to other controls. The routine is generic and is not
> app or layout specific. Every control moves and resizes as needed. Images
> maintain their aspect ratios. For any given screen size the layout of all
> controls is repeatable. I made the resolution of all image controls large
> enough to handle up to 1024x768 and not have visible jaggies.
> 
> This technique works because I am not doing animation or moving objects (at
> this time). Fine tuning the calls to my routine is a little dodgy, but not
> to bad. I spend 10-20 minutes per card getting it right. But after that,
> it's done. I can then handle any screen size, aspect ratio or orientation.
> 
> In the end I found that the best solution so far was to "Roll my own" and
> "Do the math".
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net
> 
> 
> -----Original Message-----
> From: use-livecode-bounces at lists.runrev.com
> [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Chris Sheffield
> Sent: Friday, February 10, 2012 4:32 PM
> To: How to use LiveCode
> Subject: supporting multiple mobile device resolutions
> 
> I know this topic has come up before. About a year or so ago Tom McGrath
> posted some very useful info. So now that some time has passed, I'm curious
> as to how most of you are developing apps when you need to support multiple
> device resolutions. I've been working on an iPad app. We've all heard the
> rumors, I'm sure, that a new iPad is on the way and will most likely sport a
> fancy new retina display. We (Read Naturally) would like to support the new
> device, but I'm still a little unclear on what all is involved with doing
> so.
> 
> What's the best method? Two separate stacks, one for each resolution? Or a
> single stack with code to handle positioning of controls? 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?
> 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? So if I have an
> image that's 100x100 on a non-retina display, I would need an image that's
> 200x200 for a retina display in order for it to appear the same size? Is
> that correct? Sorry for all the questions. I'm just not sure how to really
> test this out myself. Maybe I need to just fire up the different simulators
> to see how things are affected.
> 
> 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. One advantage I have going for me
> is that this app is portrait only. So no having to deal with rotation in my
> case.
> 
> Any help or suggestions would be most welcome.
> 
> Thanks,
> Chris
> 
> --
> Chris Sheffield
> Read Naturally, Inc.
> www.readnaturally.com
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode