Start a new topic
Solved

Deallocating the ArchitectView properly

Hi everyone,


we are currently trying to make the following scenario work in our iOS app:


First the user opens "FirstView", which contains an ArchitectView that allows for image tracking. When he scans a certain target and taps a button, a "SecondView" is presented which also contains an ArchitectView - this one however allows for Instant Tracking. Upon closing that view the user is sent back to "FirstView" with the active ArchitectView.


We are doing this because we ran into problems switching from image tracking to instant tracking and back inside a running project - the view would just crash. However, we are also running into problems regarding having two WikitudeSDK ArchitectViews allocated:


Since the user is supposed to be able to go back to the FirstView, it needs to stay in memory - this means the ArchitectView also stays in memory, and you know what that means:

----------------- Wikitude SDK DETECTED MULTIPLE SDK ALLOCATIONS -----------------
A second object of type WTArchitectView was created while the previous one was not deallocated.
If this behaviour was not intended (multiple architect views at the same time), The WTArchitectView didn't got a call to dealloc.
There might be a strong reference to a WTArchitectView objects captured in a block, e.g. in a NSNotificationCenter -addObserverForName:object:queue:usingBlock: method call.
To disable this check, simply set the environment variable 'WTSDKDisableDeallocValidation' to YES.
----------------------------------------------------------------------------------

 This error shows up as soon as we open the SecondView. This wouldn't matter, if switching back to the FirstView wouldn't sometimes (randomly) cause a green or black flicker on the view, or cause the view to just be completely black. Sometimes it just crashes, but that's just the mysteries of Wikitude I suppose.

I am trying to deallocate the view and reallocate it when FirstView is exited and returned to - But nothing helps actually deallocate the view. So far I've tried calling stop() on it and then removing it from the hierarchy via:

func deinitializeArchitectView() {
        architectView?.delegate = nil
        architectView?.removeFromSuperview()
        architectView = nil
}

But nothing I try stops the ArchitectView from staying in memory. I'm not using any listener on it that could keep a strong reference to it - I'm majorly confused.

Does anyone know how to properly deinitialize the ArchitectView from my FirstView so it doesn't clash with the one in SecondView and subsequently dies? Do you think the flickers and crashes are actually caused by that problem or could be from a completely different source?


Any suggestion appreciated.

1 Comment

So, answering this myself:

My problem was I was calling `
deinitializeArchitectView()` as is at the wrong point in time. Instead of on `viewWillDisappear()` I was calling it on `viewDidDisappear()`, and the other view I also allocated in `viewWillAppear()` instead of `viewDidAppear()`. That caused them to overlap and fight, causing crashes and visual bugs. In case anyone has the same problem, check your lifecycle timing.

Login or Signup to post a comment