04-28-2021 11:50
04-28-2021 11:50
I'm testing an app from fitbit Studio using an Ionic and phone. Intermittently I'm receiving a Terminating app: Unresponsive error message and the app stops. This seems to happen before the app/index.js file is loaded or, as it's being loaded. It also appears to happen more after the first build, if I re-run the app, then it will mostly work. Not sure if this is a timeout issue or what to look for. Any ideas anyone?
Answered! Go to the Best Answer.
04-28-2021 13:43
04-28-2021 13:43
It can mean that the app is taking too long to start running. I think you only get five seconds. If you've got a lot of slow startup code (eg, heaps of getElementById), that can be a problem. Even declaring lots of SVG elements can be a problem, because each one takes time for the system to construct.
Try to streamline your startup code. If desperate, you can experiment with lazy-loading some stuff.
04-28-2021 12:04
04-28-2021 12:04
I also get that regularly using the CLI with SDK4.2.2 and the Ionic:
"App: Terminating app: Unresponsive" and then the companion unloads, but if I then manually launch the app from the watch screen it runs fine and I still get console and debit messages in the terminal.
I also see numerous "App: Error 22 Critical glue error" and "App: Error 22 Failed to read SVGML './resources/index.gui' " when building and running, in this case the app gets stuck in the loading screen so I have to hold down the left and bottom right buttons until the app quits, then build it again, which works most of the time.
I have just ended up getting used to this along with the many other issues which never get fixed.
04-28-2021 12:47
04-28-2021 12:47
I don't think the issue is with fitbit, it's probably something in my code. My guess is I'm not doing something correctly but I just don't know what to look for to fix this issue.
04-28-2021 13:43
04-28-2021 13:43
It can mean that the app is taking too long to start running. I think you only get five seconds. If you've got a lot of slow startup code (eg, heaps of getElementById), that can be a problem. Even declaring lots of SVG elements can be a problem, because each one takes time for the system to construct.
Try to streamline your startup code. If desperate, you can experiment with lazy-loading some stuff.
04-28-2021 13:44
04-28-2021 13:44
Critical Glue Errors can often by solved by giving elements id attributes — even when you never refer to them. Unfortunately, the system doesn't say which element(s) need them.
04-28-2021 15:55
04-28-2021 15:55
I do have a lot of getElementById's, so I will lazy load them, thank you. Is there a way to split the index.gui into multiple files? It seems like 'document' points to index.gui, I'm not sure if it can point to another .gui file. This way I could split up my SVG elements.
thanks
04-28-2021 17:00
04-28-2021 17:00
If your elements are array-like, you could use something like getElementsByClassName(). I fancy that would be faster than many individual getElementById().
You can include other .gui files by importing them in your widgets.gui. However, doing so won't speed things up (and it may slow things down slightly).
If you don't need all of your elements to be visible and accessible simultaneously, you could a use multi-view structure; eg, document.replaceSync().
You may be able to lazy-load without going to the latter extreme.
04-28-2021 22:12
04-28-2021 22:12
Another way to speed up getElementById is not to search the whole of document. If your SVG is nicely structured, you can search within subsections of it. getElementById works on any container element. Same with getElementsByClassName, etc.