To be clear, I left out the part where I use percentages in all layout constraints. Just be sure your text wraps on small devices and you should be good to go for maximum number of different devices.
I see another discussion about performance between absolute layouts vs. percentages and I chased that rabbit before and found no noticeable improvement since about 2014 when devices were much slower than they are today. The time it takes to layout with percentages is not even worthy of consideration on the vast majority of devices today because they are so fast. And the additional work to use absolute layouts is significant. Use percentages to maximize development velocity and let hardware bear the cost where there are slight inefficiencies. But the custom runtime dpi provider can give you a lot more control over relative layouts based on real device pixel capabilities. Cheers, Erik On May 29, 2018, at 12:01 PM, Erik J. Thomas <e...@linqto.com> wrote: Hey Bill, I've never had to scale anything to work well on all mobile devices except to set applicationDPI property on the application. Flex/Air apps do that really well auto-magically. When you set height and width on containers and images, you are really setting "points" (not device pixels) and the applicationDPI property is used to "scale" the content to look really close on all devices. The only exception we've had to address is when using portrait-only apps designed primarily for phones that can also be installed on tablets. We find that a single applicationDPI setting won't work well on both devices when designed for portrait-only predominately phone application layouts. If of course you provide different layouts for tablets than phones, then this trick isn't going to be helpful. But if you have for example a portrait-only mobile app that is optimized for phone use, and it is run on iPad (you build to allow tablets to install), you will find that layouts will most likely be too small and hard to read. The simple solution we use all the time is to add a custom dpi provider just to up the overall font and image sizes on iPad. It's done like this: In your application, set this property: runtimeDPIProvider="com.linqto.eventcommons.util.CustomRuntimeDPIProvider" And your CustomRuntimeDPIProvider would have content like this: public class CustomRuntimeDPIProvider extends RuntimeDPIProvider { override public function get runtimeDPI():Number { if (!PlatformUtils.isAIRSimulator()) { if (Capabilities.screenResolutionX > 1500) { return DPIClassification.DPI_320; } } return super.runtimeDPI; } } } This just allows you to adjust your applicationDPI at runtime since it's a static property you cannot change at runtime any other way. This particular logic is in most of our AIR mobile apps and it makes portrait-only phone apps look just good on tablets. Hope this helps a little bit. Erik On May 22, 2018, at 7:57 PM, bilbosax <waspenc...@comcast.net <mailto:waspenc...@comcast.net>> wrote: I am about to submit my first AIR apps to the app store this week. Unfortunately, I never got a chance to test my app on an iPad Pro. I have scaled all my fonts for the various screen resolutions, and all my page layouts are calculated based on screen size and resolution, so in theory it should work on an iPad Pro, but I have never had an opportunity to test it. Do you think that it is safe to include iPad Pro on the App Store when I submit my app? Have any of you found any funny issues with delivering on iPad Pro that I should be aware of before I submit? Thanks for any thoughts! -- Sent from: http://apache-flex-users.2333346.n4.nabble.com/ <http://apache-flex-users.2333346.n4.nabble.com/>