Some thoughts,
I do all scaling manually. First, I write all (non-animated) programming for
600 pixel width and 1024 pixel height, hard-coded. Then I define a variable
screenRatio:
if(mx.core.FlexGlobals.topLevelApplication.aspectRatio == "portrait")
{
screenRatio = (this.width)/600;
}
else
{
screenRatio = (this.width)/1010;
}
Most (non-animated) components are then scaled in the init() function, as in
component.scaleX = screenRatio, and component.scaleY=screenRatio. This
automatically takes care of some fontScaling as well.
I set up an event handler in the init() section:
this.addEventListener(ResizeEvent.RESIZE,shiftTheFrame,false,0,true);
The function shiftTheFrame contains
if(mx.core.FlexGlobals.topLevelApplication.aspectRatio == "portrait")
{
here I adjust component width and height for portrait view
}
else
{
here I adjust component width and height for landscape view
}
This allows the device to be rotated. paddingTop for a TextArea and other
parameters may need to be scaled as well and can be altered in a rotation.
It can be easier to scale something like a button by scaling the label; this
is done with code such as:
helpButton.setStyle("fontSize",new String(26*screenRatio));
Placement of scaled sections is best left to MXML, meaning that the
components are defined using MXML and not dynamically by ActionScript.
Animations work faster in components that are not scaled. I thus place
animations in segments defined by
component.height = this.height
component.width = this.width
or width=100% if defined in MXML.
These various corrections are placed not only in init() but inside
shiftTheFrame as well, so that the component sizes are properly adjusted as
the device is rotated. Sometimes it is easier to develop separate
presentations for portrait and landscape view and then to adjust visibility
in shiftTheFrame (component.visible=false or component.visible=true as
required). Alternatively, components can be removed or added to other
components as necessary (as long as they don't contains html; the coding
will not fully survive a move).
Scaled and unscaled (animated) components are placed into the same page;
that can be a bit tricky because MXML can no longer do this for you. For
instance, one might define one component's position absolutely in relation
to the x- or y-coordinate of some named aspect of another (the tricky part
is that this does not always reflect the scaling). Also, you have to be a
bit cautious with height; give it a bit of leeway because of differing
aspect ratios.
A page with text that needs to be read must have options to alter the font
size - some people like the text larger and others appreciate it smaller. I
do that by placed html in the text such as <font size='25'>. I then do a
global search and replace for this text and replace the number with
something else (eg 32), depending on how the size has been altered. I store
the value in the persistence manager so that it is used and a replacement
automatically made the next time the app is launched. This allows me to
leave a TextArea unscaled; the adjustment for fontSize for various device
screen densities is folded into the initial one-time sizing of the text as a
preference.
I might add that I handle all persistence issues manually view by view and
use persistence only in views or components that require it. Everything in
one view is cleaned up manually before transiting to the next view. This
creates a snappy and highly stable app even with something that finally
becomes rather complex and even in some really old hardware.
I've generated an app (600 English lessons with integrated animated
exercises backed by multiple hours of either on-device or on-demand audio
presenting text with over 3500 new vocabulary words) using these techniques
that scales seamlessly and automatically (same identical apk file) from 480
X 300 all the way up to 2560 X 1600. It's just as fast with scaling as it
would be if there were no scaling (since any sections that require
animations remain unscaled; TextArea segments remain unscaled and thus
continue to scroll smoothly and easily).
Lane.
--------------------------------------------------
From: "Deepak MS" <megharajdee...@gmail.com>
Sent: Monday, February 16, 2015 1:29 PM
To: <users@flex.apache.org>
Subject: runtimeDPIProvider in mx:Application?
Hello,
Just like retina display ipads, off late, there have been laptops with
higher DPIs. And we have some of our flex 3 applications in which all the
components look too small in overall size on screen in new laptops
(something like the screenshots shown here in this link:
https://forums.adobe.com/thread/977263 )
We can achieve it in flex 4 :
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/RuntimeDPIProvider.html
But I want to know if there is anything I can try to achieve it in flex 3
we applications, as it doesn't have "runtimeDPIProvider" property.
Appreciate your help.
Cheers!
