"Clock error" when closing an app

[Gondwana]

When closing an app (as opposed to a clockface), you may see this: "Clock error... Go to the Fitbit app and try another clock".

First, isolate whether the problem is with the app that's being closed or the clockface that's being started. One way would be to use a simple standard clockface and see if the error recurs when closing the app. If it does, the problem probably lies in the app that's closing rather than the clockface that's starting (ie, the error message is misleading).

The 'Clock error' message can occur when a clockface throws an error/exception and can't be started. It's possible that the same message would be shown if an app throws an error/exception when closing. Attempt to use try...catch to intercept errors in onunload (or elsewhere), so these don't propagate to the operating system. In your catch block, you can log diagnostic info and ideally correct the error condition. (Some exceptions, such as memory errors, can't be caught, so this tactic isn't infallible.)

onunload seems to be implemented differently between sim and device. In the sim, appbit.onunload seems to work; on device, document.onunload seems to work. I'm not sure of this and can't test it, so it would be wise to verify. But don't assume that what works in the sim will work the same on a device.

A risk with using onunload is that the operating system requires apps to close fairly quickly. If an app doesn't, the operating system may kill it and respond as though an unhandled exception were thrown. Therefore, avoid slow operations in onunload, such as writing substantial data to storage. If this is the problem, a safer alternative is to save data as soon as it changes, or periodically.

[Guy_]

Thank you for this interesting post.

One strange issue did materialise, using the

import * as document from "document";

throws up an incompatibility with functions of the form

document.onXXX.

at build time.

using

import document from "document";

seems to build but may be the cause of an issue when leaving?

Don't know if it is also important to end all timers before leaving?

Also there could be an issue if the app uses the clock.ontick [as well as the established clock face]. Requires more testing. May be it has to be stopped as well, if that is possible/necessary.

[Gondwana]

Re the import format change, see Fix Broken Imports. I would have thought that the 'new' syntax would work with all SDK versions, but maybe not.

I think it's good form to clear all timers when unloading — especially those that interact with the UI. My theory is that the OS releases UI objects during the app close process; thereafter, pointers to UI objects (such as those obtained using getElementById) would no longer point to anything valid. As a result, attempts to use such pointers could result in tears. This could occur if a timer listener fires after the UI has been released but before the JS process is stopped.

I don't think there's a problem using clock.ontick in a non-clockface. I've done it. For the same reason as above, it might be wise to stop doing so when unloading, which you can achieve by setting clock.ontick=undefined. This is obviously unnecessary for clockfaces; maybe the OS stops clockface ontick events automatically, but doesn't do so for apps. 🤷‍

[Guy_]

Following the guidance in the "Fix broken imports" is what actually produces the warning error message "illegal reassignment to import 'document' " at build time - though it seems to build and run.

Will also play with stopping the app clock [clock.granularity="off" which enables it to be restarted, if necessary].

Here is the example error when switching back from app to clock - it may well be generated by the clock face.

[Gondwana]

"illegal reassignment to import 'document' " can occur if you've got something like 'document=...' in your code. It might also occur if you're importing it multiple times in ways that rollup can't rationalise. Carefully check all usage of 'document' in all of your .js.

That error message is generated by Fitbit OS and not the clockface. It normally happens when the OS can't start the clockface due to a clockface error or timeout. It's slightly possible that a poor innocent clockface is copping the blame for problems closing the app. That's why I suggested verifying whether the clockface or the app is causing the error.

granularity=off is a good idea. As an aside, you can restart clock.ontick by assigning a listener to it again. In some of my rubbish, I've used different listeners in different situations, which can be done by simply setting clock.ontick to different functions.

[Guy_]

---

@Gondwana wrote:

"illegal reassignment to import 'document' " can occur if you've got something like 'document=...' in your code. It might also occur if you're importing it multiple times in ways that rollup can't rationalise. Carefully check all usage of 'document' in all of your .js.

---

There are no document = or multiple import times.

The warning message is removed simply by changing

import * as document from "document"; to import document from "document";

The strange thing is it will run with the incorrect import [without the warning] or the correct one [with the warning]

The SDK migration says it is necessary to change to the correct one but it doesn't seem necessary, any ideas?

[Guy_]

@Gondwana - your post helped concerning too much happening at switching between clocks and apps but the issue was more to do with the clock not exiting fully and multiple instances, a rather unexpected behaviour which is partly resolvable using group storage.

However the import warning message remains a mystery but isn't having any adverse effect on functioning.

[Gondwana]

Oh! I never thought about the possibility of multiple instances. I've seen that happen with companion code (admittedly rarely).