12 Replies Latest reply: Apr 27, 2012 6:49 AM by sinious RSS

    Orientation strategy for mobile. Best practice?

    gtr Community Member

      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.

        • 1. Re: Orientation strategy for mobile. Best practice?
          sinious MVP

          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.

          • 2. Re: Orientation strategy for mobile. Best practice?
            gtr Community Member

            Thanks, that makes sense. Only, despite my best Googling, I can't find a clear and concise description on how to get the child to listen to the parent. (I understand how to achieve the opposite) What's the simplest way to do this?

            • 3. Re: Orientation strategy for mobile. Best practice?
              Colin Holgate ACP/MVPs

              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.

              • 4. Re: Orientation strategy for mobile. Best practice?
                sinious MVP

                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.

                • 5. Re: Orientation strategy for mobile. Best practice?
                  gtr Community Member

                  Thanks for the lesson, Colin. Very helpful!

                   

                  My only remaining concern is regarding a momentary performance hit by having all (five) movies rotating their content at once (even though only one is added to the stage at any one time). Would it be better to wait and use a system where the orientation function ("goLandscape" or "goPortrait" in your example) is only called when it's time to load the child to stage?

                   

                  I've noticed some apps seem to occasionally "pause" momentarily on rotation (even on the new iPad), so I suspect everything is happening at once in the background...

                  • 6. Re: Orientation strategy for mobile. Best practice?
                    Colin Holgate ACP/MVPs

                    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.

                    • 7. Re: Orientation strategy for mobile. Best practice?
                      gtr Community Member

                      @sinious

                       

                      Thanks for the custom event tip. Some of the stuff in there is a little over my head right now, but I'll give it a study.

                       

                       

                      @Colin

                       

                      So it sounds like you're saying that it's best not to have child movies change their arrangements while off stage? (rather, they adjust their "arrangement" only when added, or just prior to being added)

                       

                       

                      "You wouldn't normally have listeners active if the object wasn't on the stage at the time,"

                       

                      My app is not a heavy lifter (mostly displaying content via stagewebview rather than a game with lots of sprites and animation) and my layouts are pretty minimalist in design, so I was thinking of doing this just to save some time and primarily make sure everything is in place before the child gets added.


                      • 8. Re: Orientation strategy for mobile. Best practice?
                        sinious MVP

                        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.

                        • 9. Re: Orientation strategy for mobile. Best practice?
                          gtr Community Member

                          No, pretty simple stuff. As you suspect, just repositioning/resizing of maybe a dozen objects or so. Pretty simple app with low memory and CPU requirements (the "heavy lifting" is being done natively through stagewebview)

                           

                          "Those types of things take no more or less CPU to do on or off the stage."

                           

                          My CPU concern is if I have all five of my off-stage movies perform their repositioning functions at the same time. I wonder if that will that noticeably impact performance... I suppose I can just try it and if I don't like the results, I'll try storing a variable like Colin mentioned above to check against before adding the child movie.

                          • 10. Re: Orientation strategy for mobile. Best practice?
                            sinious MVP

                            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.

                            • 11. Re: Orientation strategy for mobile. Best practice?
                              gtr Community Member

                              Okay, thanks for the tips! Much appreciated. I'll see how it goes and report back later on with details for anyone interested.

                              • 12. Re: Orientation strategy for mobile. Best practice?
                                sinious MVP

                                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.