osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-dpi Autoscaling dimensions (android)


Using percentages in the past, circa 2014/15, could noticeably affect layout speed, but devices are so fast anymore that I don't recommend spending the time to do this.

But if you want to, the most efficient place to do your sizing (I like Bill's approach) is to override UIComponent.measure() and add the scaling logic there.

The reason is because creationComplete() isn't fired until the displayList has been measured and rendered so you are sizing everything twice.

But keep in mind that every size change you make to a component's bindable properties (like width/height) in your creationComplete handler causes every component in the display list for that component to re measure and be rendered all over again as you apply the changes, causing a ripple effect. 

Any change you make to a component's bindable property like width/height fires a property change event that has to be handled, and that change will likely fire change events on every component up the display list. Flash/AIR is optimized to prevent property change events from firing up the chain when it calculates sizes from properties set in MXML, or applied in actionscript before measure() is called in the layout sequence.

Just do all your measuring and sizing in the measure() function to be most efficient, but I still believe Flash/AIR is really good at working with percentages and the development speed/efficiency gains of using percentages is totally worth the cost of not having to write a lot of scaling logic, IMHO. :-)

override protected function measure():void {
// size all your components here and then call super.measure() - this is easy to test
// just drop this code into any UIComponent derived component add sizing logic
    super.measure();
}

Erik

On May 23, 2018, at 6:51 PM, bilbosax <waspence41@xxxxxxxxxxx> wrote:

leokan23, I don't know if this will help you, but I will tell you my process
for laying things out.  I do not place and widths, heights, positions, or
paddings in my MXML.  When you use percentages for these settings, AIR has
to do a lot of self-measuring, calculating, and then laying out components
and this can be expensive on mobile devices, especially all of the
self-measuring.

It is a little more laborious, but I lay everything out manually, but for my
rather large app, it has helped performance a lot.  So in the main app in
the Application tag, I listen for the applicationComplete event. When it
fires, I get the width and height of the device I am on using the following.

AppVars.appWidth = stage.stageWidth;
AppVars.appHeight = stage.stageHeight;

AppVars is just a dummy class that I made to hold a bunch of values that can
be shared across all of my components so I just have to measure the
dimensions one time when the app boots up.  After that, in each component
that I create, I listen for the creationComplete event and set all my
widths, heights, positions and paddings manually like this:

<s:BorderContainer xmlns:fx="http://ns.adobe.com/mxml/2009"; 
				   xmlns:s="library://ns.adobe.com/flex/spark" 
				   xmlns:mx="library://ns.adobe.com/flex/mx" 
				   creationPolicy="all" creationComplete="init(event)" visible="false">
	
	<fx:Script>
		<![CDATA[			
						
			import classes.AppVars;
			
			protected function init(event:FlexEvent):void
			{
				button1.width = AppVars.appWidth * .1;
				button1.height = AppVars.appHeight * .025;
				button1.x = AppVars.appWidth * .25;
                               button1.y = AppVars.appHeight * .25;
                       }


This way, the app always looks the same on every device, scales nicely, and
I can count on how it will lay out.  And it does not require all of the
auto-measuring that happens with every component when you lay it out with
percentages.  When i started, this was recommended to me in the past by a
lot of users here and at adobe, and it has worked well for me.

Hope this helps.



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/