Standard package freezes on iOS

Question

Hi there,i encounter a very strange behaviour of my developed app (using Starling): After installing the final release of Flash Builder 4.7 this weekrelease builds (using Standard packing method) freeze after startup on my iPhone 4 (iOS 5.01 and 6.01).With Flash Builder 4.7 beta2 everything worked fine.The funny thing is that the app works fine on Android devices and even when debugging the release build or using the fast packagingmethod on iOS.For me it seems that the ENTER_FRAME Event doesn't work correctly anymore in that situation. I don't think this is a Starling problembecause i didn't update anything.I'm using the latest AIR 3.5 SDK.Does anyone also have that problem or know what i need to change in Flash Builder or my source code that a release build alsoruns fine on iOS ?Thanks for your help.Regardsvalley

valley t · Accepted Answer

This document may have some information (for Starling perhaps) about the stricter compiler:

http://helpx.adobe.com/flash-builder/actionscript-compiler-backward-compatibility.html

Aside that I did one final test on my workstation (dual quad xeon, 32gb ram, radeon, yada). I'm tired of typing on this issue so here's the synopsis:

Fresh FB4.7 comes with AIR3.4 so it's mandatory to update to 3.5 for the Starling mobile demo test, FYI. So AIR 3.5.0.880

You only care about USB testing so:

Starling Mobile Demo:

- Debug Fast and Standard - Fail

- Release Fast and Standard - Fail

New AS Mobile project without Starling:

- Debug Fast and Standard - Success

- Release Fast and Standard - Success

New AS Mobile project that merely imports any Starling class:

Total Fail

Import old FB4.6 project of exist app with tons of Starling usage:

Total Success

Package traditional, debug over Wifi:

IPA created, installed, never connected via wifi - Fail

FB4.7 packaging is in complete disarray. It makes no sense an old 4.6 project that instantiates Starling works perfectly in all modes (debug/release/export w/ Fast or Standard). Everything else rides the fail boat.

Do all of the above in FB4.6, no problem at all (aside no direct USB install).

I'm done testing this. I can't even make a usable bugbase entry because I can't figure out what the difference is.

To show how volatile Starling is to FB4.7, this fails in debug/fast for me:

package
{
    import flash.display.Sprite;
    import flash.events.Event;

    import starling.events.Event;

    [SWF(frameRate=60,width=768,height=1024)]
    public class OmgDebug extends Sprite
    {

        public function OmgDebug()
        {
            super();

            addEventListener(flash.events.Event.ACTIVATE, onAc);
        }

        protected function onAc(event:flash.events.Event):void
        {
            // trace never happens, app locked because of junk() function
            trace("Activated....");
        }

        // comment or remove this junk() function and app works
        protected function junk(e:starling.events.Event):void
        {
            // CAUSES FAILURE, starling.events.Event is compiled
            // but not even used, WTH?
        }
    }
}

Because I use the starling event in a methods argument the compiler must include the class (it has been declared) and the app is completely locked. Just remove the function (not even the import) and the app works.

Totally ridiculos.

So we both have just reported this issue in Starling forum!

I'm glad that i'm not the only one who has these problems.

Thank you very much for your efforts, sinious, hopefully the creators of Starling

have an idea what is going on here and can fix it soon.

sinious · Answer

The render pipeline is fused together between StageVideo, Stage3D and the standard Display List. I've only encountered a situation where the app freezes when, for instance with starling, if I stop my Starling instance. Because it no longer runs a present() in an ENTER_FRAME loop it actually locks up the entire app.

I'd look around and make absolutely sure you're starting Starling and are keeping it running, sniffing out CONTEXT3D being obtained, etc.

Perhaps try making a brand new project that only starts Starling and see if it also freezes. I actually was trying to diagnose why the profiler reported objects not being removed from memory (AGAL mostly). I thought it was Starling and made a FB4.6 test project that only starts and stops Starling you could use to test.

Here's the thread, check the 2nd post for code and/or a full project (although I wait for starling.events.Event.ROOT_CREATED rather than CONTEXT3D):

http://forum.starling-framework.org/topic/starling-is-sticking-around-in-ram-general-tips-on-what-to-look-for

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.