[Android] CordovaWebView is broken

[Joe Bowser <bo...@gmail.com>]

Hey

I just started fixing up our broken JUnit Tests, and I discovered that the
recent refactors broke the CordovaWebView standalone component.  This means
that anyone who is using the CordovaWebView as a standalone component
should probably not upgrade to 2.2.0 and that we'll have to issue a 2.2.1
release to address this issue.

It seems that for some reason deviceready is no longer firing.  I think
this may have to do with the recent changes to plugins as well as the
addition of a thread pool.  I'm going to commit the fixes to the tests
today, but you can recreate the issue by pulling down this debug repo,
putting it in Eclipse and making it use Cordova as a library.

https://github.com/infil00p/CordovaActionView/tree/debug_version

Also, you can debug this using the default activity on the test project,
although the test project still needs a lot of cleaning to be done.

It sucks that we missed this, but we really need to make sure we don't
break the tests when we do a refactor.

I'll add more details to the bug soon.  This harsh sucks, because I don't
think this will be an easy fix. :(

Joe

Re: [Android] CordovaWebView is broken

[Anis KADRI <an...@gmail.com>]

+1 (update :)


On Mon, Nov 5, 2012 at 1:01 PM, Anis KADRI <an...@gmail.com> wrote:

> On Mon, Nov 5, 2012 at 9:22 AM, Joe Bowser <bo...@gmail.com> wrote:
>
>> Hey
>>
>> I know that this kind of seems like a step back, but perhaps we should
>> start with the refactor of DroidGap into CordovaActivity.  The main
>> obstacle that we have right now with the CordovaWebView is the fact that
>> we
>> have to implement everything in CordovaInterface.  While we can't get rid
>> of this, we could create a helper activity that implements this by moving
>> the current methods from DroidGap into that.  Then we can make DroidGap
>> simply an activity that creates the view and optional.
>>
>> Due to the nature of Java, anyone combining other custom activites (i.e.
>> MapActivity) will still have to implement the CordovaInterface, but this
>> should further lower the barrier for many people who want to mix
>> CordovaWebView with Android UI controls, namely the menu bar (in fact,
>> this
>> is the only UI control that I think anyone would want to add).
>>
>> Thoughts?
>>
>
> +1
>
>
>>
>>
>>
>> On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > Aah, I didn't realize that CordovaInterface was meant to be implemented
>> > other than by DroidGap. Sorry about that. Weird that projects would even
>> > compile without having the new method though.
>> >
>> > Once the tests are fixed up, we should definitely add running them to
>> the
>> > list of release steps.
>> >
>> >
>> > On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >
>> > > Nevermind....it's kinda bad but it's not minor release bad.
>> > >
>> > > Basically, adding the thread pool method requirement to the
>> > > CordovaInterface is what broke this.  For some reason when you don't
>> > have a
>> > > thread pool, Cordova silently fails instead of dumping core all over
>> the
>> > > place.  Is it possible that we can get plugins to get the thread pool
>> > from
>> > > elsewhere, or does it have to be in the Activity?
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > >
>> > > > Hey
>> > > >
>> > > > I just started fixing up our broken JUnit Tests, and I discovered
>> that
>> > > the
>> > > > recent refactors broke the CordovaWebView standalone component.
>>  This
>> > > means
>> > > > that anyone who is using the CordovaWebView as a standalone
>> component
>> > > > should probably not upgrade to 2.2.0 and that we'll have to issue a
>> > 2.2.1
>> > > > release to address this issue.
>> > > >
>> > > > It seems that for some reason deviceready is no longer firing.  I
>> think
>> > > > this may have to do with the recent changes to plugins as well as
>> the
>> > > > addition of a thread pool.  I'm going to commit the fixes to the
>> tests
>> > > > today, but you can recreate the issue by pulling down this debug
>> repo,
>> > > > putting it in Eclipse and making it use Cordova as a library.
>> > > >
>> > > > https://github.com/infil00p/CordovaActionView/tree/debug_version
>> > > >
>> > > > Also, you can debug this using the default activity on the test
>> > project,
>> > > > although the test project still needs a lot of cleaning to be done.
>> > > >
>> > > > It sucks that we missed this, but we really need to make sure we
>> don't
>> > > > break the tests when we do a refactor.
>> > > >
>> > > > I'll add more details to the bug soon.  This harsh sucks, because I
>> > don't
>> > > > think this will be an easy fix. :(
>> > > >
>> > > > Joe
>> > > >
>> > >
>> >
>>
>
>

Re: [Android] CordovaWebView is broken

[Anis KADRI <an...@gmail.com>]

On Mon, Nov 5, 2012 at 9:22 AM, Joe Bowser <bo...@gmail.com> wrote:

> Hey
>
> I know that this kind of seems like a step back, but perhaps we should
> start with the refactor of DroidGap into CordovaActivity.  The main
> obstacle that we have right now with the CordovaWebView is the fact that we
> have to implement everything in CordovaInterface.  While we can't get rid
> of this, we could create a helper activity that implements this by moving
> the current methods from DroidGap into that.  Then we can make DroidGap
> simply an activity that creates the view and optional.
>
> Due to the nature of Java, anyone combining other custom activites (i.e.
> MapActivity) will still have to implement the CordovaInterface, but this
> should further lower the barrier for many people who want to mix
> CordovaWebView with Android UI controls, namely the menu bar (in fact, this
> is the only UI control that I think anyone would want to add).
>
> Thoughts?
>

+1


>
>
>
> On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Aah, I didn't realize that CordovaInterface was meant to be implemented
> > other than by DroidGap. Sorry about that. Weird that projects would even
> > compile without having the new method though.
> >
> > Once the tests are fixed up, we should definitely add running them to the
> > list of release steps.
> >
> >
> > On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > Nevermind....it's kinda bad but it's not minor release bad.
> > >
> > > Basically, adding the thread pool method requirement to the
> > > CordovaInterface is what broke this.  For some reason when you don't
> > have a
> > > thread pool, Cordova silently fails instead of dumping core all over
> the
> > > place.  Is it possible that we can get plugins to get the thread pool
> > from
> > > elsewhere, or does it have to be in the Activity?
> > >
> > >
> > >
> > >
> > > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > > > Hey
> > > >
> > > > I just started fixing up our broken JUnit Tests, and I discovered
> that
> > > the
> > > > recent refactors broke the CordovaWebView standalone component.  This
> > > means
> > > > that anyone who is using the CordovaWebView as a standalone component
> > > > should probably not upgrade to 2.2.0 and that we'll have to issue a
> > 2.2.1
> > > > release to address this issue.
> > > >
> > > > It seems that for some reason deviceready is no longer firing.  I
> think
> > > > this may have to do with the recent changes to plugins as well as the
> > > > addition of a thread pool.  I'm going to commit the fixes to the
> tests
> > > > today, but you can recreate the issue by pulling down this debug
> repo,
> > > > putting it in Eclipse and making it use Cordova as a library.
> > > >
> > > > https://github.com/infil00p/CordovaActionView/tree/debug_version
> > > >
> > > > Also, you can debug this using the default activity on the test
> > project,
> > > > although the test project still needs a lot of cleaning to be done.
> > > >
> > > > It sucks that we missed this, but we really need to make sure we
> don't
> > > > break the tests when we do a refactor.
> > > >
> > > > I'll add more details to the bug soon.  This harsh sucks, because I
> > don't
> > > > think this will be an easy fix. :(
> > > >
> > > > Joe
> > > >
> > >
> >
>

Re: [Android] CordovaWebView is broken

[Joe Bowser <bo...@gmail.com>]

Hey

I know that this kind of seems like a step back, but perhaps we should
start with the refactor of DroidGap into CordovaActivity.  The main
obstacle that we have right now with the CordovaWebView is the fact that we
have to implement everything in CordovaInterface.  While we can't get rid
of this, we could create a helper activity that implements this by moving
the current methods from DroidGap into that.  Then we can make DroidGap
simply an activity that creates the view and optional.

Due to the nature of Java, anyone combining other custom activites (i.e.
MapActivity) will still have to implement the CordovaInterface, but this
should further lower the barrier for many people who want to mix
CordovaWebView with Android UI controls, namely the menu bar (in fact, this
is the only UI control that I think anyone would want to add).

Thoughts?



On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Aah, I didn't realize that CordovaInterface was meant to be implemented
> other than by DroidGap. Sorry about that. Weird that projects would even
> compile without having the new method though.
>
> Once the tests are fixed up, we should definitely add running them to the
> list of release steps.
>
>
> On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Nevermind....it's kinda bad but it's not minor release bad.
> >
> > Basically, adding the thread pool method requirement to the
> > CordovaInterface is what broke this.  For some reason when you don't
> have a
> > thread pool, Cordova silently fails instead of dumping core all over the
> > place.  Is it possible that we can get plugins to get the thread pool
> from
> > elsewhere, or does it have to be in the Activity?
> >
> >
> >
> >
> > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > Hey
> > >
> > > I just started fixing up our broken JUnit Tests, and I discovered that
> > the
> > > recent refactors broke the CordovaWebView standalone component.  This
> > means
> > > that anyone who is using the CordovaWebView as a standalone component
> > > should probably not upgrade to 2.2.0 and that we'll have to issue a
> 2.2.1
> > > release to address this issue.
> > >
> > > It seems that for some reason deviceready is no longer firing.  I think
> > > this may have to do with the recent changes to plugins as well as the
> > > addition of a thread pool.  I'm going to commit the fixes to the tests
> > > today, but you can recreate the issue by pulling down this debug repo,
> > > putting it in Eclipse and making it use Cordova as a library.
> > >
> > > https://github.com/infil00p/CordovaActionView/tree/debug_version
> > >
> > > Also, you can debug this using the default activity on the test
> project,
> > > although the test project still needs a lot of cleaning to be done.
> > >
> > > It sucks that we missed this, but we really need to make sure we don't
> > > break the tests when we do a refactor.
> > >
> > > I'll add more details to the bug soon.  This harsh sucks, because I
> don't
> > > think this will be an easy fix. :(
> > >
> > > Joe
> > >
> >
>

Re: [Android] CordovaWebView is broken

[Filip Maj <fi...@adobe.com>]

>Once the tests are fixed up, we should definitely add running them to the
>list of release steps.

+1

Re: [Android] CordovaWebView is broken

[Andrew Grieve <ag...@chromium.org>]

Aah, I didn't realize that CordovaInterface was meant to be implemented
other than by DroidGap. Sorry about that. Weird that projects would even
compile without having the new method though.

Once the tests are fixed up, we should definitely add running them to the
list of release steps.


On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser <bo...@gmail.com> wrote:

> Nevermind....it's kinda bad but it's not minor release bad.
>
> Basically, adding the thread pool method requirement to the
> CordovaInterface is what broke this.  For some reason when you don't have a
> thread pool, Cordova silently fails instead of dumping core all over the
> place.  Is it possible that we can get plugins to get the thread pool from
> elsewhere, or does it have to be in the Activity?
>
>
>
>
> On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Hey
> >
> > I just started fixing up our broken JUnit Tests, and I discovered that
> the
> > recent refactors broke the CordovaWebView standalone component.  This
> means
> > that anyone who is using the CordovaWebView as a standalone component
> > should probably not upgrade to 2.2.0 and that we'll have to issue a 2.2.1
> > release to address this issue.
> >
> > It seems that for some reason deviceready is no longer firing.  I think
> > this may have to do with the recent changes to plugins as well as the
> > addition of a thread pool.  I'm going to commit the fixes to the tests
> > today, but you can recreate the issue by pulling down this debug repo,
> > putting it in Eclipse and making it use Cordova as a library.
> >
> > https://github.com/infil00p/CordovaActionView/tree/debug_version
> >
> > Also, you can debug this using the default activity on the test project,
> > although the test project still needs a lot of cleaning to be done.
> >
> > It sucks that we missed this, but we really need to make sure we don't
> > break the tests when we do a refactor.
> >
> > I'll add more details to the bug soon.  This harsh sucks, because I don't
> > think this will be an easy fix. :(
> >
> > Joe
> >
>

Re: [Android] CordovaWebView is broken

[Joe Bowser <bo...@gmail.com>]

Nevermind....it's kinda bad but it's not minor release bad.

Basically, adding the thread pool method requirement to the
CordovaInterface is what broke this.  For some reason when you don't have a
thread pool, Cordova silently fails instead of dumping core all over the
place.  Is it possible that we can get plugins to get the thread pool from
elsewhere, or does it have to be in the Activity?




On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser <bo...@gmail.com> wrote:

> Hey
>
> I just started fixing up our broken JUnit Tests, and I discovered that the
> recent refactors broke the CordovaWebView standalone component.  This means
> that anyone who is using the CordovaWebView as a standalone component
> should probably not upgrade to 2.2.0 and that we'll have to issue a 2.2.1
> release to address this issue.
>
> It seems that for some reason deviceready is no longer firing.  I think
> this may have to do with the recent changes to plugins as well as the
> addition of a thread pool.  I'm going to commit the fixes to the tests
> today, but you can recreate the issue by pulling down this debug repo,
> putting it in Eclipse and making it use Cordova as a library.
>
> https://github.com/infil00p/CordovaActionView/tree/debug_version
>
> Also, you can debug this using the default activity on the test project,
> although the test project still needs a lot of cleaning to be done.
>
> It sucks that we missed this, but we really need to make sure we don't
> break the tests when we do a refactor.
>
> I'll add more details to the bug soon.  This harsh sucks, because I don't
> think this will be an easy fix. :(
>
> Joe
>