SDK 4.0 dynamic code loading

[gaperton]

That is indeed the most amazing feature of the SDK 4.0. There are some pitfalls, though.

- UI event handlers are being unsubscribed automatically, but not sensor or clock events. There's seems to be no way to unregister sensor events on view close in sdk-multi-view example.
- It seems that all dynamically loaded views load their own copy of the shared module due to the fact that there's no module cache. This is, in fact, looks like a huge problem defeating the purpose of the dynamic code loading. And it looks like views can't share the state in the sdk-multi-view example, which is sorta an immediate problem.
- There's a duplication of "back" button logic in the example and no way to pass view parameters. While that could work in a simple apps, there's no way to open a proper subview (say, a screen showing the details for the selected item).

I took an sdk-multi-view example and made some touches to address these issues (basically, rewrote everything):

- views now can have a clean-up function.
- the global context object is passed around so all views can access it and have a shared state.
- It supports the proper view stack with an automatic "back" button and a possibility to pass view options.

https://github.com/gaperton/sdk-multi-view

@JonFitbit, I thought it would be sad if everyone will have to figure it out over and over, so made a PR to sdk-multi-view, take a look if you don't mind.

[gaperton]

Yes, using the occasion, would you mind to fix the disappeared gradientRect in Versa 2, please? Half of the watch faces are not working, including mine.

[LiamFitbit]

UI event handlers are cleaned up because the thing they reference no longer exists. You might want to keep a sensor/clock object between views, so we don't make any assumptions there.

The lack of a module cache is unusual, but if we did have one, it'd negate the memory savings that are to be had from using this feature.

PR looks great, by the way!

[gaperton]

> The lack of a module cache is unusual, but if we did have one, it'd negate the memory savings that are to be had from using this feature.

You mean, with cache it’s harder to unload shared modules properly on a page switch (and you really do unload them now). Makes sense, actually, as a some sort of compromise.

However, if you import the same module in index.js and any of the dynamically loaded modules it will be loaded twice, doing something which is a directly opposite to the memory saving. Also, it makes it harder to manage the shared global state as you can't just import the singleton from the same module in different dynamically loaded views. So, stateful modules are not supported (you can't use any let-variables in shared modules), and this might have a huge compatibility consequences, it should be written in docs with a BOLD FONT.

Sounds like an acceptable, but really questionable compromise as it's totally counterintuitive and far from the common JS practices.

[gaperton]

> You might want to keep a sensor/clock object between views, so we don't make any assumptions there.

That part of SDK design is totally fine, the issue was with an example app which didn’t allow the opportunity to do that in views, nor it demonstrate how to pass the global state to them. That’s what I fixed in PR.

There was one SDK-related question about module cache, but you explained the reasoning so it’s okay too. 🙂