Hey all, Over the past week or so I have been conducting a review of the issues for the camera plugin in JIRA and have noticed two big areas of confusion that seem to plague users in Android. I want to start a DISCUSS thread because both of these involve larger decisions to be made.
1. Cropping Images (allowEdit) There are a number of issues related to this posted in JIRA and it's one of the larger quirks on Android for the camera plugin. The problem is that we are using an undocumented and officially unsupported API for doing cropping and this is leading to unpredictable behavior. We have no control over what cropping Activity the user has on their phone and if those Activities even return their results in a way that is compatible with our plugin (e.g. the Gallery application). Unfortunately, there is no easy way to handle this issue as far as I know beyond implementing our own crop Activity or dropping in some library that does the same thing. Is that the avenue we want to pursue? I think it's a common enough problem to warrant the effort. At the very least I believe we need to have a much sterner warning in the docs about using this feature in Android. 2. Activity Destruction This one is a documented issue where the OS can kill our Activity when it's pushed into the background if the device is on low memory. Unfortunately, this is an unavoidable fact of life in Android that creates a pretty big issue in plugins which call out to another Activity (this is not limited to the camera). There are two ways that I see to pursue a solution to this problem. The first is requiring plugins to handle it on a case by case basis (this pull request<https://github.com/apache/cordova-plugin-camera/pull/97> proposes such a solution). The issue with such an approach is that it encourages platform specific APIs for plugins, which I am against. The second approach would be to somehow persist the application's state across Activity creation/destruction. I'll admit that I am not familiar enough with the webview-native bridge to comment on that particular approach, but I am sure it's a non-trivial undertaking. It does have the obvious upside of being a general solution, however. I noticed in the pull request above that there was some mention of Jesse working on a solution in this direction. Is that still happening? Thanks, Richard
