Environment
✔ Getting NativeScript components versions information...
✔ Component nativescript has 6.7.8 version and is up to date.
✔ Component @nativescript/core has 6.5.12 version and is up to date.
✔ Component tns-android has 6.5.3 version and is up to date.
✔ Component tns-ios has 6.5.2 version and is up to date.
Describe the bug
When running the app, Android only, we connectivity.startMonitoring() on app resume, and stop monitoring on the other hooks, typically "suspend". Android suspends when the app in minimized, when asking for permissions, when showing a camera or filepicker, etc.
Sometimes, but not all the time, the onAvailable() or onCapabilitiiesChanged() does not have a valid reference inside the connectivty module and it dies. Related to this area of code and here is a stack trace:
JS: Crash Message: Calling js method onCapabilitiesChanged failed
JS: TypeError: notifyCallback is not a function
JS: Stack: onCapabilitiesChanged(file: node_modules/@nativescript/core/connectivity/connectivity.android.js:108:24)
JS: at com.tns.Runtime.callJSMethodNative(Native Method)
JS: at com.tns.Runtime.access$2300(Runtime.java:39)
JS: at com.tns.Runtime$5.run(Runtime.java:1307)
JS: at android.os.Handler.handleCallback(Handler.java:883)
JS: at android.os.Handler.dispatchMessage(Handler.java:100)
JS: at android.os.Looper.loop(Looper.java:241)
JS: at android.app.ActivityThread.main(ActivityThread.java:7604)
JS: at java.lang.reflect.Method.invoke(Native Method)
JS: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
JS: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:941)
To Reproduce
Minimize and Open app repeatedly.
Or sometimes have phone sleep while app is open, and unlocking phone causes the bad timing (like the monitor was stopped but the callback for onCapabilitiesChanges still fired)
Expected behavior
Not crashing. If the callback for startMonitoring fires and there is no notifyCallback (because it was destroyed on stopMonitoring), then fail more gracefully.
Sample project
This project is not a working sample. (Namely I have not made permissions work yet for the camera). But it does replicate the suspend and resume when minimizing and opening the app. But it does not crash! Whatever else our real app is doing on "resume" must cause the bad timing.
https://play.nativescript.org/?template=play-vue&id=vaxKwu&v=3
Additional context
I'd gladly put a "mutex" in my code but that monitoring callback is outside of my control. If the callback is wanting to be fired but I stopped monitoring already, there is no callback and it crashes. I could try a PR if just defensive coding is helpful here
if (notifyCallback) notifyCallback()
but realize there could be more to this connectivity module.
Hi @chimmelb
Thank you for reporting this issue.
We are going to try replicate this case on our end and will confirm. Can you please confirm if you tested this on a real device?
Yes, this was on a moto g(7) Power, Android 10.
It was first noticed most reliably on a clean install of the app, as asking for permissions cycles the app through suspend and resume quickly. For example:
Usually our app would "die" somewhere in that process, so when the camera came back nothing good would happen (if the app died before reaching the camera, when the camera returned the app would restart and we'd be back at the home screen).
It does not happen every time, like with that Playground sample. Whatever else is on our Nativescript activity resuming is just enough to have bad timing interaction with this Connectivity monitoring. stopMonitoring() nulls the notifyCallback(), but the callback for startMonitoring() fires at just the wrong time so it's still processed in our app, but there is no notifyCallback() in Connectivity, so an exception is thrown.
I've got the same problem and tested it on a OnePlus 7T Pro. It happens with clean Dev builds on my device as well. So when I leave the app in the background and reopen the app after a little while, it shows the error shown in the opening post.
Thanks for sharing those use case I’ll push a fix for this
Is this fix merged on NS 7?
@mapo80 yes
Hi @triniwiz , Could You fix this on tns-core-modules for Nativescript 6?
Most helpful comment
Thanks for sharing those use case I’ll push a fix for this