LiveCode Forums.

I know this topic has been discussed before but, is there any way to develop for the Retina display as well as the regular display without having to make multiple cards/stacks, etc. But still be able to maintain one set of code. Similar to the "Resolution Independence" feature on Game Salad. I have all of my graphics in regular.png & regular@2x.png format.

-Thanks

Bump up. I would like to know as well as I don't know how to get it to display high res on the iPad. Hopefully soon

I use this in one stack for iPad, iPhone3gs, iPod and a Retina Display. When I switch to the iPhone Retina the resolution is doubled and the screen size is larger.

on preOpenStack
if the environment is "mobile" then
iphoneUseDeviceResolution "true" -- For Retina True Display (doesn't work in openStack)
end if
end preOpenStack

So what size stack do you use? Do you just make an iPad sized stack and put in full graphics?

I prefer to use one stack sized 1024 x 1024 and then use a grid for the different sizes and orientations.

For the One Orientation per Card sizes use:
iPod  320 x 480 & 480 x 320  -- No Status Bar
iPod  320 x 460 & 480 x 300  -- Status Bar showing
iPhone3GS  320 x 480 & 480 x 320  -- No Status Bar
iPhone3GS  320 x 460 & 480 x 300  -- Status Bar showing
iPhoneRetina  640 x 960 & 960 x 640  -- No Status Bar
iPhoneRetina  640 x 920 & 960 x 600  -- Status Bar showing
iPad  768 x 1024 & 1024 x 768  -- No Status Bar
iPad  768 x 1004 & 1024 x 748  -- Status Bar showing

For the Two Orientations per Card sizes use:
iPod  480 x 480 -- Has room at bottom and side for when Status Bar is hidden
iPhone3GS  480 x 480 -- Has room at bottom and side for when Status Bar is hidden
iPhoneRetina  960 x 960 -- Has room at bottom and side for when Status Bar is hidden
iPad  1024 x 1024 -- Has room at bottom and side for when Status Bar is hidden

You can find a template stack here that I use. It is a work in progress but has a great grid that I use.

http://lazyriver.on-rev.com/iOS.rev.zip

Info:

This is a preliminary stack that lets the user choose the type of iOS build and then creates a stack for those devices. This stack works best with Method 1 and 2 below and can be useful for creating the number of cards you need for either A, B or C below:

I have tried the first following two approaches for building a single project for deployment on all available iOS devices. The third is much harder for a visual programmer like myself and as such I have not tried it yet. Your experiences and comments are welcome and appreciated.

1.) The first one uses one Stack with multiple cards, one for each device. The stack is sized to the iPad since that is the largest size. For the iPhone3GS/iPhone Retina/iPod the extra space is 'cut off' as it were and seems to work just fine. Then in the preOpenStack use code to determine which device we are launching on and Go to that card. All shared code can be at the stack level and this way seems pretty fast.

2.) The second uses one Main Stack with multiple subStacks, one for each device. This way each subStack can be sized to the right device size. Then in the preOpenStack use code to determine which device we are launching on and Go to that subStack. The shared code is harder to deal with (library) since each device has its own stack code and then the main stack also has its stack code as well. But this way is cleaner and if you start with the iPad and get everything organized and coded then it is easier to duplicate the stack and resize it and change the layout for each other device.

3.) Use one stack with one card for all devices and orientations. This one is the hardest to both code for and layout. But in the end it is only one card and one stack so it is very clean.

Now, with both of the first two approaches there are three alternate ways to handle device rotation-orientation.
A.) The first is by having both orientations available on the same card and via code moving/rearranging the controls to that particular orientation. Having both on the same card requires a lot more coding to handle the layout/rearranging but requires less coding when making changes to the projects functionality - you just have to change the functionality code for controls just once for either orientation.  

B.) The same as (A) above except but we layout controls so that they can are available for both orientations at the same time. This is easier to show than describe. But if the card is large enough to encompass both orientations then when the device rotates from Vertical to Horizontal the bottom is cut off and the area to the right of the Vertical space is now visible during the Horizontal View and when rotating from Horizontal to Vertical the the right side is cut off and the bottom is now visible. This requires duplicating the controls that are cut off on the right so they are also available on the bottom part so that both are always available regardless of orientation but one or the other is not seen. ( I have a very successful app done in xCode this way and this is actually the easiest way of the three to handle orientation if your layout allows for this. i.e. No pictures or fields will be cut off at the bottom or side.) 

C.) Or lastly by having two cards per orientation per device (for either (1) single stacks or (2) multiple substacks - above) where the first card is the vertical orientation and the second card is the horizontal orientation. Using two cards, one for each orientation, for each device allows for laying out both orientations ahead of time (good for fine tuning the UI) and requires much less coding to handle the layout but it does require a lot more code when making a change to the functionality - unless all of the code is handled at the stack level and with behaviors (which is preferable anyway). Then when orientation changes just switch cards to that orientation. This requires the most amount of cards etc. but for visual displaying of controls is the best way.

Wow thanks! If I want to make an app for Retina and non-retina that will only be landscape, can I use only one card?

Absolutely but then you will have to handle the resizing of the elements. Start with the retina size, code everything, make sure it works the way you like and then in a script like this you can intercept the device and load appropriately. NOTE: I use this for either a two card or one card solution: NOTE: This is from the sample stack listed above:

Also, if you use the exact size of a device instead of one size fits all and put things in substacks then you can instead intercept a resizeStack handler like this:

The stack I am currently building actually has three cards per DEVICE.

The first card is the main card that we go to and has all of the Vertical (in my case since I open vertically first) elements coded and ready to go. Tested and happy I then copy the controls to the other two cards.

The second card is an exact dup of the vertical layout. "RetinaV"

The third card is manually rearranged for the horizontal layout. "RetinaH"

Then when a rotation is detected the card code in the first card catches the resizeStack and calls either of these two codes below: The beauty of this is that all coding is done on the first card and the second and third are just for layout sizes and locations" This actually is the easiest so far for complex layouts.

Thanks McGrath! I can't thank you enough! I am only coding for 1 orientation so it should be simple!

Thank you Tom