Start a new topic

Crash on ArchitectView.onDestroy

Crash on ArchitectView.onDestroy


I found an (ugly) workaround that somewhat solves the issue for me right now (at least it looks as if it does...):

In the AR fragment's onDestroy / onPause callbacks I simply reload the architectview with a more or less blank html file if it's currently loaded with the world.html.
And in onResume / onCreate the real world.html is loaded if that blank thingy is currently loaded.

My idea was:
the problem seems to be that the architectview's onDestroy isn't fully cleaning up everything, so that queued JS calls are being executed later on on an otherwise invalid object.
So I thought, maybe I could somehow "help" the architectview cleaning up beforehand and that was what I came up with.

Looks as if it sort-of works, at least in my situation.
It's certainly nothing I'd place a bet on, but for now, until this gets resolved for real... ;)
 

Hi Daniel,

 

you can send it to *removed for fear of being bombared with support requests directly :)*.

 

Kind regards

Daniel

Hi Daniel,

thanks for your reply.
Yes, I can provide you with the source.
Any mail-adress where I can send the FTP access info to?

Best regards,
Daniel
 

Hi Daniel,

 

would you be comfortable uploading your project somewhere and providing me with the URL? I would have an easier time figuring this out if I were able to build, run and debug your app myself.

 

Kind regards

Daniel

Hi! I have the following situation:

- Android 6.0
- App is fragment based, ARView has its own fragment.
- at the moment I'm using the ClientTracker.
- The ARView "World"-Javascript registers touchstart and touchend events.
- Inside those events the app is notified via the "architectsdk://"-protocol to do certain things, namely:
- to zoom in / out. This is done inside a handler / runnable which again calls a JS function "World.setZoom" (my first attempt was to do this via a JS timer but this variant turned out to be smoother; it makes no difference for the upcoming problem though!).
- World.setZoom doesn't do much more than to set "AR.hardware.camera.zoom" to a valid value.

Everything works fine until it's about time to replace that fragment by another one.
If the zooming is currently in progress and the fragment back-stack gets modified so that ultimately arview.onDestroy gets triggered, the app will crash about half a second later with a

java.lang.RuntimeException: Camera is being used after Camera.release() was called
at android.hardware.Camera.native_getParameters(Native Method)
at android.hardware.Camera.getParameters(Camera.java:2031)
at com.wikitude.architect.CameraPreviewBase.getCameraParameter(ProGuard:169)
at com.wikitude.architect.ArchitectView.setCameraZoomLevel(ProGuard:1374)
at com.wikitude.architect.CallbackHandler.setCameraZoomLevel(ProGuard:335)
at com.wikitude.architect.PlatformBridge.callAsyncImplInternal(Native Method)
at com.wikitude.architect.PlatformBridge.callAsyncImpl(ProGuard:134)
at com.wikitude.architect.PlatformBridge$a.a(ProGuard:66)
at com.wikitude.architect.PlatformBridge$a.run(ProGuard:40)

I trid to add sanity checks all around, but it doesn't help.
Apparently somehow the setZoom function is executed asynchronously by the ARView even if it internally already shut down most of its stuff. And "AR.hardware.camera.zoom" apparently lacks safety checks itself.
Note that I took care that no such JS call is triggered after arview.onDestroy has been issued.

Any idea / hint / whatever how to workaound this issue would be highly appreciated.

Thanks & best regards,
Daniel
Login or Signup to post a comment