incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryce Curtis" <curtis.br...@gmail.com>
Subject Re: Update on CordovaView/CordovaActivity - Tests
Date Mon, 16 Jan 2012 20:13:46 GMT
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 -
>> Source
>> >> > https://github.com/infil00p/PhoneGap-CordovaTest - JUnit Tests
>> >> > 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
View raw message