On Mon, Nov 5, 2012 at 9:22 AM, Joe Bowser <bows...@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 <agri...@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 <bows...@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 <bows...@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 > > > > > > > > > >
