Extension waited for a message from the native app which has the version using await nextMessage(...)
Native app waiting for commands
Extension could now send a command and wait for a reply and theoretically do that multiple times
Extension keeps waiting for the native app to disconnect
It was implemented this way, because initially there was an idea that we could get the signing certificate and request signing in the same native app instance. For various reasons, we decided it was better to start a new native app instance in such a case.
In the current code base, the background/actions don't support such a case anymore.
There was also a bug with the Edge browser which got a temporary fix in #67, however this should no longer be necessary.
The way the NativeAppService works now
Handshake
Extension opened the connection to the native app
Extension waited for a message from the native app which has the version using await nextMessage(...)
Native app waiting for commands
Extension sends a single command to the native app
Extension waits for a response from the native app, reusing await nextMessage(...)
Extension closes the native app port immediately, without waiting for the native app to close on it's own
The nextMessage now has a throwAfterTimeout: Error argument and the background\actions no longer handle the timeout logic on their own. This way, when the timeout occurs, the nextMessage(...) can run it's cleanup logic.
The way the NativeAppService worked before
await nextMessage(...)
It was implemented this way, because initially there was an idea that we could get the signing certificate and request signing in the same native app instance. For various reasons, we decided it was better to start a new native app instance in such a case.
In the current code base, the
background/actions
don't support such a case anymore.There was also a bug with the Edge browser which got a temporary fix in #67, however this should no longer be necessary.
The way the NativeAppService works now
await nextMessage(...)
await nextMessage(...)
The
nextMessage
now has athrowAfterTimeout: Error
argument and thebackground\actions
no longer handle the timeout logic on their own. This way, when the timeout occurs, thenextMessage(...)
can run it's cleanup logic.