incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Update on CordovaView/CordovaActivity - Tests
Date Mon, 16 Jan 2012 20:29:18 GMT
Why don't we have the plugins get re-initialized on the onPageFinished code
in the WebViewClient (CordovaClient in this case)? We already fire
onNativeReady here, so we should probably do the re-init here as well.  I
don't believe that onPageFinished is called when we load an anchor tag, but
I'll take a look at that on this end to see if that's possible.

Joe

On Mon, Jan 16, 2012 at 12:13 PM, Bryce Curtis <curtis.bryce@gmail.com>wrote:

> We have to maintain our own history on Android because there are issues
> with native and JS interactions.
>
> 1. When loading a new page the native code must be reinit
>        - so we get deviceready
>        - get new plugins otherwise plugins would call callbacks meant for
> previous page
> 2. When returning to previous page webview reloads page, but again the
> native code must be reinit for the same reasons above.
> 3. When loading the same page but with a # (used by jQuery navigation), we
> don't want to reload or reinit the native side, so we let the webview
> handle it.
>
> I don't see a way around maintaining our own history.  There were changes
> made to this code recently, so maybe that is a factor.  Simon can help out
> with this.
>
> Bryce
>
>
>
> On Mon, 16 Jan 2012 12:36:23 -0600, Joe Bowser <bowserj@gmail.com> wrote:
>
>  Why are we implementing our own history again instead of using the WebKit
>> history?  This code seems especially fragile, and I would rather get rid
>> of
>> it than keep trying to fix it/write tests for it if possible.
>>
>> Joe
>>
>> On Thu, Jan 12, 2012 at 3:23 PM, Simon MacDonald
>> <simon.macdonald@gmail.com>**wrote:
>>
>>  Hey Joe,
>>>
>>> I pulled the code down and tested it and it looks like it is 90% of
>>> the way there. If you have a two page app and follow this scenario:
>>>
>>> i) start app
>>> ii) page 1 loaded
>>> iii) click on link for page 2
>>> iv) page 2 loaded
>>> v) click back button
>>> vi) page 1 displayed
>>> vii) click back button
>>> viii) exits app
>>>
>>> So it works as expected.
>>>
>>> The problem starts to happen when you go 3 or 4 pages deep. For instance:
>>>
>>> i) start app
>>> ii) page 1 loaded
>>> iii) click on link for page 2
>>> iv) page 2 loaded
>>> v) click on link for page 3
>>> vi) page 3 loaded
>>> vii) click back button
>>> viii) page 1 is displayed
>>> ix) click back button
>>> x) page 3 is displayed
>>>
>>> I've observed the same behaviour when I go four pages deep as well.
>>> You can reproduce this bug if you use the mobile spec code and go into
>>> "Misc Content" then click on "Load another PhoneGap page". When you
>>> click on the back button you'll see the problem.
>>>
>>> Simon Mac Donald
>>> http://hi.im/simonmacdonald
>>>
>>>
>>>
>>> On Thu, Jan 12, 2012 at 2:13 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>> > The back button issues should be resolved. Please pull down the changes
>>> > again.
>>> >
>>> > Thanks
>>> >
>>> > Joe
>>> >
>>> > On Wed, Jan 11, 2012 at 12:00 PM, Simon MacDonald <
>>> simon.macdonald@gmail.com
>>> >> wrote:
>>> >
>>> >> Hey Joe,
>>> >>
>>> >> I've been spending some time today testing your changes and it looks
>>> >> good for the most part. The only areas that I seem to be having issues
>>> >> with are:
>>> >>
>>> >> 1) Splash screen
>>> >> 2) Back button
>>> >>
>>> >> 1) I believe you posted the splash screen would have to be re-worked
>>> >> with the new approach.
>>> >>
>>> >> 2) The back button is acting very oddly:
>>> >>
>>> >> a) Sometimes when I'm in the second page of an application hitting the
>>> >> back button goes back one page, at other times it exits the app
>>> >> completely.
>>> >> b) If you register an event listener for the back button it works
>>> >> great but if you then unregister that event listener the back button
>>> >> does not work anymore. That is, you can't exit the application using
>>> >> the back button anymore.
>>> >> c) The function navigator.app.backHistory() no longer works.
>>> >>
>>> >> You can reproduce the above by using the callback-test code.
>>> >> Specifically the index.html under events.
>>> >>
>>> >> Simon Mac Donald
>>> >> http://hi.im/simonmacdonald
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jan 10, 2012 at 7:56 PM, Joe Bowser <bowserj@gmail.com>
>>> wrote:
>>> >> > Hey
>>> >> >
>>> >> > We've got most of the functionality implemented in
>>> >> > CordovaView/CordovaActivity, and we're starting on tests.  Android
>>> tests
>>> >> > are somewhat complex for anything that uses Activities or Views,
so
>>> we're
>>> >> > using Eclipse for the time being.  Does Apache have a wiki where
we
>>> can
>>> >> put
>>> >> > testing information such as this?
>>> >> >
>>> >> > Anyway, here's the projects needed for the tests:
>>> >> > https://github.com/infil00p/**callback-android/tree/**phonegapview<https://github.com/infil00p/callback-android/tree/phonegapview>-
>>> Source
>>> >> > https://github.com/infil00p/**PhoneGap-CordovaTest<https://github.com/infil00p/PhoneGap-CordovaTest>-
JUnit Tests
>>> >> > https://github.com/infil00p/**PhoneGapView-Test<https://github.com/infil00p/PhoneGapView-Test>-
Test Cases that JUnit
>>> >> uses
>>> >> >
>>> >> > We have three activities in the 3rd project that use the phonegap
>>> jar.
>>> >> >  These activities are what we use to test the different methods
of
>>> >> loading
>>> >> > a PhoneGap application. This is required to test the delayed loadUrl
>>> >> method
>>> >> > for the splashscreen, although we haven't added the tests to it
yet.
>>>  You
>>> >> > can use eclipse to add the PhoneGap project to the build path of
>>> >> > CordovaTest.
>>> >> >
>>> >> > Anyway, have a look at the tests and the recent changes.  Please
>>> provide
>>> >> > feedback and feel free to look at it. Also, DroidGap.java is finally
>>> >> dead!
>>> >> > We've moved all the functionality across the four remaining classes
>>> that
>>> >> > handle this (CordovaActivity, CordovaView, CordovaClient and
>>> GapClient).
>>> >> >  Assuming that things are good, I can author a patch and send it
up
>>> >> and/or
>>> >> > do a pull request.  Whatever our process looks like (which I'd
>>> assume
>>> is
>>> >> in
>>> >> > a wiki somewhere).
>>> >> >
>>> >> > Joe
>>> >>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message