OK, since we're not talking about each individual one in their own thread (or at least a thread I can find), let's talk about them here:
On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve <agri...@chromium.org> wrote: > > cordova-android: > > - Change plugins to have distinct package names How does this work with plugin discovery? It's better to change it now before we get plugin discovery fully setup and this becomes a problem. Doing this for 3.0 was too much work last minute but this could be done on 3.1 > - Look at using requestAnimationFrame to throttle exec bridge (advice from > a PGD talk) There better be tests for this before it lands since this touches the exec bridge. Do we have JUnit tests for the exec bridge? We probably should! > - Move JSONUtils out of core (to minimize API surface) (was added by our > intern a while ago) > So, this isn't being used by our plugins? > - Move FileHelpers out of core (Most functionality now lives in > CordovaResourceApi) > The last time I checked, our plugins depended on this. If we're not supporting it, it should go. > - Move ExifHelpers out of core and into Camera (used only by Camera) This may also be used by Capture when we capture an image. I have no idea why we have two ways of taking a photo. > - Extract Database plugin out of core (and into... cordova-labs? > cordova-android?) What Database Plugin? If we have a storage plugin still in core, it should die. > - Change CordovaWebview constructors to accept a CordovaInterface instead > of a Context (get the Context from the getActivity() of CordovaInterface) I recommend creating a second constructor instead, since there are examples of CordovaWebViews that use CordovaInterfaces that aren't activities and it's probably easier for CordovaWebView to provide a Context than CordovaInterface to do so in those cases. I don't see why we can't add a second constructor and keep this for those cases. > - Make private (or package-private) any api that is likely unused by third > party plugins We should warn people that we're doing that this release. > - Use source instead of .jar We should allow for both! Using a jar is easier to do from the command line, and this is more CLI work (which there is no shortage of). > > - Easier to debug, faster "project create", consistent with how plugins > work > > - Extract splashscreen logic out of core It can't be done, we've gone through this numerous times. The splashscreen has to appear before we even have a PluginManager instantiated. Someone has to put a Java chicken there to stall while we get the JS Egg ready.
