Bob, I agree.
I use single card solution for my apps because the same controls appear regardless of the size/aspect ratio or orientation. 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
