Open heyhippari opened 4 years ago
We would have one major update with backwards compatibility to allow time for clients to update their global uses, and then drop the hacks. That would let us add a compatibility layer just before an update, and immediately revert it after a release since we use release branches.
I agree, this is a good idea. In the device section, there's missing a function that supplies the current media metadata though (e.g. for a notification).
We should also ask ourselves whether the new API methods should be synchronous or asynchronous. The new Android app uses WebView.addJavascriptInterface
which registers itself as a window object with a collection of synchronous functions. Supporting async calls/callbacks there is possible, but kinda hacky - currently, I have to register the callbacks in a map on the Javascript side, which I can later call from Java with WebView.loadUrl()
.
If it's synchronous it doesn't work with jf desktop at all, best just wrap any call with Promise.resolve()
so it's irrelevant if it's sync or async
Yeah, that'll need JavaScript code though. Should that go into jf-web or jf-android?
So it's quite easy to write a wrapper that web (or Android) could used to call native shell methods an convert anything in to a promise (so catch all errors and pass them to Promise.reject
and pass the result to Promise.resolve
) it's like 10 lines or so
I'm also happy to help with this but only after web is ts because otherwise I'm sure there'll be quite a bunch of issues (and it's a pain to work with).
This issue is to track and discuss a rewrite of NativeShell/AppHost into a system that makes more sense and is well-documented, well-thought-out, and just generally better made.
Here is a preliminary idea of what it could look like, based on a 5min discussion between @dkanada and me.