supporting multiple mobile device resolutions

Tue Feb 14 15:52:39 EST 2012

On 14/02/2012 17:57, Ralph DiMola wrote:
> Bob,
>
> I agree.
>
> I use single card solution for my apps because the same controls appear
> regardless of the size/aspect ratio or orientation.
Hmmm . I wonder if that's always the right decision :-)

Would there be cases where some parts of the UI change from "always 
visible" to "visible as a pop-up" if the size/resolution becomes 
sufficiently small ?  (or even become completely hidden, or appear on 
another additional card ?)

Is there not a parallel with web pages, where it's often considered 
desirable to special case the 'mobile' pages to reduce unnecessary clutter ?

-- Alex.

> If I need to rearrange
> controls to better utilize real-estate on a landscape screen or stupidly
> large buttons on tablet screen I change the bounding box portion of the
> call(s) via a switch statement.
>
> 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 Bob Sneidar
> Sent: Tuesday, February 14, 2012 12:28 PM
> To: How to use LiveCode
> Subject: Re: supporting multiple mobile device resolutions
>
> 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
>
> _______________________________________________
> 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
>