cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Knoll <>
Subject [DISCUSS] Camera plugin considerations in Android
Date Fri, 16 Oct 2015 23:32:03 GMT
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<>
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?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message