Skip to main content
A
as4more
Known Participant
January 6, 2011
Question

Buritto/Hero 4.5 (MobileApplication) popView stomping old mxml on existing view

  • January 6, 2011
  • 1 reply
  • 803 views

I noticed when trying to dynamically load a SWFLoader with a new SWF source/load that after waiting for the event load COMPLETED and then calling popView (the suggested methodology), results in the old original mxml stomping the changes of in this case a newly loaded SWF in a SWFLoader.

I'm confused as to how one uses persistance manager or what?

   mainView.addEventListener(FlexEvent.VIEW_ACTIVATE, mainViewActivate);
   mainView.addEventListener(FlexEvent.VIEW_DEACTIVATE, mainViewDeactivate);

I mean once a viwe has been loaded with pushView you shouldn't have it re-wiped with a popView. Is this making sense? It made me think there are major problems with SWFLoader.

Currently I popView before calling load on a SWFLoader or the original mxml stomps over wipping out the updates, when you call popView on completetion of the load call.

This topic has been closed for replies.

1 reply

A
as4moreAuthor
Known Participant
February 10, 2011

Yup this is definately something that should have a don't reload and call createCompleted etc. if you don't want it too. It's a total nightmare programming this way otherwise. Enough to want to turf the navigator stuff for your own, and sight esthetic artistict design as your motivation even subcontiously when really it's the overhead of trouble you wish to avoid.

So the question & thought is....

is there an argument verson of popView like...

navigator.popViewAndRetain(true);

or

naivigator pushViewAndRetain(MyViewClass, passedData, true);

A
Anonymous
February 22, 2011

Not sure if you have solved this problem, but I came across this recently, haven't used it myself:

<s:View destructionPolicy="none"

<s:View destructionPolicy="auto"

none keeps your view alive

Andrew

A
as4moreAuthor
Known Participant
March 1, 2011

Awesome SPSman!

I tried it and it still called my mxml's init() via creationComplete (with events deactivate and activate of course).

Maybe it's a bug still yet than? yes.

I've managed to work around it and it's really very desturbing situation to program for that I don't like as a default policy. [Although I fear I'm still battling with related issues.]

I think in the few adobe mobile examples I've seen (out there) it didn't really matter and therefore makes sense, but it's not my practical user experience. I should be managing that basically by reference?! I always though.

Thanks very much for the help I'm sure this thread will be of help to others one day when that helps in this situation.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices