Github user riknoll commented on the pull request:
https://github.com/apache/cordova-android/pull/236#issuecomment-154590431
After getting some feedback from @purplecabbage on the dev list and talking
this over with @jasongin, it sounds as though we should cut everything from
this resume payload besides the pending result (which means we would remove
`app.saveState` as well). The burden will be on the app developer to maintain
their state in local storage including the context surrounding whatever plugin
calls they have pending. The new resume event payload would look like this:
```
{
action: "resume",
pendingResult: {
pluginServiceName: <plugin service name e.g. "Camera">,
pluginStatus: <description of result' status (see
PluginResult.java)>,
result: <the result of the call that would be passed to the
callback>
}
}
```
I agree that this is a much better idea. We should make sure we communicate
the need for saving state well in the Android and plugin docs so that
developers are aware of this unique Android "feature".
Are people okay with the proposed approach for allowing plugins that are
waiting for external results to bundle up their state on the native side?
Alternatively, we can leave plugin developers to be good about maintaining
their state (using something like Android preferences). This is technically
already possible assuming that we fire events correctly, but a little clunky.
The advantage of the approach in this PR is that it exposes the standard
Android way of doing things on the native side with the Bundle save/restore
API. Does that API make sense? Should we open it up to all plugins instead of
just the plugin that is receiving the Activity result?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
