In mobile we are proactively stopping the node when we are going into the background or when we are in the background and finished with our work.
This may be too heavy handed.
Option 1. Mobile-only test
I thought we could test this by just commenting out the stop call from mobile. The problem is that if we do this, we'll miss out on all the cleanup tasks the node does in preparation of being destroyed.
Option 2. Prepare to stop API
Another option would be to create a second API in the node, prepareToStop that would take that event and do all the shutdown tasks but not shut down.
When in this state,
we could then just let the OS destroy the node however it likes.
if the client attempts to call the node, it could fail just like it is stopped
if the client comes back to the foreground, it could call 'start' as it does today, and if the node was in the 'prepared to stop' state, it would start-up instantly.
In mobile we are proactively stopping the node when we are going into the background or when we are in the background and finished with our work.
This may be too heavy handed.
Option 1. Mobile-only test
I thought we could test this by just commenting out the stop call from mobile. The problem is that if we do this, we'll miss out on all the cleanup tasks the node does in preparation of being destroyed.
Option 2. Prepare to stop API
Another option would be to create a second API in the node,
prepareToStop
that would take that event and do all the shutdown tasks but not shut down.When in this state,