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
rdim...@evergreeninfo.net
-----Original Message-----
From: use-livecode-boun...@lists.runrev.com
[mailto:use-livecode-boun...@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
rdim...@evergreeninfo.net
-----Original Message-----
From: use-livecode-boun...@lists.runrev.com
[mailto:use-livecode-boun...@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
rdim...@evergreeninfo.net
-----Original Message-----
From: use-livecode-boun...@lists.runrev.com
[mailto:use-livecode-boun...@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@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@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@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@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
