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 22:43:39 GMT
Hey

I implemented what I discussed earlier and on Android 2.x it works as I
would expect a browser history to work and we manage to have PhoneGap work
for the most part across pages, with it throwing away and reloading the
plugins once the HTML has been loaded into the webview.  However, on the
Galaxy Nexus, apparently Chromium can't load URLs with # in them (I'm not
kidding! We get a 404 with both # and ?).  I'm going to write a work-around
for this in the CordovaClient, since this is a problem with WebView, and
isn't directly related to the history.

But yeah, assuming that Google didn't shit the bed with their browser back
history, it should work fine. Although since I can't seem to get a browser
history working properly without weird threading issues either, I'm not
terribly surprised.  The changes are on the phonegapview branch.

Joe

On Mon, Jan 16, 2012 at 12:29 PM, Joe Bowser <bowserj@gmail.com> wrote:

> 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