Multi-view clockface mounting duplicates of other view

[dbe5007]

I'm developing an watch face with 2 views - a main clockface view and alternate view that sometimes appears. After some testing I've noticed when I move back and forth between the alternate view that its double or triple mounting the alternate, resulting in duplicate or triplicate event execution and file creation/saving. How do I fully and completely unload/unmount this alternate view when returning to the main watch face, but also ensure it is still reachable in the future? Appreciate any help!

[kozm0naut · Accepted solution]

If you are using document.location.assign() to reach your alternate view, be sure to return using the default method (user swipe from left) or using document.history.back() to go back down the stack rather than adding to the stack with another document.location.assign() operation. Alternatively, you may consider using document.history.replace() which will unload the existing views when loading the new view, but does not preserve the stack and so you would need to create your own "back button" or other method of returning to the other view with another document.location.replace() operation.

https://dev.fitbit.com/build/reference/device-api/document/#interface-location

[dbe5007]

Apologies but maybe I didn't explain the issue clearly. Getting the view page itself isn't necessarily an issue. It's the re-running of the associated javascript code that is. I'm using the SDK example here to load the alternate view and accompanying js code in the main clock face, but whenever I navigate using that method it loads a duplicate version of the js code. It's an additive problem - every time I navigate another version is loaded (so 2, 3, 4, 5, and so on). I can see the console logging repeats grow and grow (e.g. a button event is clicked 5 times even though it was really once).

In reference to the items you've listed out, I am using document.history.back() to go back down the stack to the main clock face. I've attempted to use the location assignment and replacement options to navigate to the alternate view, but while they load the view the underlying js code for that view isn't running so it's devoid of functionality.

[Gondwana]

This probably isn't relevant, but I've found that document.history.back() leaves the old view still visible beneath the one to which we've returned (ie, TWO views are rendered). Methinks the old view should not be displayed after we've backed out of it.

I don't think the document API methods are responsible for connecting your code to the new view document. After the new document is loaded, you have to reconnect listeners, etc, yourself.

The memory behaviour you noticed may not be a problem. JS doesn't free memory as soon as it becomes unused or inaccessible; it only does so when it needs to (ie, when it's worried about running out of memory). Keep using your app and see if the memory used suddenly jumps down. If it does, that means the garbage collector has kicked in and freed all the old no-longer-relevant instances of the code (and variables, etc).

[dbe5007]

So I took another read through of the SDK 5.0 changes for multi-view, re-wrote the change in view to only rely on document.location.assign() and document.history.back() & it solved the problem. The logic duplication issue is gone and overall it runs smoother than my previous method. Appreciate the suggestion.