Colin, This is a fantastic overview of the problem! Do you mind if I make these links available to my students? We are studying how to make mobile apps with LiveCode this semester, and the different resolutions are a major issue.
Thanks for this. Regards, Devin On Feb 28, 2013, at 1:56 PM, Colin Holgate wrote: > I know quite a bit about showing content at a size that is different to the > original document size, everything I make in Flash uses that ability, it lets > me make a single file that works for all existing mobile screens. But, it > would be easy for most people to not understand what resolution independence > is, or what the benefits are. > > What it is not: Something that will automatically layout your interface, > using different styled buttons, or different arrangements of controls. If > you're doing an app that needs different layout for portrait and landscape, > or different buttons for small screens compared to large screens, then that's > more like the current geometry manager, plus some code logic. > > What it is: The ability to layout your app with a given aspect ratio, and > then have that layout fill a device screen of the same ratio, even though the > device is a different pixel size. > > For example, if you want to create an app that works for all iPads in > landscape, you could layout the card as a size of 640x480, and that card > would fill the 1024x768 iPad 1 & 2 screens, and the 2048x1536 iPad 3 Retina > screen. > > If you wanted to design for iPhone, but couldn't bare working at 480x320, you > could work at a comfortable 960x640 and have an app that is immediately > correct for iPhone 4 Retina, and would still exactly fill an iPhone 3gs > screen. > > Now, those are the simple cases for resolution independence, there are more > exceptions to the above examples than there are cases that are so convenient. > > Suppose you want, as an obvious case, to support the full width of the iPhone > 5 screen, as well as the iPad screen. You could have 960x720 of content, > which would scale to exactly fill the iPad screen, and you would accept the > fact that empty areas would appear on the iPhone 4 and even more empty space > on the iPhone 5. > > That's not ideal though, so instead you might have extra content that extends > beyond the left and right of the card window. On iPad you would never see > that extra content, but on the other screens you would. > > To achieve that the resolution independence system would need to be able to > place the card centered on the device screen, currently it's always at the > top left of the device screen. > > Another solution to the problem is to allow the wider screen device to cut > into the top and bottom of the card window. In that case you would have > content near the edges that was not vital, and if it didn't appear on the > iPhone 5 screen it wouldn't matter. > > There may also be cases where you want the card to remain at 100 percent > size, but be centered on the screen, whatever size it is. > > Here are some examples of how all that resizing and aligning might look. In > each one you will see some lines. The red lines represent the iPad ratio, the > green lines are iPhone, and the blue liens are iPhone 5. Incidentally, this > all applies to Android too, where the narrowest Android is the same as the > iPad, and the widest is the same as the iPhone 5. Open the links and do > window resizing to simulate different device screens. > > 1. Top left alignment, and no scaling. This is identical to how LiveCode > works currently. You would have to do all layout management with code. Try > resizing the window and you'll see that more content is revealed to the right > and bottom: > > http://xfiles.funnygarbage.com/~colinholgate/rev/topleftnoscale.html > > 2. Centered, no scaling. I can't immediately think of a good usage case for > this one, other than maybe you have a backdrop image that works better when > its centered: > > http://xfiles.funnygarbage.com/~colinholgate/rev/noscale.html > > 3. Show all. In this one the content is resized to fill the window, and in > doing so it makes sure that all of the card window's content is visible, > doing that by revealing extra content area. In this case that extra area is > empty, but it need not be: > > http://xfiles.funnygarbage.com/~colinholgate/rev/showall.html > > 4. No border. Again, the content is scaled to fill the window, but this time > it's at a size that makes sure you don't see any empty areas. The content > will be cropped on either the left and right, or the top and bottom, > depending on how narrow you make the window: > > http://xfiles.funnygarbage.com/~colinholgate/rev/noborder.html > > 5. Exact fit. Here the card window is squished to exactly match the device > screen. I can't think of ANY usage case for this! But, for completeness here > it is: > > http://xfiles.funnygarbage.com/~colinholgate/rev/exactfit.html > > The scale modes I use the most are Show All and No Border. But then I mainly > do graphical scenes, and not control filled utility applications. If you are > doing those sorts of things you could use code to do the general layout for > all aspect ratios, from 4:3 through to 16:9, and then let the Centered No > Scale mode or Top Left No Scale modes take care of the different pixel > dimensions. > > Please let me know if I need to go not more detail! > > > > _______________________________________________ > 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 Devin Asay Office of Digital Humanities Brigham Young University _______________________________________________ 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
