Inspiring

Question

Workers break on iOS Standard and Production Builds

Forum|Forum|7 years ago
May 6, 2018
7 replies
2748 views

All is well when the packaging method is Fast - issue only arrises in a Standard or Production build. This is only happening on iOS - Android (cheap low end model) all is well.

I'm testing on an iPhone X 11.3.1 | AIR 30.0.0.96 | Feathers 3.5.0

With one library and one line of code - a Worker terminates.

For now I've integrated the code from my Worker into the main APP so I can submit to the APP Store - but the performance hit is evident.

ADOBE - issues with workers on iOS that were not present in Air 27 and below.

Air beta

This topic has been closed for replies.

D

danseeker

Participant

I've been trying every possible sample of workers for iOS I can find without any successful results. My last hope was loading one compiled .swf into the iOS app by having two different .fla projects set for publishing to AIR. Tried on AIR 23, 25, 29, 30, 32, nothing.

Until I tried having the worker .fla target to "Flash Player 30", then it started working. Switched back to AIR for Desktop, stopped working.

It looks like when the worker is set to AIR it keeps expecting the network debug to be present and doesn't start, even when the main application has started. Perhaps some flag in the .swf to wait connection?

For my use case it's fine to compile the worker to a Flash Player target, but perhaps there needs to clearer documentation or some runtime warning message when executing debug and having "hang" workers?

perhaps there is a guide on how to integrate the worker to connect to the same debug session?

D

dewsAuthor

Inspiring

There is currently a bug in Tracker (AIR-4198666) which Adobe recognized it in AIR 31 release notes:

Release Notes Flash Player 31 AIR 31

Since AIR 32 Adobe have dropped it - so this thread is a reminder for them to address.

D

dewsAuthor

Inspiring

Refer to Bug AIR-4198666 missing from AIR32 release notes -- Adobe are working on it

D

dewsAuthor

Inspiring

STILL not seeing this in the release notes for AIR 32.

ADOBE!

D

dewsAuthor

Inspiring

Hey now! I'm not seeing this in the 32 release notes. Adobe don't forget about this..

D

der_fuchs

Participating Frequently

I built my test project and the workers are back on iOS

D

der_fuchs

Participating Frequently

Sorry it doesn't work! I was so happy about the new version, so I test the wrong project. Workers still not working on iOS!

D

der_fuchs

Participating Frequently

Now AIR 31 is released and the problem is not solved.

Actual we are not able to update our app in the apple app store.

The problem was reported 8 month ago and it is not fixed until today.

From my view, the worst thing is that ADOBE does not respond to a request in the tracker or a message.

D

dewsAuthor

Inspiring

Understand your frustration - but fair dues - Adobe haven't said they've fixed the issue yet just that they've acknowledged it, so hopefully we'll see a fix in AIR 32.

D

der_fuchs

Participating Frequently

Yes, but will it fix in AIR 32, if yes when AIR 32 will released?

If I had this information, that would be much better.

Just hope and pray ...

RossD20Studios

Known Participant

Hi dews-

I've been working extensively with Backworkers on iOS for my latest game. I saw your post, and thought I'd help as I encountered this issue and have got two possible work arounds for it. The easiest solution is to use your main application SWF as your backworker SWF as follows:

// Use our own SWF bytes to create the worker thread

_worker = WorkerDomain.current.createWorker(loaderInfo.bytes);

The downside is that you cannot run a debug version as workers do not operate in debug SWFs. The other solution involves creating a completely isolated class so the application does not attempt to convert objects.

Full details of solutions and source code available on my Starling forum post here:

https://forum.starling-framework.org/topic/worker-on-ios-air-starling-conflict-this-one-is-way-above-skill-level?replies…

Let me know if this helps or if you have any follow-up questions.

~Ross

D

dewsAuthor

Inspiring

Hi Ross,

This is why I love the AS3 community so much - thank you so much for taking the time to share your experience.

We are actually using a completely independent worker and including quite a few libraries, so the workarounds don't work for us. Our workaround was to simply ignore the worker completely on iOS - fortunately not too much of a performance hit but a performance hit nonetheless.

Looking forward to Adobe figuring this one out.

Once again, thank you so much for being what makes our community so cool

RossD20Studios

Known Participant

Anytime, dews! For me, I was just excited to come across another AIR developer using back workers. My code was using quite a few libraries as well, so, to create a separate SWF was quite a tedious workflow. I had to completely change the package of all the classes shared between the main/worker SWF. This of course requires you to have all the source files, SWCs are going to prevent that since you can't change package path, so I assume that's where you weren't able to implement the workaround. It's definitely a bug specific to iOS, as the Android/Desktop won't try to overlap classes contained in their own thread.

Feel free to reach out if you ever want to chat AS3 dev stuff. It's good medicine to learn how other folks are doing things and share solutions.