supporting multiple mobile device resolutions

Tue Feb 14 12:28:07 EST 2012

I think you have touched on why a single card/custom geometry solution can be inadequate at a certain point. I had suggested (although I do not myself know how to do it) that conceptually you could have an app that detects what the resolution is, loads a card/stack (or set of them) from an internet source that matches that resolution and is fine tuned for it, and then goes from there. 

Bob

On Feb 14, 2012, at 9:03 AM, Ralph DiMola wrote:

> Chris,
> 
> My routine operates using an edge based solution to create bounding boxes
> for control(s). Edges are either control boundaries or the edge of the
> screen. Seeing that these are all relative regardless of the screen size.
> Different screen sizes may make a card layout look odd. Buttons that are
> small on an iPhone or Android may look too large on a tablet. But placement
> and size of controls are correct. All screens and controls have edges. This
> is the reason my solution is generic and will work on any screen size,
> aspect ratio(within reason) and orientation. I assume only 2 dimensions. I
> took a 3d solution I used in the 80's and flattened it to 2d. This also
> allows a desktop app to be resized dynamically. I was only worried about
> mobile but this work great for desktop apps also.  The calls just define the
> boxes. Then a little math gets the control(s) nicely place in a bounding
> box. I hope this description helps.
> 
> 
> 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: Monday, February 13, 2012 4:10 PM
> To: How to use LiveCode
> Subject: Re: supporting multiple mobile device resolutions
> 
> 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
> 
> 
> _______________________________________________
> 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