cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Google Team's Task Backlog: Android
Date Mon, 29 Jul 2013 18:13:14 GMT
On Mon, Jul 29, 2013 at 7:29 AM, Andrew Grieve <agrieve@chromium.org> wrote:
> On Sun, Jul 28, 2013 at 12:32 AM, Joe Bowser <bowserj@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 <agrieve@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.
>

Except that 3.0 version of the plugin will have
org.apache.cordova.core.foo and 3.1 will have
org.apache.cordova.foo.bar.  So, is this an issue yet for upgrading
the plugin or will it be an uninstall/install thing.  I have no idea.
>
>>
>> > - 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.

Sounds good. I hope nobody else is using it, because we made no
promises about this one.
>>
>> > - 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());
>

I believe that a View MUST have a constructor with a context, so we
still need the constructor there in some form, even if it just calls
super.  It won't just infer that it has two constructors on its own.

Mime
View raw message