On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser <bows...@gmail.com> wrote:
> 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
>
It's unrelated to plugin discovery.
>
>
> > - 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!
>
We have mobile-spec tests for the bridge. Both automated & manual benchmark
ones.
>
> > - 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?
>
Nope.
>
> > - 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.
>
A few of our plugins use one or two methods from it. On the whole, I think
the class causes more harm than good because it has bugs & uses Strings
instead of Uri. Step 1 is to move it into plugins, step 2 would be to
refactor the plugins to not use it at all.
>
> > - 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.
>
Confirmed: It's not used by Capture, only Camera.
>
> > - 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.
>
Yeah, my motivation is the same I think. Wanted to extract it so that I
don't have to use it. Are you sure no one depends on it? Moving it to labs
might be a safer move.
>
> > - 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.
>
All of our constructors look like this:
> public CordovaWebView(Context context) {
> super(context);
> if (CordovaInterface.class.isInstance(context))
> {
> this.cordova = (CordovaInterface) context;
> }
> else
> {
> Log.d(TAG, "Your activity must implement CordovaInterface to
> work");
> }
So, we're currently forcing people to pass in a Context that implements
CordovaInterface.
Instead, we should do:
> public CordovaWebView(CordovaInterface cordova) {
> super(cordova.getActivity());
>
>
> > - 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.
>
Yeah, this will definitely require code review before we even really know
what we're up against.
>
>
> > - 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.
>
:) awesome. I haven't looked into this yet, but look forward to meeting
this Java chicken!
