Yep, that was my intention.
On Thu, Jul 25, 2013 at 1:56 PM, Joe Bowser <[email protected]> wrote: > Can we break these out and talk about a couple of these? I'm certain > that many of these features will be subject to the Deprecation Policy. > > On Thu, Jul 25, 2013 at 10:48 AM, Andrew Grieve <[email protected]> > wrote: > > We've done some planning around what we'd like to get done over the next > > quarter, and so I thought I'd share. > > > > > > This isn't to say that we'll be going and doing these things without > > further discussion or proper JIRA issues. It also doesn't mean we will be > > solely focused on this list, nor that we'll actually end up completing > > everything on the list. Just that we *currently* think that these things > > should get done. > > > > > > > > cordova-android: > > > > - Change plugins to have distinct package names > > > > - Look at using requestAnimationFrame to throttle exec bridge (advice > from > > a PGD talk) > > > > - Move JSONUtils out of core (to minimize API surface) (was added by our > > intern a while ago) > > > > - Move FileHelpers out of core (Most functionality now lives in > > CordovaResourceApi) > > > > - Move ExifHelpers out of core and into Camera (used only by Camera) > > > > - Extract Database plugin out of core (and into... cordova-labs? > > cordova-android?) > > > > - Change CordovaWebview constructors to accept a CordovaInterface instead > > of a Context (get the Context from the getActivity() of CordovaInterface) > > > > - Make private (or package-private) any api that is likely unused by > third > > party plugins > > > > - (CB-3900) Have PluginResult that gets populated lazily - at the time of > > being sent over the bridge. > > > > - Use source instead of .jar > > > > - Easier to debug, faster "project create", consistent with how > plugins > > work > > > > - Extract splashscreen logic out of core >
