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/>
