Skip navigation
Currently Being Moderated

Orientation strategy for mobile. Best practice?

Apr 26, 2012 1:43 PM

Hi all.

 

What's the best way to handle orientation changes on a mobile device when you have several child movies loaded in the background?

 

I'm thinking:

 

1. Each child movie have it's own listener for an orientation change. (calls function to adjust graphics as needed so they are ready when the movie is added to stage)

 

or

 

2. One primary listener on the main stage which the child movies respond to.

 

Thoughts? Am I way off-base on this?

 

Thanks!

 

JP

 

PS. Don't think this matters, but just in case, the app is for iOS only.

 
Replies
  • Currently Being Moderated
    Apr 26, 2012 1:50 PM   in reply to gtr

    I dispatch an event from my main and have my children listen and adjust accordingly.

     

    Of course you can always simply use Flex with some simple layout rules and constraints and let Flex do the work for you. Not every complex view is capable of that automation but I tend to stray from making any single view too complex anyhow.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 2:14 PM   in reply to gtr

    It can get complicated it you want to send an event with data attached, so it could be that the simpler approach would be to have two listeners in each child. Something like this, in each child that needs to rearrange things:

     

    stage.addEventListener("go portrait",goportrait);

    stage.addEventListener("go landscape",golandscape);

     

     

    function goportrait(e:Event){

      //do what this child needs when going to portrait

    }

     

    function golandscape(e:Event){

      //do what this child needs when going to landscape

    }

     

     

    Then in the orientation listener on the stage you would do:

     

    dispatchEvent(new Event("goportrait"));

     

    or:

     

    dispatchEvent(new Event("golandscape"));

     

    You'll read in some places about how it's bad practice to use strings like that, and that you should set up constants with the strings in them. But, using strings is quick and easy, and has no drawbacks at runtime.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 2:24 PM   in reply to Colin Holgate

    It's not difficult to make your own event, which you can use custom information in it. I prefer this method.

     

    Here's a full example of a custom event I use all the time called AppEvent:

    package {      import flash.events.Event;            public class AppEvent extends Event      {           public static const APP_EVENT:String = "appevent";           public var params:Object;  // where you stick your custom goodies           public function AppEvent(type:String, params:Object, bubbles:Boolean = false, cancelable:Boolean = false)           {                super(type, bubbles, cancelable);                this.params = params;           }           public override function clone():Event           {                return new AppEvent(type, this.params, bubbles, cancelable);           }           public override function toString():String           {                return formatToString("AppEvent", "params", "type", "bubbles", "cancelable");           }      } }

     

    To dispatch this event with a piece of data, you'd do this:

     

    this.dispatchEvent(new AppEvent(AppEvent.APP_EVENT, {customVarA:"something",customVarB:"something"}));

     

    In that example I sent "customVarA" and "customVarB" both set to the string "something". I'd read it like this:

     

    function someHandler(e:AppEvent):void {      trace("A: " + e.params.customVarA + ", B: " + e.params.customVarB); }

     

    It sends an object through called e.params. You set whatever objects you want inside it.

     

    To add a listener from a child clip just use the .parent property.

     

    e.g.

     

    this.parent.addEventListener(AppEvent.APP_EVENT, someHandler, false, 0, true);

     

    Any time the parent dispatches the event the child will get it, with whatever custom parameters you need.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 2:44 PM   in reply to gtr

    If you study carefully what apps are doing, they are often doing a quick crossfade from one arrangement to another. You could grab the current arrangement as a bitmap, and then lay that on top of the arrangement before you instantly switch the layouts, and then fade out the old layout to reveal the new one.

     

    You wouldn't normally have listeners active if the object wasn't on the stage at the time, but I suppose that if you're adding something to the stage it should arrange itself correctly. In your main orientation function you could store the current state in a variable, and then the child would check that variable as it gets added to the stage, to see what arrangement it should show.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 4:32 PM   in reply to gtr

    Can you explain exactly what you're "doing" when the orientation changes? How are you "transforming" these clips? Adjusting sizes of objects and possibly repositioning things or is there anything else more elaborate? Those types of things take no more or less CPU to do on or off the stage.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 4:56 PM   in reply to gtr

    Many apps take a second to reorient to a new view, even (but to a much lesser extent) native applications. I don't know "how many things" you're doing in these 5 clips but I'm willing to bet you're a lot pickier about a tiny bog than a user of the app will be.

     

    And yes the StageWebView can utilize the GPU but it can use CPU as well.

     

    Being you have to do the resposition/resize anyhow, you should just do it and see how it goes.

     

    Realize also that while AIR is a pretty easy app to make, it is nowhere near the performance of a native app outside the GPU utilizing features. Everything is "boggy" in an AIR app that isn't using a native feature.

     

    On or off the stage, when you perform those calculations it will take up so little difference in CPU it's not worth removing them from stage if you think that removing them from the display list will somehow make the resizing and repositioning faster. You could even take a hit for it, albeit equally small.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 27, 2012 6:49 AM   in reply to gtr

    You're welcome and good luck. iPad1 optimization is what I work the hardest at..  It's amazing how much faster the iPad2 is going from a single A4 to dual A5s.. The display list is what I'd call pretty boggish on iPad1, but that's because it's all cpu.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points