You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2012/03/27 22:15:07 UTC

[Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Hey

I've been working on the CordovaWebView branch, and I think we need to
discuss where to put the CallbackServer and PluginManager in the new
implementation.  I'm OK with it being in the view, but I did have it in the
Client before, and I'm wondering what people's thoughts are on that.  Also,
since these are core pieces of Cordova on Android, this may break the
branch, which is fine, but it'd be good if more people looked at this
branch, and discussed how this should work.

https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=shortlog;h=refs/heads/CordovaWebView

http://wiki.apache.org/cordova/CordovaWebView

Joe

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Bryce Curtis <cu...@gmail.com>.

If the problem is limited to a version of the emulator, then it's not
unreasonable to suggest that a developer simply test on another version
that works.  Similarly, if that particular version must be used, then I
would expect the developer to use a real device.  We could list the
emulator versions that have issues in the readme and other docs.

On Sun, Apr 1, 2012 at 4:46 PM, Filip Maj <fi...@adobe.com> wrote:

>
> >I agree that emulators are not a good enough reason to implement a
> >workaround.
> >Is it possible to detect these conditions and simply tell the user it
> >won't work?
>
> +1 to this
>
> >
> >Cheers,
> >  Jesse
>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Filip Maj <fi...@adobe.com>.

>I agree that emulators are not a good enough reason to implement a
>workaround.
>Is it possible to detect these conditions and simply tell the user it
>won't work?

+1 to this

>
>Cheers,
>  Jesse

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Jesse MacFadyen <pu...@gmail.com>.

I agree that emulators are not a good enough reason to implement a workaround.
Is it possible to detect these conditions and simply tell the user it
won't work?

Cheers,
  Jesse

Sent from my iPhone5

On 2012-04-01, at 12:21 PM, Matthew Schulkind <ms...@gmail.com> wrote:

> I'm new to android, so maybe I'm not looking in the right place, but the
> only x86 image I see is for Android 2.3.3 (API 10).
>
> Is there any gain with addJavascriptImplementation other than cleaning
> things up? It'd be a shame to make things more difficult for a large number
> of people for no material gain.
>
> On Sun, Apr 1, 2012 at 2:52 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> If it only is broken on the emulator, I would argue that's not a good
>> enough reason to stay away from using it.  I would recommend that people
>> get a device.  It's not like the devices are prohibitively expensive.
>> (Under $150 on DealExtreme was the cheapest I saw a 2.3 device, probably
>> cheaper on Craigslist)
>>
>> Also, doesn't 4.0.3 work on kvm?  I remember hearing that it does.
>> On Apr 1, 2012 11:41 AM, "Matthew Schulkind" <ms...@gmail.com> wrote:
>>
>>> Looks like addJavascriptInterface is still broken on 2.3.x emulator (not
>>> sure about other versions). 2.3 seems to be the only version with an x86
>>> image for using with kvm, so I expect lots of people (including me) are
>>> using it for development. Probably best to stay away from
>>> addJavascriptInterface for now.
>>>
>>> These are the first lines I get every time I try to call a method on an
>>> addJavascriptInterface object:
>>> W/dalvikvm( 2967): JNI WARNING: jarray 0xb75d9720 points to non-array
>>> object (Ljava/lang/String;)
>>> I/dalvikvm( 2967): "WebViewCoreThread" prio=5 tid=8 NATIVE
>>> I/dalvikvm( 2967):   | group="main" sCount=0 dsCount=0 obj=0xb75b0d90
>>> self=0x93f8410
>>> I/dalvikvm( 2967):   | sysTid=2975 nice=0 sched=0/0 cgrp=[fopen-error:2]
>>> handle=155168040
>>> I/dalvikvm( 2967):   at
>>> android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
>>> Method)
>>> I/dalvikvm( 2967):   at
>>> android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
>>> Method)
>>>
>>> On Sat, Mar 31, 2012 at 1:20 AM, Matthew Schulkind <mschulkind@gmail.com
>>>> wrote:
>>>
>>>> What do you mean by disrupt exactly?
>>>>
>>>> I've seen one potential solution where you basically make the
>> javascript
>>>> call with loadUrl and then wait for a addJavascriptInterface method to
>> be
>>>> called from the result. This waiting can happen on a non-ui thread. The
>>>> biggest problem is how long do you wait for the result to come back in
>>> case
>>>> it's never coming.
>>>>
>>>>
>>>> On Fri, Mar 30, 2012 at 4:58 PM, Joe Bowser <bo...@gmail.com> wrote:
>>>>
>>>>> The problem is that there is no mechanism for this on Android that
>>> doesn't
>>>>> disrupt the UI thread.
>>>>>
>>>>> On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <
>>> mschulkind@gmail.com
>>>>>> wrote:
>>>>>
>>>>>> Works here!
>>>>>>
>>>>>> If exec is getting futzed with, it'd be great if at the same time,
>>>>> support
>>>>>> was added for synchronous return values when calling Java ->
>>> JavaScript.
>>>>>> I'm working on the android port of true native, and I'm either going
>>> to
>>>>>> need this support in cordova directly or in my own code.
>>>>>>
>>>>>> On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> Congrats! Your phone didn't come out of a vending machine!
>>>>>>>
>>>>>>> On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
>>>>>>> <si...@gmail.com>wrote:
>>>>>>>
>>>>>>>> Installed and it looks like everything worked.
>>>>>>>>
>>>>>>>> Simon Mac Donald
>>>>>>>> http://hi.im/simonmacdonald
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bowserj@gmail.com
>>>
>>>>>> wrote:
>>>>>>>>> We don't have enough crap Android devices running 2.3.  This
>> is
>>> to
>>>>>> also
>>>>>>>>> help us buy devices for the device wall.  The application can
>> be
>>>>>> found
>>>>>>>> here:
>>>>>>>>>
>>>>>>>>>
>>>>> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
>>>>>>>>>
>>>>>>>>> On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
>>>>>>>>> <si...@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so
>>>>> lemme
>>>>>>>>>> know when it is up.
>>>>>>>>>>
>>>>>>>>>> But wait, isn't this a job for the PhoneGap Device Wall!
>>>>>>>>>>
>>>>>>>>>> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
>>>>>>>>>>
>>>>>>>>>> Simon Mac Donald
>>>>>>>>>> http://hi.im/simonmacdonald
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <
>> bowserj@gmail.com
>>>>
>>>>>>> wrote:
>>>>>>>>>>> OK, I published a test app on Google Play.  I'll post the
>>> link
>>>>>> once
>>>>>>> it
>>>>>>>>>>> actually shows up.  I want people to download and run it on
>>>>> their
>>>>>>>> Android
>>>>>>>>>>> 2.3 devices to see if we can find any that crash!  If so,
>>>>> it'll be
>>>>>>>>>> recorded
>>>>>>>>>>> in the Error Report.  That way we can finally know is this
>>> is a
>>>>>> real
>>>>>>>> bug
>>>>>>>>>> or
>>>>>>>>>>> something that only exists in the Emulator.
>>>>>>>>>>>
>>>>>>>>>>> I'll throw up the code on a repo somewhere as well.  I made
>>>>> sure
>>>>>> to
>>>>>>>> use
>>>>>>>>>>> zero permissions so that it's clear what the app is. (I bet
>>> it
>>>>>> gets
>>>>>>>>>> really
>>>>>>>>>>> crap ratings!).
>>>>>>>>>>>
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1 science
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <
>>>>> bowserj@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>> On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
>>>>>>>> curtis.bryce@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, I meant providing your own classes that inherit
>> from
>>>>> our
>>>>>>>>>>>>>> CordovaChrome/WebView classes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From what I've observed recently,
>> addJavascriptInterface
>>> is
>>>>>>> still
>>>>>>>>>>>> broken in
>>>>>>>>>>>>>> the emulator and on some (maybe small subset) of real
>>>>> phones.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just tested it on the emulator.  However, I don't
>> think
>>>>> this
>>>>>> is
>>>>>>>> an
>>>>>>>>>>>> issue
>>>>>>>>>>>>> on real phones.  When they wrote the switch, it was
>> meant
>>> to
>>>>>>> allow
>>>>>>>>>>>> Android
>>>>>>>>>>>>> 2.3 to run on crap like the Quench.  So far, I have
>> never
>>>>> seen
>>>>>> a
>>>>>>>> phone
>>>>>>>>>>>> that
>>>>>>>>>>>>> has less than 256 MB of RAM produced, not even the HTC
>>>>> Wildfire
>>>>>>>> (and
>>>>>>>>>> that
>>>>>>>>>>>>> phone sucked!).  I honestly don't think that there's a
>>>>> single
>>>>>>>> Android
>>>>>>>>>> 2.3
>>>>>>>>>>>>> phone that has this bug.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I'm going to release an application to prove
>> this
>>>>>> point.
>>>>>>>> FOR
>>>>>>>>>>>>> SCIENCE!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
>>>>>> bowserj@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
>>>>>>>>>> curtis.bryce@gmail.com
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I really haven't had time to look at this in
>> detail,
>>>>> but
>>>>>>> agree
>>>>>>>>>> that
>>>>>>>>>>>>>>>> anything related to the webview should be in
>>>>>> CordovaWebView.
>>>>>>>> As
>>>>>>>>>> Fil
>>>>>>>>>>>>>>>> mentioned, that includes the history, plugin
>> manager,
>>>>>>>>>> whitelisting,
>>>>>>>>>>>> &
>>>>>>>>>>>>>>>> authentication + callback server.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I assume that overriding chrome/view clients so the
>>>>> user
>>>>>> can
>>>>>>>>>> specify
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> own will still work.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you mean overriding Chrome/View clients?  You
>>> can
>>>>>> use
>>>>>>>> your
>>>>>>>>>> own
>>>>>>>>>>>>>>> classes if they inherit from the CordovaChrome class
>> or
>>>>>>>>>> CordovaWebView
>>>>>>>>>>>>>>> class, but if you just cram a vanilla WebViewClient
>> or
>>>>>>>>>>>> WebChromeClient,
>>>>>>>>>>>>>>> Cordova won't work at all.  This has nothing to do
>> with
>>>>>>>>>>>> CordovaWebView,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> instead is a consequence of the prompt hack that acts
>>> as
>>>>> our
>>>>>>>>>> current
>>>>>>>>>>>>>>> bridge.  If we want to make it so that we're not
>>>>> dependent
>>>>>> on
>>>>>>>> the
>>>>>>>>>>>>>>> ChromeClient, we should probably bring back
>>>>>>>> addJavascriptInterface
>>>>>>>>>> and
>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>> it in the view itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW: Does the emulator still break when we do this on
>>>>>> Android
>>>>>>>> 2.3?
>>>>>>>>>> I
>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>> I'll have to look into that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <
>>>>> fil@adobe.com
>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry for late reply Joe!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Looks great! As for outstanding issues as per
>> your
>>>>> wiki
>>>>>>>> article
>>>>>>>>>>>> [1],
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> would say move everything WebView related, as
>> well
>>> as
>>>>>>>>>>>>>> Cordova-specific
>>>>>>>>>>>>>>>>> such as the plugin manager, into
>>>>> CordovaWebView.java. My
>>>>>>>>>> thinking
>>>>>>>>>>>>>> here
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> that, none of scaffolding necessary to enable
>>> device
>>>>>> APIs
>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>>>> web
>>>>>>>>>>>>>>> view
>>>>>>>>>>>>>>>>> should be a burden on the user - the
>> CordovaWebView
>>>>>> class
>>>>>>>>>> should
>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>>>>> all of that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It separates the cordova-y bits as something the
>>>>> WEbView
>>>>>>>> needs
>>>>>>>>>> to
>>>>>>>>>>>>>>> manage
>>>>>>>>>>>>>>>>> on its own, as well, and cleans up the final
>>>>>>>> Activity-extending
>>>>>>>>>>>> class
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> be simpler. Our end users should not have to
>> worry
>>>>> about
>>>>>>>> that
>>>>>>>>>>>> stuff,
>>>>>>>>>>>>>>> nor
>>>>>>>>>>>>>>>>> do they need to see it in their own activities,
>> or
>>>>> the
>>>>>>>>>> generated
>>>>>>>>>>>>>>>>> activities the baseline tooling within
>>>>> cordova-android
>>>>>>>>>> provides.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IMO: history, plugin manager, whitelisting,
>>>>>>> authentication,
>>>>>>>>>> should
>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> handled by CordovaWebView.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1]
>> http://wiki.apache.org/cordova/CordovaWebView
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 3/28/12 4:06 PM, "Joe Bowser" <
>>> bowserj@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BUMP! Are we all on board with doing this?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
>>>>>>>>>> bowserj@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hey
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I've been working on the CordovaWebView
>> branch,
>>>>> and I
>>>>>>>> think
>>>>>>>>>> we
>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> discuss where to put the CallbackServer and
>>>>>>>> PluginManager in
>>>>>>>>>>>> the
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> implementation.  I'm OK with it being in the
>>> view,
>>>>>> but
>>>>>>> I
>>>>>>>> did
>>>>>>>>>>>> have
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> Client before, and I'm wondering what people's
>>>>>> thoughts
>>>>>>>> are
>>>>>>>>>> on
>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>> Also,
>>>>>>>>>>>>>>>>>>> since these are core pieces of Cordova on
>>> Android,
>>>>>> this
>>>>>>>> may
>>>>>>>>>>>> break
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> branch, which is fine, but it'd be good if
>> more
>>>>>> people
>>>>>>>>>> looked
>>>>>>>>>>>> at
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> branch, and discussed how this should work.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>>>>>>>>>>>>>>>>>>> =shortlog;h=refs/heads/CordovaWebView
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://wiki.apache.org/cordova/CordovaWebView
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Matthew Schulkind <ms...@gmail.com>.

I'm new to android, so maybe I'm not looking in the right place, but the
only x86 image I see is for Android 2.3.3 (API 10).

Is there any gain with addJavascriptImplementation other than cleaning
things up? It'd be a shame to make things more difficult for a large number
of people for no material gain.

On Sun, Apr 1, 2012 at 2:52 PM, Joe Bowser <bo...@gmail.com> wrote:

> If it only is broken on the emulator, I would argue that's not a good
> enough reason to stay away from using it.  I would recommend that people
> get a device.  It's not like the devices are prohibitively expensive.
> (Under $150 on DealExtreme was the cheapest I saw a 2.3 device, probably
> cheaper on Craigslist)
>
> Also, doesn't 4.0.3 work on kvm?  I remember hearing that it does.
> On Apr 1, 2012 11:41 AM, "Matthew Schulkind" <ms...@gmail.com> wrote:
>
> > Looks like addJavascriptInterface is still broken on 2.3.x emulator (not
> > sure about other versions). 2.3 seems to be the only version with an x86
> > image for using with kvm, so I expect lots of people (including me) are
> > using it for development. Probably best to stay away from
> > addJavascriptInterface for now.
> >
> > These are the first lines I get every time I try to call a method on an
> > addJavascriptInterface object:
> > W/dalvikvm( 2967): JNI WARNING: jarray 0xb75d9720 points to non-array
> > object (Ljava/lang/String;)
> > I/dalvikvm( 2967): "WebViewCoreThread" prio=5 tid=8 NATIVE
> > I/dalvikvm( 2967):   | group="main" sCount=0 dsCount=0 obj=0xb75b0d90
> > self=0x93f8410
> > I/dalvikvm( 2967):   | sysTid=2975 nice=0 sched=0/0 cgrp=[fopen-error:2]
> > handle=155168040
> > I/dalvikvm( 2967):   at
> > android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
> > Method)
> > I/dalvikvm( 2967):   at
> > android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
> > Method)
> >
> > On Sat, Mar 31, 2012 at 1:20 AM, Matthew Schulkind <mschulkind@gmail.com
> > >wrote:
> >
> > > What do you mean by disrupt exactly?
> > >
> > > I've seen one potential solution where you basically make the
> javascript
> > > call with loadUrl and then wait for a addJavascriptInterface method to
> be
> > > called from the result. This waiting can happen on a non-ui thread. The
> > > biggest problem is how long do you wait for the result to come back in
> > case
> > > it's never coming.
> > >
> > >
> > > On Fri, Mar 30, 2012 at 4:58 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > >> The problem is that there is no mechanism for this on Android that
> > doesn't
> > >> disrupt the UI thread.
> > >>
> > >> On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <
> > mschulkind@gmail.com
> > >> >wrote:
> > >>
> > >> > Works here!
> > >> >
> > >> > If exec is getting futzed with, it'd be great if at the same time,
> > >> support
> > >> > was added for synchronous return values when calling Java ->
> > JavaScript.
> > >> > I'm working on the android port of true native, and I'm either going
> > to
> > >> > need this support in cordova directly or in my own code.
> > >> >
> > >> > On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > >> >
> > >> > > Congrats! Your phone didn't come out of a vending machine!
> > >> > >
> > >> > > On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
> > >> > > <si...@gmail.com>wrote:
> > >> > >
> > >> > > > Installed and it looks like everything worked.
> > >> > > >
> > >> > > > Simon Mac Donald
> > >> > > > http://hi.im/simonmacdonald
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bowserj@gmail.com
> >
> > >> > wrote:
> > >> > > > > We don't have enough crap Android devices running 2.3.  This
> is
> > to
> > >> > also
> > >> > > > > help us buy devices for the device wall.  The application can
> be
> > >> > found
> > >> > > > here:
> > >> > > > >
> > >> > > > >
> > >> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> > >> > > > >
> > >> > > > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> > >> > > > > <si...@gmail.com>wrote:
> > >> > > > >
> > >> > > > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so
> > >> lemme
> > >> > > > >> know when it is up.
> > >> > > > >>
> > >> > > > >> But wait, isn't this a job for the PhoneGap Device Wall!
> > >> > > > >>
> > >> > > > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> > >> > > > >>
> > >> > > > >> Simon Mac Donald
> > >> > > > >> http://hi.im/simonmacdonald
> > >> > > > >>
> > >> > > > >>
> > >> > > > >>
> > >> > > > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <
> bowserj@gmail.com
> > >
> > >> > > wrote:
> > >> > > > >> > OK, I published a test app on Google Play.  I'll post the
> > link
> > >> > once
> > >> > > it
> > >> > > > >> > actually shows up.  I want people to download and run it on
> > >> their
> > >> > > > Android
> > >> > > > >> > 2.3 devices to see if we can find any that crash!  If so,
> > >> it'll be
> > >> > > > >> recorded
> > >> > > > >> > in the Error Report.  That way we can finally know is this
> > is a
> > >> > real
> > >> > > > bug
> > >> > > > >> or
> > >> > > > >> > something that only exists in the Emulator.
> > >> > > > >> >
> > >> > > > >> > I'll throw up the code on a repo somewhere as well.  I made
> > >> sure
> > >> > to
> > >> > > > use
> > >> > > > >> > zero permissions so that it's clear what the app is. (I bet
> > it
> > >> > gets
> > >> > > > >> really
> > >> > > > >> > crap ratings!).
> > >> > > > >> >
> > >> > > > >> > Joe
> > >> > > > >> >
> > >> > > > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io>
> > >> wrote:
> > >> > > > >> >
> > >> > > > >> >> +1 science
> > >> > > > >> >>
> > >> > > > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <
> > >> bowserj@gmail.com>
> > >> > > > wrote:
> > >> > > > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> > >> > > > curtis.bryce@gmail.com
> > >> > > > >> >> >wrote:
> > >> > > > >> >> >
> > >> > > > >> >> >> Yes, I meant providing your own classes that inherit
> from
> > >> our
> > >> > > > >> >> >> CordovaChrome/WebView classes.
> > >> > > > >> >> >>
> > >> > > > >> >> >> From what I've observed recently,
> addJavascriptInterface
> > is
> > >> > > still
> > >> > > > >> >> broken in
> > >> > > > >> >> >> the emulator and on some (maybe small subset) of real
> > >> phones.
> > >> > > > >> >> >>
> > >> > > > >> >> >
> > >> > > > >> >> > I just tested it on the emulator.  However, I don't
> think
> > >> this
> > >> > is
> > >> > > > an
> > >> > > > >> >> issue
> > >> > > > >> >> > on real phones.  When they wrote the switch, it was
> meant
> > to
> > >> > > allow
> > >> > > > >> >> Android
> > >> > > > >> >> > 2.3 to run on crap like the Quench.  So far, I have
> never
> > >> seen
> > >> > a
> > >> > > > phone
> > >> > > > >> >> that
> > >> > > > >> >> > has less than 256 MB of RAM produced, not even the HTC
> > >> Wildfire
> > >> > > > (and
> > >> > > > >> that
> > >> > > > >> >> > phone sucked!).  I honestly don't think that there's a
> > >> single
> > >> > > > Android
> > >> > > > >> 2.3
> > >> > > > >> >> > phone that has this bug.
> > >> > > > >> >> >
> > >> > > > >> >> > I think I'm going to release an application to prove
> this
> > >> > point.
> > >> > > >  FOR
> > >> > > > >> >> > SCIENCE!
> > >> > > > >> >> >
> > >> > > > >> >> > Joe
> > >> > > > >> >> >
> > >> > > > >> >> >
> > >> > > > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
> > >> > bowserj@gmail.com>
> > >> > > > >> wrote:
> > >> > > > >> >> >>
> > >> > > > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> > >> > > > >> curtis.bryce@gmail.com
> > >> > > > >> >> >> > >wrote:
> > >> > > > >> >> >> >
> > >> > > > >> >> >> > > I really haven't had time to look at this in
> detail,
> > >> but
> > >> > > agree
> > >> > > > >> that
> > >> > > > >> >> >> > > anything related to the webview should be in
> > >> > CordovaWebView.
> > >> > > >  As
> > >> > > > >> Fil
> > >> > > > >> >> >> > > mentioned, that includes the history, plugin
> manager,
> > >> > > > >> whitelisting,
> > >> > > > >> >> &
> > >> > > > >> >> >> > > authentication + callback server.
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> > > I assume that overriding chrome/view clients so the
> > >> user
> > >> > can
> > >> > > > >> specify
> > >> > > > >> >> >> > their
> > >> > > > >> >> >> > > own will still work.
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> > What do you mean overriding Chrome/View clients?  You
> > can
> > >> > use
> > >> > > > your
> > >> > > > >> own
> > >> > > > >> >> >> > classes if they inherit from the CordovaChrome class
> or
> > >> > > > >> CordovaWebView
> > >> > > > >> >> >> > class, but if you just cram a vanilla WebViewClient
> or
> > >> > > > >> >> WebChromeClient,
> > >> > > > >> >> >> > Cordova won't work at all.  This has nothing to do
> with
> > >> > > > >> >> CordovaWebView,
> > >> > > > >> >> >> but
> > >> > > > >> >> >> > instead is a consequence of the prompt hack that acts
> > as
> > >> our
> > >> > > > >> current
> > >> > > > >> >> >> > bridge.  If we want to make it so that we're not
> > >> dependent
> > >> > on
> > >> > > > the
> > >> > > > >> >> >> > ChromeClient, we should probably bring back
> > >> > > > addJavascriptInterface
> > >> > > > >> and
> > >> > > > >> >> >> put
> > >> > > > >> >> >> > it in the view itself.
> > >> > > > >> >> >> >
> > >> > > > >> >> >> > BTW: Does the emulator still break when we do this on
> > >> > Android
> > >> > > > 2.3?
> > >> > > > >>  I
> > >> > > > >> >> >> think
> > >> > > > >> >> >> > I'll have to look into that.
> > >> > > > >> >> >> >
> > >> > > > >> >> >> > Joe
> > >> > > > >> >> >> >
> > >> > > > >> >> >> >
> > >> > > > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <
> > >> fil@adobe.com
> > >> > >
> > >> > > > >> wrote:
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> > > > Sorry for late reply Joe!
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > Looks great! As for outstanding issues as per
> your
> > >> wiki
> > >> > > > article
> > >> > > > >> >> [1],
> > >> > > > >> >> >> I
> > >> > > > >> >> >> > > > would say move everything WebView related, as
> well
> > as
> > >> > > > >> >> >> Cordova-specific
> > >> > > > >> >> >> > > > such as the plugin manager, into
> > >> CordovaWebView.java. My
> > >> > > > >> thinking
> > >> > > > >> >> >> here
> > >> > > > >> >> >> > is
> > >> > > > >> >> >> > > > that, none of scaffolding necessary to enable
> > device
> > >> > APIs
> > >> > > in
> > >> > > > >> the
> > >> > > > >> >> web
> > >> > > > >> >> >> > view
> > >> > > > >> >> >> > > > should be a burden on the user - the
> CordovaWebView
> > >> > class
> > >> > > > >> should
> > >> > > > >> >> >> handle
> > >> > > > >> >> >> > > > all of that.
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > It separates the cordova-y bits as something the
> > >> WEbView
> > >> > > > needs
> > >> > > > >> to
> > >> > > > >> >> >> > manage
> > >> > > > >> >> >> > > > on its own, as well, and cleans up the final
> > >> > > > Activity-extending
> > >> > > > >> >> class
> > >> > > > >> >> >> > to
> > >> > > > >> >> >> > > > be simpler. Our end users should not have to
> worry
> > >> about
> > >> > > > that
> > >> > > > >> >> stuff,
> > >> > > > >> >> >> > nor
> > >> > > > >> >> >> > > > do they need to see it in their own activities,
> or
> > >> the
> > >> > > > >> generated
> > >> > > > >> >> >> > > > activities the baseline tooling within
> > >> cordova-android
> > >> > > > >> provides.
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > IMO: history, plugin manager, whitelisting,
> > >> > > authentication,
> > >> > > > >> should
> > >> > > > >> >> >> all
> > >> > > > >> >> >> > be
> > >> > > > >> >> >> > > > handled by CordovaWebView.
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > [1]
> http://wiki.apache.org/cordova/CordovaWebView
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <
> > bowserj@gmail.com>
> > >> > > wrote:
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > > >BUMP! Are we all on board with doing this?
> > >> > > > >> >> >> > > > >
> > >> > > > >> >> >> > > > >Joe
> > >> > > > >> >> >> > > > >
> > >> > > > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> > >> > > > >> bowserj@gmail.com>
> > >> > > > >> >> >> > wrote:
> > >> > > > >> >> >> > > > >
> > >> > > > >> >> >> > > > >> Hey
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >> I've been working on the CordovaWebView
> branch,
> > >> and I
> > >> > > > think
> > >> > > > >> we
> > >> > > > >> >> >> need
> > >> > > > >> >> >> > to
> > >> > > > >> >> >> > > > >> discuss where to put the CallbackServer and
> > >> > > > PluginManager in
> > >> > > > >> >> the
> > >> > > > >> >> >> new
> > >> > > > >> >> >> > > > >> implementation.  I'm OK with it being in the
> > view,
> > >> > but
> > >> > > I
> > >> > > > did
> > >> > > > >> >> have
> > >> > > > >> >> >> it
> > >> > > > >> >> >> > > in
> > >> > > > >> >> >> > > > >>the
> > >> > > > >> >> >> > > > >> Client before, and I'm wondering what people's
> > >> > thoughts
> > >> > > > are
> > >> > > > >> on
> > >> > > > >> >> >> that.
> > >> > > > >> >> >> > > > >>Also,
> > >> > > > >> >> >> > > > >> since these are core pieces of Cordova on
> > Android,
> > >> > this
> > >> > > > may
> > >> > > > >> >> break
> > >> > > > >> >> >> > the
> > >> > > > >> >> >> > > > >> branch, which is fine, but it'd be good if
> more
> > >> > people
> > >> > > > >> looked
> > >> > > > >> >> at
> > >> > > > >> >> >> > this
> > >> > > > >> >> >> > > > >> branch, and discussed how this should work.
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> >
> > >> > > > >> >> >>
> > >> > > > >> >>
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > >> > > > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > > >> Joe
> > >> > > > >> >> >> > > > >>
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > > >
> > >> > > > >> >> >> > >
> > >> > > > >> >> >> >
> > >> > > > >> >> >>
> > >> > > > >> >>
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

If it only is broken on the emulator, I would argue that's not a good
enough reason to stay away from using it.  I would recommend that people
get a device.  It's not like the devices are prohibitively expensive.
(Under $150 on DealExtreme was the cheapest I saw a 2.3 device, probably
cheaper on Craigslist)

Also, doesn't 4.0.3 work on kvm?  I remember hearing that it does.
On Apr 1, 2012 11:41 AM, "Matthew Schulkind" <ms...@gmail.com> wrote:

> Looks like addJavascriptInterface is still broken on 2.3.x emulator (not
> sure about other versions). 2.3 seems to be the only version with an x86
> image for using with kvm, so I expect lots of people (including me) are
> using it for development. Probably best to stay away from
> addJavascriptInterface for now.
>
> These are the first lines I get every time I try to call a method on an
> addJavascriptInterface object:
> W/dalvikvm( 2967): JNI WARNING: jarray 0xb75d9720 points to non-array
> object (Ljava/lang/String;)
> I/dalvikvm( 2967): "WebViewCoreThread" prio=5 tid=8 NATIVE
> I/dalvikvm( 2967):   | group="main" sCount=0 dsCount=0 obj=0xb75b0d90
> self=0x93f8410
> I/dalvikvm( 2967):   | sysTid=2975 nice=0 sched=0/0 cgrp=[fopen-error:2]
> handle=155168040
> I/dalvikvm( 2967):   at
> android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
> Method)
> I/dalvikvm( 2967):   at
> android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
> Method)
>
> On Sat, Mar 31, 2012 at 1:20 AM, Matthew Schulkind <mschulkind@gmail.com
> >wrote:
>
> > What do you mean by disrupt exactly?
> >
> > I've seen one potential solution where you basically make the javascript
> > call with loadUrl and then wait for a addJavascriptInterface method to be
> > called from the result. This waiting can happen on a non-ui thread. The
> > biggest problem is how long do you wait for the result to come back in
> case
> > it's never coming.
> >
> >
> > On Fri, Mar 30, 2012 at 4:58 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> The problem is that there is no mechanism for this on Android that
> doesn't
> >> disrupt the UI thread.
> >>
> >> On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <
> mschulkind@gmail.com
> >> >wrote:
> >>
> >> > Works here!
> >> >
> >> > If exec is getting futzed with, it'd be great if at the same time,
> >> support
> >> > was added for synchronous return values when calling Java ->
> JavaScript.
> >> > I'm working on the android port of true native, and I'm either going
> to
> >> > need this support in cordova directly or in my own code.
> >> >
> >> > On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >> >
> >> > > Congrats! Your phone didn't come out of a vending machine!
> >> > >
> >> > > On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
> >> > > <si...@gmail.com>wrote:
> >> > >
> >> > > > Installed and it looks like everything worked.
> >> > > >
> >> > > > Simon Mac Donald
> >> > > > http://hi.im/simonmacdonald
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com>
> >> > wrote:
> >> > > > > We don't have enough crap Android devices running 2.3.  This is
> to
> >> > also
> >> > > > > help us buy devices for the device wall.  The application can be
> >> > found
> >> > > > here:
> >> > > > >
> >> > > > >
> >> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> >> > > > >
> >> > > > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> >> > > > > <si...@gmail.com>wrote:
> >> > > > >
> >> > > > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so
> >> lemme
> >> > > > >> know when it is up.
> >> > > > >>
> >> > > > >> But wait, isn't this a job for the PhoneGap Device Wall!
> >> > > > >>
> >> > > > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> >> > > > >>
> >> > > > >> Simon Mac Donald
> >> > > > >> http://hi.im/simonmacdonald
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bowserj@gmail.com
> >
> >> > > wrote:
> >> > > > >> > OK, I published a test app on Google Play.  I'll post the
> link
> >> > once
> >> > > it
> >> > > > >> > actually shows up.  I want people to download and run it on
> >> their
> >> > > > Android
> >> > > > >> > 2.3 devices to see if we can find any that crash!  If so,
> >> it'll be
> >> > > > >> recorded
> >> > > > >> > in the Error Report.  That way we can finally know is this
> is a
> >> > real
> >> > > > bug
> >> > > > >> or
> >> > > > >> > something that only exists in the Emulator.
> >> > > > >> >
> >> > > > >> > I'll throw up the code on a repo somewhere as well.  I made
> >> sure
> >> > to
> >> > > > use
> >> > > > >> > zero permissions so that it's clear what the app is. (I bet
> it
> >> > gets
> >> > > > >> really
> >> > > > >> > crap ratings!).
> >> > > > >> >
> >> > > > >> > Joe
> >> > > > >> >
> >> > > > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io>
> >> wrote:
> >> > > > >> >
> >> > > > >> >> +1 science
> >> > > > >> >>
> >> > > > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <
> >> bowserj@gmail.com>
> >> > > > wrote:
> >> > > > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> >> > > > curtis.bryce@gmail.com
> >> > > > >> >> >wrote:
> >> > > > >> >> >
> >> > > > >> >> >> Yes, I meant providing your own classes that inherit from
> >> our
> >> > > > >> >> >> CordovaChrome/WebView classes.
> >> > > > >> >> >>
> >> > > > >> >> >> From what I've observed recently, addJavascriptInterface
> is
> >> > > still
> >> > > > >> >> broken in
> >> > > > >> >> >> the emulator and on some (maybe small subset) of real
> >> phones.
> >> > > > >> >> >>
> >> > > > >> >> >
> >> > > > >> >> > I just tested it on the emulator.  However, I don't think
> >> this
> >> > is
> >> > > > an
> >> > > > >> >> issue
> >> > > > >> >> > on real phones.  When they wrote the switch, it was meant
> to
> >> > > allow
> >> > > > >> >> Android
> >> > > > >> >> > 2.3 to run on crap like the Quench.  So far, I have never
> >> seen
> >> > a
> >> > > > phone
> >> > > > >> >> that
> >> > > > >> >> > has less than 256 MB of RAM produced, not even the HTC
> >> Wildfire
> >> > > > (and
> >> > > > >> that
> >> > > > >> >> > phone sucked!).  I honestly don't think that there's a
> >> single
> >> > > > Android
> >> > > > >> 2.3
> >> > > > >> >> > phone that has this bug.
> >> > > > >> >> >
> >> > > > >> >> > I think I'm going to release an application to prove this
> >> > point.
> >> > > >  FOR
> >> > > > >> >> > SCIENCE!
> >> > > > >> >> >
> >> > > > >> >> > Joe
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
> >> > bowserj@gmail.com>
> >> > > > >> wrote:
> >> > > > >> >> >>
> >> > > > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> >> > > > >> curtis.bryce@gmail.com
> >> > > > >> >> >> > >wrote:
> >> > > > >> >> >> >
> >> > > > >> >> >> > > I really haven't had time to look at this in detail,
> >> but
> >> > > agree
> >> > > > >> that
> >> > > > >> >> >> > > anything related to the webview should be in
> >> > CordovaWebView.
> >> > > >  As
> >> > > > >> Fil
> >> > > > >> >> >> > > mentioned, that includes the history, plugin manager,
> >> > > > >> whitelisting,
> >> > > > >> >> &
> >> > > > >> >> >> > > authentication + callback server.
> >> > > > >> >> >> > >
> >> > > > >> >> >> > > I assume that overriding chrome/view clients so the
> >> user
> >> > can
> >> > > > >> specify
> >> > > > >> >> >> > their
> >> > > > >> >> >> > > own will still work.
> >> > > > >> >> >> > >
> >> > > > >> >> >> > >
> >> > > > >> >> >> > What do you mean overriding Chrome/View clients?  You
> can
> >> > use
> >> > > > your
> >> > > > >> own
> >> > > > >> >> >> > classes if they inherit from the CordovaChrome class or
> >> > > > >> CordovaWebView
> >> > > > >> >> >> > class, but if you just cram a vanilla WebViewClient or
> >> > > > >> >> WebChromeClient,
> >> > > > >> >> >> > Cordova won't work at all.  This has nothing to do with
> >> > > > >> >> CordovaWebView,
> >> > > > >> >> >> but
> >> > > > >> >> >> > instead is a consequence of the prompt hack that acts
> as
> >> our
> >> > > > >> current
> >> > > > >> >> >> > bridge.  If we want to make it so that we're not
> >> dependent
> >> > on
> >> > > > the
> >> > > > >> >> >> > ChromeClient, we should probably bring back
> >> > > > addJavascriptInterface
> >> > > > >> and
> >> > > > >> >> >> put
> >> > > > >> >> >> > it in the view itself.
> >> > > > >> >> >> >
> >> > > > >> >> >> > BTW: Does the emulator still break when we do this on
> >> > Android
> >> > > > 2.3?
> >> > > > >>  I
> >> > > > >> >> >> think
> >> > > > >> >> >> > I'll have to look into that.
> >> > > > >> >> >> >
> >> > > > >> >> >> > Joe
> >> > > > >> >> >> >
> >> > > > >> >> >> >
> >> > > > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <
> >> fil@adobe.com
> >> > >
> >> > > > >> wrote:
> >> > > > >> >> >> > >
> >> > > > >> >> >> > > > Sorry for late reply Joe!
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > Looks great! As for outstanding issues as per your
> >> wiki
> >> > > > article
> >> > > > >> >> [1],
> >> > > > >> >> >> I
> >> > > > >> >> >> > > > would say move everything WebView related, as well
> as
> >> > > > >> >> >> Cordova-specific
> >> > > > >> >> >> > > > such as the plugin manager, into
> >> CordovaWebView.java. My
> >> > > > >> thinking
> >> > > > >> >> >> here
> >> > > > >> >> >> > is
> >> > > > >> >> >> > > > that, none of scaffolding necessary to enable
> device
> >> > APIs
> >> > > in
> >> > > > >> the
> >> > > > >> >> web
> >> > > > >> >> >> > view
> >> > > > >> >> >> > > > should be a burden on the user - the CordovaWebView
> >> > class
> >> > > > >> should
> >> > > > >> >> >> handle
> >> > > > >> >> >> > > > all of that.
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > It separates the cordova-y bits as something the
> >> WEbView
> >> > > > needs
> >> > > > >> to
> >> > > > >> >> >> > manage
> >> > > > >> >> >> > > > on its own, as well, and cleans up the final
> >> > > > Activity-extending
> >> > > > >> >> class
> >> > > > >> >> >> > to
> >> > > > >> >> >> > > > be simpler. Our end users should not have to worry
> >> about
> >> > > > that
> >> > > > >> >> stuff,
> >> > > > >> >> >> > nor
> >> > > > >> >> >> > > > do they need to see it in their own activities, or
> >> the
> >> > > > >> generated
> >> > > > >> >> >> > > > activities the baseline tooling within
> >> cordova-android
> >> > > > >> provides.
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > IMO: history, plugin manager, whitelisting,
> >> > > authentication,
> >> > > > >> should
> >> > > > >> >> >> all
> >> > > > >> >> >> > be
> >> > > > >> >> >> > > > handled by CordovaWebView.
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <
> bowserj@gmail.com>
> >> > > wrote:
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > > >BUMP! Are we all on board with doing this?
> >> > > > >> >> >> > > > >
> >> > > > >> >> >> > > > >Joe
> >> > > > >> >> >> > > > >
> >> > > > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> >> > > > >> bowserj@gmail.com>
> >> > > > >> >> >> > wrote:
> >> > > > >> >> >> > > > >
> >> > > > >> >> >> > > > >> Hey
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >> I've been working on the CordovaWebView branch,
> >> and I
> >> > > > think
> >> > > > >> we
> >> > > > >> >> >> need
> >> > > > >> >> >> > to
> >> > > > >> >> >> > > > >> discuss where to put the CallbackServer and
> >> > > > PluginManager in
> >> > > > >> >> the
> >> > > > >> >> >> new
> >> > > > >> >> >> > > > >> implementation.  I'm OK with it being in the
> view,
> >> > but
> >> > > I
> >> > > > did
> >> > > > >> >> have
> >> > > > >> >> >> it
> >> > > > >> >> >> > > in
> >> > > > >> >> >> > > > >>the
> >> > > > >> >> >> > > > >> Client before, and I'm wondering what people's
> >> > thoughts
> >> > > > are
> >> > > > >> on
> >> > > > >> >> >> that.
> >> > > > >> >> >> > > > >>Also,
> >> > > > >> >> >> > > > >> since these are core pieces of Cordova on
> Android,
> >> > this
> >> > > > may
> >> > > > >> >> break
> >> > > > >> >> >> > the
> >> > > > >> >> >> > > > >> branch, which is fine, but it'd be good if more
> >> > people
> >> > > > >> looked
> >> > > > >> >> at
> >> > > > >> >> >> > this
> >> > > > >> >> >> > > > >> branch, and discussed how this should work.
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > >
> >> > > > >> >> >> >
> >> > > > >> >> >>
> >> > > > >> >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> >> > > > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > > >> Joe
> >> > > > >> >> >> > > > >>
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > > >
> >> > > > >> >> >> > >
> >> > > > >> >> >> >
> >> > > > >> >> >>
> >> > > > >> >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Matthew Schulkind <ms...@gmail.com>.

Looks like addJavascriptInterface is still broken on 2.3.x emulator (not
sure about other versions). 2.3 seems to be the only version with an x86
image for using with kvm, so I expect lots of people (including me) are
using it for development. Probably best to stay away from
addJavascriptInterface for now.

These are the first lines I get every time I try to call a method on an
addJavascriptInterface object:
W/dalvikvm( 2967): JNI WARNING: jarray 0xb75d9720 points to non-array
object (Ljava/lang/String;)
I/dalvikvm( 2967): "WebViewCoreThread" prio=5 tid=8 NATIVE
I/dalvikvm( 2967):   | group="main" sCount=0 dsCount=0 obj=0xb75b0d90
self=0x93f8410
I/dalvikvm( 2967):   | sysTid=2975 nice=0 sched=0/0 cgrp=[fopen-error:2]
handle=155168040
I/dalvikvm( 2967):   at
android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
Method)
I/dalvikvm( 2967):   at
android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native
Method)

On Sat, Mar 31, 2012 at 1:20 AM, Matthew Schulkind <ms...@gmail.com>wrote:

> What do you mean by disrupt exactly?
>
> I've seen one potential solution where you basically make the javascript
> call with loadUrl and then wait for a addJavascriptInterface method to be
> called from the result. This waiting can happen on a non-ui thread. The
> biggest problem is how long do you wait for the result to come back in case
> it's never coming.
>
>
> On Fri, Mar 30, 2012 at 4:58 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> The problem is that there is no mechanism for this on Android that doesn't
>> disrupt the UI thread.
>>
>> On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <mschulkind@gmail.com
>> >wrote:
>>
>> > Works here!
>> >
>> > If exec is getting futzed with, it'd be great if at the same time,
>> support
>> > was added for synchronous return values when calling Java -> JavaScript.
>> > I'm working on the android port of true native, and I'm either going to
>> > need this support in cordova directly or in my own code.
>> >
>> > On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >
>> > > Congrats! Your phone didn't come out of a vending machine!
>> > >
>> > > On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
>> > > <si...@gmail.com>wrote:
>> > >
>> > > > Installed and it looks like everything worked.
>> > > >
>> > > > Simon Mac Donald
>> > > > http://hi.im/simonmacdonald
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com>
>> > wrote:
>> > > > > We don't have enough crap Android devices running 2.3.  This is to
>> > also
>> > > > > help us buy devices for the device wall.  The application can be
>> > found
>> > > > here:
>> > > > >
>> > > > >
>> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
>> > > > >
>> > > > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
>> > > > > <si...@gmail.com>wrote:
>> > > > >
>> > > > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so
>> lemme
>> > > > >> know when it is up.
>> > > > >>
>> > > > >> But wait, isn't this a job for the PhoneGap Device Wall!
>> > > > >>
>> > > > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
>> > > > >>
>> > > > >> Simon Mac Donald
>> > > > >> http://hi.im/simonmacdonald
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com>
>> > > wrote:
>> > > > >> > OK, I published a test app on Google Play.  I'll post the link
>> > once
>> > > it
>> > > > >> > actually shows up.  I want people to download and run it on
>> their
>> > > > Android
>> > > > >> > 2.3 devices to see if we can find any that crash!  If so,
>> it'll be
>> > > > >> recorded
>> > > > >> > in the Error Report.  That way we can finally know is this is a
>> > real
>> > > > bug
>> > > > >> or
>> > > > >> > something that only exists in the Emulator.
>> > > > >> >
>> > > > >> > I'll throw up the code on a repo somewhere as well.  I made
>> sure
>> > to
>> > > > use
>> > > > >> > zero permissions so that it's clear what the app is. (I bet it
>> > gets
>> > > > >> really
>> > > > >> > crap ratings!).
>> > > > >> >
>> > > > >> > Joe
>> > > > >> >
>> > > > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io>
>> wrote:
>> > > > >> >
>> > > > >> >> +1 science
>> > > > >> >>
>> > > > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <
>> bowserj@gmail.com>
>> > > > wrote:
>> > > > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
>> > > > curtis.bryce@gmail.com
>> > > > >> >> >wrote:
>> > > > >> >> >
>> > > > >> >> >> Yes, I meant providing your own classes that inherit from
>> our
>> > > > >> >> >> CordovaChrome/WebView classes.
>> > > > >> >> >>
>> > > > >> >> >> From what I've observed recently, addJavascriptInterface is
>> > > still
>> > > > >> >> broken in
>> > > > >> >> >> the emulator and on some (maybe small subset) of real
>> phones.
>> > > > >> >> >>
>> > > > >> >> >
>> > > > >> >> > I just tested it on the emulator.  However, I don't think
>> this
>> > is
>> > > > an
>> > > > >> >> issue
>> > > > >> >> > on real phones.  When they wrote the switch, it was meant to
>> > > allow
>> > > > >> >> Android
>> > > > >> >> > 2.3 to run on crap like the Quench.  So far, I have never
>> seen
>> > a
>> > > > phone
>> > > > >> >> that
>> > > > >> >> > has less than 256 MB of RAM produced, not even the HTC
>> Wildfire
>> > > > (and
>> > > > >> that
>> > > > >> >> > phone sucked!).  I honestly don't think that there's a
>> single
>> > > > Android
>> > > > >> 2.3
>> > > > >> >> > phone that has this bug.
>> > > > >> >> >
>> > > > >> >> > I think I'm going to release an application to prove this
>> > point.
>> > > >  FOR
>> > > > >> >> > SCIENCE!
>> > > > >> >> >
>> > > > >> >> > Joe
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
>> > bowserj@gmail.com>
>> > > > >> wrote:
>> > > > >> >> >>
>> > > > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
>> > > > >> curtis.bryce@gmail.com
>> > > > >> >> >> > >wrote:
>> > > > >> >> >> >
>> > > > >> >> >> > > I really haven't had time to look at this in detail,
>> but
>> > > agree
>> > > > >> that
>> > > > >> >> >> > > anything related to the webview should be in
>> > CordovaWebView.
>> > > >  As
>> > > > >> Fil
>> > > > >> >> >> > > mentioned, that includes the history, plugin manager,
>> > > > >> whitelisting,
>> > > > >> >> &
>> > > > >> >> >> > > authentication + callback server.
>> > > > >> >> >> > >
>> > > > >> >> >> > > I assume that overriding chrome/view clients so the
>> user
>> > can
>> > > > >> specify
>> > > > >> >> >> > their
>> > > > >> >> >> > > own will still work.
>> > > > >> >> >> > >
>> > > > >> >> >> > >
>> > > > >> >> >> > What do you mean overriding Chrome/View clients?  You can
>> > use
>> > > > your
>> > > > >> own
>> > > > >> >> >> > classes if they inherit from the CordovaChrome class or
>> > > > >> CordovaWebView
>> > > > >> >> >> > class, but if you just cram a vanilla WebViewClient or
>> > > > >> >> WebChromeClient,
>> > > > >> >> >> > Cordova won't work at all.  This has nothing to do with
>> > > > >> >> CordovaWebView,
>> > > > >> >> >> but
>> > > > >> >> >> > instead is a consequence of the prompt hack that acts as
>> our
>> > > > >> current
>> > > > >> >> >> > bridge.  If we want to make it so that we're not
>> dependent
>> > on
>> > > > the
>> > > > >> >> >> > ChromeClient, we should probably bring back
>> > > > addJavascriptInterface
>> > > > >> and
>> > > > >> >> >> put
>> > > > >> >> >> > it in the view itself.
>> > > > >> >> >> >
>> > > > >> >> >> > BTW: Does the emulator still break when we do this on
>> > Android
>> > > > 2.3?
>> > > > >>  I
>> > > > >> >> >> think
>> > > > >> >> >> > I'll have to look into that.
>> > > > >> >> >> >
>> > > > >> >> >> > Joe
>> > > > >> >> >> >
>> > > > >> >> >> >
>> > > > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <
>> fil@adobe.com
>> > >
>> > > > >> wrote:
>> > > > >> >> >> > >
>> > > > >> >> >> > > > Sorry for late reply Joe!
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > Looks great! As for outstanding issues as per your
>> wiki
>> > > > article
>> > > > >> >> [1],
>> > > > >> >> >> I
>> > > > >> >> >> > > > would say move everything WebView related, as well as
>> > > > >> >> >> Cordova-specific
>> > > > >> >> >> > > > such as the plugin manager, into
>> CordovaWebView.java. My
>> > > > >> thinking
>> > > > >> >> >> here
>> > > > >> >> >> > is
>> > > > >> >> >> > > > that, none of scaffolding necessary to enable device
>> > APIs
>> > > in
>> > > > >> the
>> > > > >> >> web
>> > > > >> >> >> > view
>> > > > >> >> >> > > > should be a burden on the user - the CordovaWebView
>> > class
>> > > > >> should
>> > > > >> >> >> handle
>> > > > >> >> >> > > > all of that.
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > It separates the cordova-y bits as something the
>> WEbView
>> > > > needs
>> > > > >> to
>> > > > >> >> >> > manage
>> > > > >> >> >> > > > on its own, as well, and cleans up the final
>> > > > Activity-extending
>> > > > >> >> class
>> > > > >> >> >> > to
>> > > > >> >> >> > > > be simpler. Our end users should not have to worry
>> about
>> > > > that
>> > > > >> >> stuff,
>> > > > >> >> >> > nor
>> > > > >> >> >> > > > do they need to see it in their own activities, or
>> the
>> > > > >> generated
>> > > > >> >> >> > > > activities the baseline tooling within
>> cordova-android
>> > > > >> provides.
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > IMO: history, plugin manager, whitelisting,
>> > > authentication,
>> > > > >> should
>> > > > >> >> >> all
>> > > > >> >> >> > be
>> > > > >> >> >> > > > handled by CordovaWebView.
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com>
>> > > wrote:
>> > > > >> >> >> > > >
>> > > > >> >> >> > > > >BUMP! Are we all on board with doing this?
>> > > > >> >> >> > > > >
>> > > > >> >> >> > > > >Joe
>> > > > >> >> >> > > > >
>> > > > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
>> > > > >> bowserj@gmail.com>
>> > > > >> >> >> > wrote:
>> > > > >> >> >> > > > >
>> > > > >> >> >> > > > >> Hey
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >> I've been working on the CordovaWebView branch,
>> and I
>> > > > think
>> > > > >> we
>> > > > >> >> >> need
>> > > > >> >> >> > to
>> > > > >> >> >> > > > >> discuss where to put the CallbackServer and
>> > > > PluginManager in
>> > > > >> >> the
>> > > > >> >> >> new
>> > > > >> >> >> > > > >> implementation.  I'm OK with it being in the view,
>> > but
>> > > I
>> > > > did
>> > > > >> >> have
>> > > > >> >> >> it
>> > > > >> >> >> > > in
>> > > > >> >> >> > > > >>the
>> > > > >> >> >> > > > >> Client before, and I'm wondering what people's
>> > thoughts
>> > > > are
>> > > > >> on
>> > > > >> >> >> that.
>> > > > >> >> >> > > > >>Also,
>> > > > >> >> >> > > > >> since these are core pieces of Cordova on Android,
>> > this
>> > > > may
>> > > > >> >> break
>> > > > >> >> >> > the
>> > > > >> >> >> > > > >> branch, which is fine, but it'd be good if more
>> > people
>> > > > >> looked
>> > > > >> >> at
>> > > > >> >> >> > this
>> > > > >> >> >> > > > >> branch, and discussed how this should work.
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > >
>> > > > >> >> >> > >
>> > > > >> >> >> >
>> > > > >> >> >>
>> > > > >> >>
>> > > > >>
>> > > >
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>> > > > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > > >> Joe
>> > > > >> >> >> > > > >>
>> > > > >> >> >> > > >
>> > > > >> >> >> > > >
>> > > > >> >> >> > >
>> > > > >> >> >> >
>> > > > >> >> >>
>> > > > >> >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Matthew Schulkind <ms...@gmail.com>.

What do you mean by disrupt exactly?

I've seen one potential solution where you basically make the javascript
call with loadUrl and then wait for a addJavascriptInterface method to be
called from the result. This waiting can happen on a non-ui thread. The
biggest problem is how long do you wait for the result to come back in case
it's never coming.

On Fri, Mar 30, 2012 at 4:58 PM, Joe Bowser <bo...@gmail.com> wrote:

> The problem is that there is no mechanism for this on Android that doesn't
> disrupt the UI thread.
>
> On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <mschulkind@gmail.com
> >wrote:
>
> > Works here!
> >
> > If exec is getting futzed with, it'd be great if at the same time,
> support
> > was added for synchronous return values when calling Java -> JavaScript.
> > I'm working on the android port of true native, and I'm either going to
> > need this support in cordova directly or in my own code.
> >
> > On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > Congrats! Your phone didn't come out of a vending machine!
> > >
> > > On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
> > > <si...@gmail.com>wrote:
> > >
> > > > Installed and it looks like everything worked.
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > > >
> > > >
> > > >
> > > > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > > > > We don't have enough crap Android devices running 2.3.  This is to
> > also
> > > > > help us buy devices for the device wall.  The application can be
> > found
> > > > here:
> > > > >
> > > > >
> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> > > > >
> > > > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> > > > > <si...@gmail.com>wrote:
> > > > >
> > > > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
> > > > >> know when it is up.
> > > > >>
> > > > >> But wait, isn't this a job for the PhoneGap Device Wall!
> > > > >>
> > > > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> > > > >>
> > > > >> Simon Mac Donald
> > > > >> http://hi.im/simonmacdonald
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com>
> > > wrote:
> > > > >> > OK, I published a test app on Google Play.  I'll post the link
> > once
> > > it
> > > > >> > actually shows up.  I want people to download and run it on
> their
> > > > Android
> > > > >> > 2.3 devices to see if we can find any that crash!  If so, it'll
> be
> > > > >> recorded
> > > > >> > in the Error Report.  That way we can finally know is this is a
> > real
> > > > bug
> > > > >> or
> > > > >> > something that only exists in the Emulator.
> > > > >> >
> > > > >> > I'll throw up the code on a repo somewhere as well.  I made sure
> > to
> > > > use
> > > > >> > zero permissions so that it's clear what the app is. (I bet it
> > gets
> > > > >> really
> > > > >> > crap ratings!).
> > > > >> >
> > > > >> > Joe
> > > > >> >
> > > > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io>
> wrote:
> > > > >> >
> > > > >> >> +1 science
> > > > >> >>
> > > > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bowserj@gmail.com
> >
> > > > wrote:
> > > > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> > > > curtis.bryce@gmail.com
> > > > >> >> >wrote:
> > > > >> >> >
> > > > >> >> >> Yes, I meant providing your own classes that inherit from
> our
> > > > >> >> >> CordovaChrome/WebView classes.
> > > > >> >> >>
> > > > >> >> >> From what I've observed recently, addJavascriptInterface is
> > > still
> > > > >> >> broken in
> > > > >> >> >> the emulator and on some (maybe small subset) of real
> phones.
> > > > >> >> >>
> > > > >> >> >
> > > > >> >> > I just tested it on the emulator.  However, I don't think
> this
> > is
> > > > an
> > > > >> >> issue
> > > > >> >> > on real phones.  When they wrote the switch, it was meant to
> > > allow
> > > > >> >> Android
> > > > >> >> > 2.3 to run on crap like the Quench.  So far, I have never
> seen
> > a
> > > > phone
> > > > >> >> that
> > > > >> >> > has less than 256 MB of RAM produced, not even the HTC
> Wildfire
> > > > (and
> > > > >> that
> > > > >> >> > phone sucked!).  I honestly don't think that there's a single
> > > > Android
> > > > >> 2.3
> > > > >> >> > phone that has this bug.
> > > > >> >> >
> > > > >> >> > I think I'm going to release an application to prove this
> > point.
> > > >  FOR
> > > > >> >> > SCIENCE!
> > > > >> >> >
> > > > >> >> > Joe
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
> > bowserj@gmail.com>
> > > > >> wrote:
> > > > >> >> >>
> > > > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> > > > >> curtis.bryce@gmail.com
> > > > >> >> >> > >wrote:
> > > > >> >> >> >
> > > > >> >> >> > > I really haven't had time to look at this in detail, but
> > > agree
> > > > >> that
> > > > >> >> >> > > anything related to the webview should be in
> > CordovaWebView.
> > > >  As
> > > > >> Fil
> > > > >> >> >> > > mentioned, that includes the history, plugin manager,
> > > > >> whitelisting,
> > > > >> >> &
> > > > >> >> >> > > authentication + callback server.
> > > > >> >> >> > >
> > > > >> >> >> > > I assume that overriding chrome/view clients so the user
> > can
> > > > >> specify
> > > > >> >> >> > their
> > > > >> >> >> > > own will still work.
> > > > >> >> >> > >
> > > > >> >> >> > >
> > > > >> >> >> > What do you mean overriding Chrome/View clients?  You can
> > use
> > > > your
> > > > >> own
> > > > >> >> >> > classes if they inherit from the CordovaChrome class or
> > > > >> CordovaWebView
> > > > >> >> >> > class, but if you just cram a vanilla WebViewClient or
> > > > >> >> WebChromeClient,
> > > > >> >> >> > Cordova won't work at all.  This has nothing to do with
> > > > >> >> CordovaWebView,
> > > > >> >> >> but
> > > > >> >> >> > instead is a consequence of the prompt hack that acts as
> our
> > > > >> current
> > > > >> >> >> > bridge.  If we want to make it so that we're not dependent
> > on
> > > > the
> > > > >> >> >> > ChromeClient, we should probably bring back
> > > > addJavascriptInterface
> > > > >> and
> > > > >> >> >> put
> > > > >> >> >> > it in the view itself.
> > > > >> >> >> >
> > > > >> >> >> > BTW: Does the emulator still break when we do this on
> > Android
> > > > 2.3?
> > > > >>  I
> > > > >> >> >> think
> > > > >> >> >> > I'll have to look into that.
> > > > >> >> >> >
> > > > >> >> >> > Joe
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <
> fil@adobe.com
> > >
> > > > >> wrote:
> > > > >> >> >> > >
> > > > >> >> >> > > > Sorry for late reply Joe!
> > > > >> >> >> > > >
> > > > >> >> >> > > > Looks great! As for outstanding issues as per your
> wiki
> > > > article
> > > > >> >> [1],
> > > > >> >> >> I
> > > > >> >> >> > > > would say move everything WebView related, as well as
> > > > >> >> >> Cordova-specific
> > > > >> >> >> > > > such as the plugin manager, into CordovaWebView.java.
> My
> > > > >> thinking
> > > > >> >> >> here
> > > > >> >> >> > is
> > > > >> >> >> > > > that, none of scaffolding necessary to enable device
> > APIs
> > > in
> > > > >> the
> > > > >> >> web
> > > > >> >> >> > view
> > > > >> >> >> > > > should be a burden on the user - the CordovaWebView
> > class
> > > > >> should
> > > > >> >> >> handle
> > > > >> >> >> > > > all of that.
> > > > >> >> >> > > >
> > > > >> >> >> > > > It separates the cordova-y bits as something the
> WEbView
> > > > needs
> > > > >> to
> > > > >> >> >> > manage
> > > > >> >> >> > > > on its own, as well, and cleans up the final
> > > > Activity-extending
> > > > >> >> class
> > > > >> >> >> > to
> > > > >> >> >> > > > be simpler. Our end users should not have to worry
> about
> > > > that
> > > > >> >> stuff,
> > > > >> >> >> > nor
> > > > >> >> >> > > > do they need to see it in their own activities, or the
> > > > >> generated
> > > > >> >> >> > > > activities the baseline tooling within cordova-android
> > > > >> provides.
> > > > >> >> >> > > >
> > > > >> >> >> > > > IMO: history, plugin manager, whitelisting,
> > > authentication,
> > > > >> should
> > > > >> >> >> all
> > > > >> >> >> > be
> > > > >> >> >> > > > handled by CordovaWebView.
> > > > >> >> >> > > >
> > > > >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > > > >> >> >> > > >
> > > > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com>
> > > wrote:
> > > > >> >> >> > > >
> > > > >> >> >> > > > >BUMP! Are we all on board with doing this?
> > > > >> >> >> > > > >
> > > > >> >> >> > > > >Joe
> > > > >> >> >> > > > >
> > > > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> > > > >> bowserj@gmail.com>
> > > > >> >> >> > wrote:
> > > > >> >> >> > > > >
> > > > >> >> >> > > > >> Hey
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >> I've been working on the CordovaWebView branch,
> and I
> > > > think
> > > > >> we
> > > > >> >> >> need
> > > > >> >> >> > to
> > > > >> >> >> > > > >> discuss where to put the CallbackServer and
> > > > PluginManager in
> > > > >> >> the
> > > > >> >> >> new
> > > > >> >> >> > > > >> implementation.  I'm OK with it being in the view,
> > but
> > > I
> > > > did
> > > > >> >> have
> > > > >> >> >> it
> > > > >> >> >> > > in
> > > > >> >> >> > > > >>the
> > > > >> >> >> > > > >> Client before, and I'm wondering what people's
> > thoughts
> > > > are
> > > > >> on
> > > > >> >> >> that.
> > > > >> >> >> > > > >>Also,
> > > > >> >> >> > > > >> since these are core pieces of Cordova on Android,
> > this
> > > > may
> > > > >> >> break
> > > > >> >> >> > the
> > > > >> >> >> > > > >> branch, which is fine, but it'd be good if more
> > people
> > > > >> looked
> > > > >> >> at
> > > > >> >> >> > this
> > > > >> >> >> > > > >> branch, and discussed how this should work.
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >>
> > > > >> >> >> > > >
> > > > >> >> >> > >
> > > > >> >> >> >
> > > > >> >> >>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > > > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > > > >> >> >> > > > >>
> > > > >> >> >> > > > >> Joe
> > > > >> >> >> > > > >>
> > > > >> >> >> > > >
> > > > >> >> >> > > >
> > > > >> >> >> > >
> > > > >> >> >> >
> > > > >> >> >>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

The problem is that there is no mechanism for this on Android that doesn't
disrupt the UI thread.

On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind <ms...@gmail.com>wrote:

> Works here!
>
> If exec is getting futzed with, it'd be great if at the same time, support
> was added for synchronous return values when calling Java -> JavaScript.
> I'm working on the android port of true native, and I'm either going to
> need this support in cordova directly or in my own code.
>
> On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Congrats! Your phone didn't come out of a vending machine!
> >
> > On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
> > <si...@gmail.com>wrote:
> >
> > > Installed and it looks like everything worked.
> > >
> > > Simon Mac Donald
> > > http://hi.im/simonmacdonald
> > >
> > >
> > >
> > > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com>
> wrote:
> > > > We don't have enough crap Android devices running 2.3.  This is to
> also
> > > > help us buy devices for the device wall.  The application can be
> found
> > > here:
> > > >
> > > > https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> > > >
> > > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> > > > <si...@gmail.com>wrote:
> > > >
> > > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
> > > >> know when it is up.
> > > >>
> > > >> But wait, isn't this a job for the PhoneGap Device Wall!
> > > >>
> > > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> > > >>
> > > >> Simon Mac Donald
> > > >> http://hi.im/simonmacdonald
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > > >> > OK, I published a test app on Google Play.  I'll post the link
> once
> > it
> > > >> > actually shows up.  I want people to download and run it on their
> > > Android
> > > >> > 2.3 devices to see if we can find any that crash!  If so, it'll be
> > > >> recorded
> > > >> > in the Error Report.  That way we can finally know is this is a
> real
> > > bug
> > > >> or
> > > >> > something that only exists in the Emulator.
> > > >> >
> > > >> > I'll throw up the code on a repo somewhere as well.  I made sure
> to
> > > use
> > > >> > zero permissions so that it's clear what the app is. (I bet it
> gets
> > > >> really
> > > >> > crap ratings!).
> > > >> >
> > > >> > Joe
> > > >> >
> > > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
> > > >> >
> > > >> >> +1 science
> > > >> >>
> > > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com>
> > > wrote:
> > > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> > > curtis.bryce@gmail.com
> > > >> >> >wrote:
> > > >> >> >
> > > >> >> >> Yes, I meant providing your own classes that inherit from our
> > > >> >> >> CordovaChrome/WebView classes.
> > > >> >> >>
> > > >> >> >> From what I've observed recently, addJavascriptInterface is
> > still
> > > >> >> broken in
> > > >> >> >> the emulator and on some (maybe small subset) of real phones.
> > > >> >> >>
> > > >> >> >
> > > >> >> > I just tested it on the emulator.  However, I don't think this
> is
> > > an
> > > >> >> issue
> > > >> >> > on real phones.  When they wrote the switch, it was meant to
> > allow
> > > >> >> Android
> > > >> >> > 2.3 to run on crap like the Quench.  So far, I have never seen
> a
> > > phone
> > > >> >> that
> > > >> >> > has less than 256 MB of RAM produced, not even the HTC Wildfire
> > > (and
> > > >> that
> > > >> >> > phone sucked!).  I honestly don't think that there's a single
> > > Android
> > > >> 2.3
> > > >> >> > phone that has this bug.
> > > >> >> >
> > > >> >> > I think I'm going to release an application to prove this
> point.
> > >  FOR
> > > >> >> > SCIENCE!
> > > >> >> >
> > > >> >> > Joe
> > > >> >> >
> > > >> >> >
> > > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <
> bowserj@gmail.com>
> > > >> wrote:
> > > >> >> >>
> > > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> > > >> curtis.bryce@gmail.com
> > > >> >> >> > >wrote:
> > > >> >> >> >
> > > >> >> >> > > I really haven't had time to look at this in detail, but
> > agree
> > > >> that
> > > >> >> >> > > anything related to the webview should be in
> CordovaWebView.
> > >  As
> > > >> Fil
> > > >> >> >> > > mentioned, that includes the history, plugin manager,
> > > >> whitelisting,
> > > >> >> &
> > > >> >> >> > > authentication + callback server.
> > > >> >> >> > >
> > > >> >> >> > > I assume that overriding chrome/view clients so the user
> can
> > > >> specify
> > > >> >> >> > their
> > > >> >> >> > > own will still work.
> > > >> >> >> > >
> > > >> >> >> > >
> > > >> >> >> > What do you mean overriding Chrome/View clients?  You can
> use
> > > your
> > > >> own
> > > >> >> >> > classes if they inherit from the CordovaChrome class or
> > > >> CordovaWebView
> > > >> >> >> > class, but if you just cram a vanilla WebViewClient or
> > > >> >> WebChromeClient,
> > > >> >> >> > Cordova won't work at all.  This has nothing to do with
> > > >> >> CordovaWebView,
> > > >> >> >> but
> > > >> >> >> > instead is a consequence of the prompt hack that acts as our
> > > >> current
> > > >> >> >> > bridge.  If we want to make it so that we're not dependent
> on
> > > the
> > > >> >> >> > ChromeClient, we should probably bring back
> > > addJavascriptInterface
> > > >> and
> > > >> >> >> put
> > > >> >> >> > it in the view itself.
> > > >> >> >> >
> > > >> >> >> > BTW: Does the emulator still break when we do this on
> Android
> > > 2.3?
> > > >>  I
> > > >> >> >> think
> > > >> >> >> > I'll have to look into that.
> > > >> >> >> >
> > > >> >> >> > Joe
> > > >> >> >> >
> > > >> >> >> >
> > > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fil@adobe.com
> >
> > > >> wrote:
> > > >> >> >> > >
> > > >> >> >> > > > Sorry for late reply Joe!
> > > >> >> >> > > >
> > > >> >> >> > > > Looks great! As for outstanding issues as per your wiki
> > > article
> > > >> >> [1],
> > > >> >> >> I
> > > >> >> >> > > > would say move everything WebView related, as well as
> > > >> >> >> Cordova-specific
> > > >> >> >> > > > such as the plugin manager, into CordovaWebView.java. My
> > > >> thinking
> > > >> >> >> here
> > > >> >> >> > is
> > > >> >> >> > > > that, none of scaffolding necessary to enable device
> APIs
> > in
> > > >> the
> > > >> >> web
> > > >> >> >> > view
> > > >> >> >> > > > should be a burden on the user - the CordovaWebView
> class
> > > >> should
> > > >> >> >> handle
> > > >> >> >> > > > all of that.
> > > >> >> >> > > >
> > > >> >> >> > > > It separates the cordova-y bits as something the WEbView
> > > needs
> > > >> to
> > > >> >> >> > manage
> > > >> >> >> > > > on its own, as well, and cleans up the final
> > > Activity-extending
> > > >> >> class
> > > >> >> >> > to
> > > >> >> >> > > > be simpler. Our end users should not have to worry about
> > > that
> > > >> >> stuff,
> > > >> >> >> > nor
> > > >> >> >> > > > do they need to see it in their own activities, or the
> > > >> generated
> > > >> >> >> > > > activities the baseline tooling within cordova-android
> > > >> provides.
> > > >> >> >> > > >
> > > >> >> >> > > > IMO: history, plugin manager, whitelisting,
> > authentication,
> > > >> should
> > > >> >> >> all
> > > >> >> >> > be
> > > >> >> >> > > > handled by CordovaWebView.
> > > >> >> >> > > >
> > > >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > > >> >> >> > > >
> > > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com>
> > wrote:
> > > >> >> >> > > >
> > > >> >> >> > > > >BUMP! Are we all on board with doing this?
> > > >> >> >> > > > >
> > > >> >> >> > > > >Joe
> > > >> >> >> > > > >
> > > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> > > >> bowserj@gmail.com>
> > > >> >> >> > wrote:
> > > >> >> >> > > > >
> > > >> >> >> > > > >> Hey
> > > >> >> >> > > > >>
> > > >> >> >> > > > >> I've been working on the CordovaWebView branch, and I
> > > think
> > > >> we
> > > >> >> >> need
> > > >> >> >> > to
> > > >> >> >> > > > >> discuss where to put the CallbackServer and
> > > PluginManager in
> > > >> >> the
> > > >> >> >> new
> > > >> >> >> > > > >> implementation.  I'm OK with it being in the view,
> but
> > I
> > > did
> > > >> >> have
> > > >> >> >> it
> > > >> >> >> > > in
> > > >> >> >> > > > >>the
> > > >> >> >> > > > >> Client before, and I'm wondering what people's
> thoughts
> > > are
> > > >> on
> > > >> >> >> that.
> > > >> >> >> > > > >>Also,
> > > >> >> >> > > > >> since these are core pieces of Cordova on Android,
> this
> > > may
> > > >> >> break
> > > >> >> >> > the
> > > >> >> >> > > > >> branch, which is fine, but it'd be good if more
> people
> > > >> looked
> > > >> >> at
> > > >> >> >> > this
> > > >> >> >> > > > >> branch, and discussed how this should work.
> > > >> >> >> > > > >>
> > > >> >> >> > > > >>
> > > >> >> >> > > > >>
> > > >> >> >> > > > >>
> > > >> >> >> > > >
> > > >> >> >> > >
> > > >> >> >> >
> > > >> >> >>
> > > >> >>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > > >> >> >> > > > >>
> > > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > > >> >> >> > > > >>
> > > >> >> >> > > > >> Joe
> > > >> >> >> > > > >>
> > > >> >> >> > > >
> > > >> >> >> > > >
> > > >> >> >> > >
> > > >> >> >> >
> > > >> >> >>
> > > >> >>
> > > >>
> > >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Matthew Schulkind <ms...@gmail.com>.

Works here!

If exec is getting futzed with, it'd be great if at the same time, support
was added for synchronous return values when calling Java -> JavaScript.
I'm working on the android port of true native, and I'm either going to
need this support in cordova directly or in my own code.

On Fri, Mar 30, 2012 at 12:39 PM, Joe Bowser <bo...@gmail.com> wrote:

> Congrats! Your phone didn't come out of a vending machine!
>
> On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
> <si...@gmail.com>wrote:
>
> > Installed and it looks like everything worked.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> >
> > On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com> wrote:
> > > We don't have enough crap Android devices running 2.3.  This is to also
> > > help us buy devices for the device wall.  The application can be found
> > here:
> > >
> > > https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> > >
> > > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> > > <si...@gmail.com>wrote:
> > >
> > >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
> > >> know when it is up.
> > >>
> > >> But wait, isn't this a job for the PhoneGap Device Wall!
> > >>
> > >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> > >>
> > >> Simon Mac Donald
> > >> http://hi.im/simonmacdonald
> > >>
> > >>
> > >>
> > >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> > >> > OK, I published a test app on Google Play.  I'll post the link once
> it
> > >> > actually shows up.  I want people to download and run it on their
> > Android
> > >> > 2.3 devices to see if we can find any that crash!  If so, it'll be
> > >> recorded
> > >> > in the Error Report.  That way we can finally know is this is a real
> > bug
> > >> or
> > >> > something that only exists in the Emulator.
> > >> >
> > >> > I'll throw up the code on a repo somewhere as well.  I made sure to
> > use
> > >> > zero permissions so that it's clear what the app is. (I bet it gets
> > >> really
> > >> > crap ratings!).
> > >> >
> > >> > Joe
> > >> >
> > >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
> > >> >
> > >> >> +1 science
> > >> >>
> > >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> > curtis.bryce@gmail.com
> > >> >> >wrote:
> > >> >> >
> > >> >> >> Yes, I meant providing your own classes that inherit from our
> > >> >> >> CordovaChrome/WebView classes.
> > >> >> >>
> > >> >> >> From what I've observed recently, addJavascriptInterface is
> still
> > >> >> broken in
> > >> >> >> the emulator and on some (maybe small subset) of real phones.
> > >> >> >>
> > >> >> >
> > >> >> > I just tested it on the emulator.  However, I don't think this is
> > an
> > >> >> issue
> > >> >> > on real phones.  When they wrote the switch, it was meant to
> allow
> > >> >> Android
> > >> >> > 2.3 to run on crap like the Quench.  So far, I have never seen a
> > phone
> > >> >> that
> > >> >> > has less than 256 MB of RAM produced, not even the HTC Wildfire
> > (and
> > >> that
> > >> >> > phone sucked!).  I honestly don't think that there's a single
> > Android
> > >> 2.3
> > >> >> > phone that has this bug.
> > >> >> >
> > >> >> > I think I'm going to release an application to prove this point.
> >  FOR
> > >> >> > SCIENCE!
> > >> >> >
> > >> >> > Joe
> > >> >> >
> > >> >> >
> > >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com>
> > >> wrote:
> > >> >> >>
> > >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> > >> curtis.bryce@gmail.com
> > >> >> >> > >wrote:
> > >> >> >> >
> > >> >> >> > > I really haven't had time to look at this in detail, but
> agree
> > >> that
> > >> >> >> > > anything related to the webview should be in CordovaWebView.
> >  As
> > >> Fil
> > >> >> >> > > mentioned, that includes the history, plugin manager,
> > >> whitelisting,
> > >> >> &
> > >> >> >> > > authentication + callback server.
> > >> >> >> > >
> > >> >> >> > > I assume that overriding chrome/view clients so the user can
> > >> specify
> > >> >> >> > their
> > >> >> >> > > own will still work.
> > >> >> >> > >
> > >> >> >> > >
> > >> >> >> > What do you mean overriding Chrome/View clients?  You can use
> > your
> > >> own
> > >> >> >> > classes if they inherit from the CordovaChrome class or
> > >> CordovaWebView
> > >> >> >> > class, but if you just cram a vanilla WebViewClient or
> > >> >> WebChromeClient,
> > >> >> >> > Cordova won't work at all.  This has nothing to do with
> > >> >> CordovaWebView,
> > >> >> >> but
> > >> >> >> > instead is a consequence of the prompt hack that acts as our
> > >> current
> > >> >> >> > bridge.  If we want to make it so that we're not dependent on
> > the
> > >> >> >> > ChromeClient, we should probably bring back
> > addJavascriptInterface
> > >> and
> > >> >> >> put
> > >> >> >> > it in the view itself.
> > >> >> >> >
> > >> >> >> > BTW: Does the emulator still break when we do this on Android
> > 2.3?
> > >>  I
> > >> >> >> think
> > >> >> >> > I'll have to look into that.
> > >> >> >> >
> > >> >> >> > Joe
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com>
> > >> wrote:
> > >> >> >> > >
> > >> >> >> > > > Sorry for late reply Joe!
> > >> >> >> > > >
> > >> >> >> > > > Looks great! As for outstanding issues as per your wiki
> > article
> > >> >> [1],
> > >> >> >> I
> > >> >> >> > > > would say move everything WebView related, as well as
> > >> >> >> Cordova-specific
> > >> >> >> > > > such as the plugin manager, into CordovaWebView.java. My
> > >> thinking
> > >> >> >> here
> > >> >> >> > is
> > >> >> >> > > > that, none of scaffolding necessary to enable device APIs
> in
> > >> the
> > >> >> web
> > >> >> >> > view
> > >> >> >> > > > should be a burden on the user - the CordovaWebView class
> > >> should
> > >> >> >> handle
> > >> >> >> > > > all of that.
> > >> >> >> > > >
> > >> >> >> > > > It separates the cordova-y bits as something the WEbView
> > needs
> > >> to
> > >> >> >> > manage
> > >> >> >> > > > on its own, as well, and cleans up the final
> > Activity-extending
> > >> >> class
> > >> >> >> > to
> > >> >> >> > > > be simpler. Our end users should not have to worry about
> > that
> > >> >> stuff,
> > >> >> >> > nor
> > >> >> >> > > > do they need to see it in their own activities, or the
> > >> generated
> > >> >> >> > > > activities the baseline tooling within cordova-android
> > >> provides.
> > >> >> >> > > >
> > >> >> >> > > > IMO: history, plugin manager, whitelisting,
> authentication,
> > >> should
> > >> >> >> all
> > >> >> >> > be
> > >> >> >> > > > handled by CordovaWebView.
> > >> >> >> > > >
> > >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > >> >> >> > > >
> > >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com>
> wrote:
> > >> >> >> > > >
> > >> >> >> > > > >BUMP! Are we all on board with doing this?
> > >> >> >> > > > >
> > >> >> >> > > > >Joe
> > >> >> >> > > > >
> > >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> > >> bowserj@gmail.com>
> > >> >> >> > wrote:
> > >> >> >> > > > >
> > >> >> >> > > > >> Hey
> > >> >> >> > > > >>
> > >> >> >> > > > >> I've been working on the CordovaWebView branch, and I
> > think
> > >> we
> > >> >> >> need
> > >> >> >> > to
> > >> >> >> > > > >> discuss where to put the CallbackServer and
> > PluginManager in
> > >> >> the
> > >> >> >> new
> > >> >> >> > > > >> implementation.  I'm OK with it being in the view, but
> I
> > did
> > >> >> have
> > >> >> >> it
> > >> >> >> > > in
> > >> >> >> > > > >>the
> > >> >> >> > > > >> Client before, and I'm wondering what people's thoughts
> > are
> > >> on
> > >> >> >> that.
> > >> >> >> > > > >>Also,
> > >> >> >> > > > >> since these are core pieces of Cordova on Android, this
> > may
> > >> >> break
> > >> >> >> > the
> > >> >> >> > > > >> branch, which is fine, but it'd be good if more people
> > >> looked
> > >> >> at
> > >> >> >> > this
> > >> >> >> > > > >> branch, and discussed how this should work.
> > >> >> >> > > > >>
> > >> >> >> > > > >>
> > >> >> >> > > > >>
> > >> >> >> > > > >>
> > >> >> >> > > >
> > >> >> >> > >
> > >> >> >> >
> > >> >> >>
> > >> >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > >> >> >> > > > >>
> > >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > >> >> >> > > > >>
> > >> >> >> > > > >> Joe
> > >> >> >> > > > >>
> > >> >> >> > > >
> > >> >> >> > > >
> > >> >> >> > >
> > >> >> >> >
> > >> >> >>
> > >> >>
> > >>
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

Congrats! Your phone didn't come out of a vending machine!

On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
<si...@gmail.com>wrote:

> Installed and it looks like everything worked.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
>
> On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com> wrote:
> > We don't have enough crap Android devices running 2.3.  This is to also
> > help us buy devices for the device wall.  The application can be found
> here:
> >
> > https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
> >
> > On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> > <si...@gmail.com>wrote:
> >
> >> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
> >> know when it is up.
> >>
> >> But wait, isn't this a job for the PhoneGap Device Wall!
> >>
> >> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >>
> >> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> > OK, I published a test app on Google Play.  I'll post the link once it
> >> > actually shows up.  I want people to download and run it on their
> Android
> >> > 2.3 devices to see if we can find any that crash!  If so, it'll be
> >> recorded
> >> > in the Error Report.  That way we can finally know is this is a real
> bug
> >> or
> >> > something that only exists in the Emulator.
> >> >
> >> > I'll throw up the code on a repo somewhere as well.  I made sure to
> use
> >> > zero permissions so that it's clear what the app is. (I bet it gets
> >> really
> >> > crap ratings!).
> >> >
> >> > Joe
> >> >
> >> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> >> +1 science
> >> >>
> >> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <
> curtis.bryce@gmail.com
> >> >> >wrote:
> >> >> >
> >> >> >> Yes, I meant providing your own classes that inherit from our
> >> >> >> CordovaChrome/WebView classes.
> >> >> >>
> >> >> >> From what I've observed recently, addJavascriptInterface is still
> >> >> broken in
> >> >> >> the emulator and on some (maybe small subset) of real phones.
> >> >> >>
> >> >> >
> >> >> > I just tested it on the emulator.  However, I don't think this is
> an
> >> >> issue
> >> >> > on real phones.  When they wrote the switch, it was meant to allow
> >> >> Android
> >> >> > 2.3 to run on crap like the Quench.  So far, I have never seen a
> phone
> >> >> that
> >> >> > has less than 256 MB of RAM produced, not even the HTC Wildfire
> (and
> >> that
> >> >> > phone sucked!).  I honestly don't think that there's a single
> Android
> >> 2.3
> >> >> > phone that has this bug.
> >> >> >
> >> >> > I think I'm going to release an application to prove this point.
>  FOR
> >> >> > SCIENCE!
> >> >> >
> >> >> > Joe
> >> >> >
> >> >> >
> >> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >> >> >>
> >> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> >> curtis.bryce@gmail.com
> >> >> >> > >wrote:
> >> >> >> >
> >> >> >> > > I really haven't had time to look at this in detail, but agree
> >> that
> >> >> >> > > anything related to the webview should be in CordovaWebView.
>  As
> >> Fil
> >> >> >> > > mentioned, that includes the history, plugin manager,
> >> whitelisting,
> >> >> &
> >> >> >> > > authentication + callback server.
> >> >> >> > >
> >> >> >> > > I assume that overriding chrome/view clients so the user can
> >> specify
> >> >> >> > their
> >> >> >> > > own will still work.
> >> >> >> > >
> >> >> >> > >
> >> >> >> > What do you mean overriding Chrome/View clients?  You can use
> your
> >> own
> >> >> >> > classes if they inherit from the CordovaChrome class or
> >> CordovaWebView
> >> >> >> > class, but if you just cram a vanilla WebViewClient or
> >> >> WebChromeClient,
> >> >> >> > Cordova won't work at all.  This has nothing to do with
> >> >> CordovaWebView,
> >> >> >> but
> >> >> >> > instead is a consequence of the prompt hack that acts as our
> >> current
> >> >> >> > bridge.  If we want to make it so that we're not dependent on
> the
> >> >> >> > ChromeClient, we should probably bring back
> addJavascriptInterface
> >> and
> >> >> >> put
> >> >> >> > it in the view itself.
> >> >> >> >
> >> >> >> > BTW: Does the emulator still break when we do this on Android
> 2.3?
> >>  I
> >> >> >> think
> >> >> >> > I'll have to look into that.
> >> >> >> >
> >> >> >> > Joe
> >> >> >> >
> >> >> >> >
> >> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com>
> >> wrote:
> >> >> >> > >
> >> >> >> > > > Sorry for late reply Joe!
> >> >> >> > > >
> >> >> >> > > > Looks great! As for outstanding issues as per your wiki
> article
> >> >> [1],
> >> >> >> I
> >> >> >> > > > would say move everything WebView related, as well as
> >> >> >> Cordova-specific
> >> >> >> > > > such as the plugin manager, into CordovaWebView.java. My
> >> thinking
> >> >> >> here
> >> >> >> > is
> >> >> >> > > > that, none of scaffolding necessary to enable device APIs in
> >> the
> >> >> web
> >> >> >> > view
> >> >> >> > > > should be a burden on the user - the CordovaWebView class
> >> should
> >> >> >> handle
> >> >> >> > > > all of that.
> >> >> >> > > >
> >> >> >> > > > It separates the cordova-y bits as something the WEbView
> needs
> >> to
> >> >> >> > manage
> >> >> >> > > > on its own, as well, and cleans up the final
> Activity-extending
> >> >> class
> >> >> >> > to
> >> >> >> > > > be simpler. Our end users should not have to worry about
> that
> >> >> stuff,
> >> >> >> > nor
> >> >> >> > > > do they need to see it in their own activities, or the
> >> generated
> >> >> >> > > > activities the baseline tooling within cordova-android
> >> provides.
> >> >> >> > > >
> >> >> >> > > > IMO: history, plugin manager, whitelisting, authentication,
> >> should
> >> >> >> all
> >> >> >> > be
> >> >> >> > > > handled by CordovaWebView.
> >> >> >> > > >
> >> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> >> >> >> > > >
> >> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >> >> >> > > >
> >> >> >> > > > >BUMP! Are we all on board with doing this?
> >> >> >> > > > >
> >> >> >> > > > >Joe
> >> >> >> > > > >
> >> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> >> bowserj@gmail.com>
> >> >> >> > wrote:
> >> >> >> > > > >
> >> >> >> > > > >> Hey
> >> >> >> > > > >>
> >> >> >> > > > >> I've been working on the CordovaWebView branch, and I
> think
> >> we
> >> >> >> need
> >> >> >> > to
> >> >> >> > > > >> discuss where to put the CallbackServer and
> PluginManager in
> >> >> the
> >> >> >> new
> >> >> >> > > > >> implementation.  I'm OK with it being in the view, but I
> did
> >> >> have
> >> >> >> it
> >> >> >> > > in
> >> >> >> > > > >>the
> >> >> >> > > > >> Client before, and I'm wondering what people's thoughts
> are
> >> on
> >> >> >> that.
> >> >> >> > > > >>Also,
> >> >> >> > > > >> since these are core pieces of Cordova on Android, this
> may
> >> >> break
> >> >> >> > the
> >> >> >> > > > >> branch, which is fine, but it'd be good if more people
> >> looked
> >> >> at
> >> >> >> > this
> >> >> >> > > > >> branch, and discussed how this should work.
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > > >>
> >> >> >> > > >
> >> >> >> > >
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> >> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> >> >> >> > > > >>
> >> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> >> >> >> > > > >>
> >> >> >> > > > >> Joe
> >> >> >> > > > >>
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> >
> >> >> >>
> >> >>
> >>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Simon MacDonald <si...@gmail.com>.

Installed and it looks like everything worked.

Simon Mac Donald
http://hi.im/simonmacdonald



On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser <bo...@gmail.com> wrote:
> We don't have enough crap Android devices running 2.3.  This is to also
> help us buy devices for the device wall.  The application can be found here:
>
> https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
>
> On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
> <si...@gmail.com>wrote:
>
>> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
>> know when it is up.
>>
>> But wait, isn't this a job for the PhoneGap Device Wall!
>>
>> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>>
>> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > OK, I published a test app on Google Play.  I'll post the link once it
>> > actually shows up.  I want people to download and run it on their Android
>> > 2.3 devices to see if we can find any that crash!  If so, it'll be
>> recorded
>> > in the Error Report.  That way we can finally know is this is a real bug
>> or
>> > something that only exists in the Emulator.
>> >
>> > I'll throw up the code on a repo somewhere as well.  I made sure to use
>> > zero permissions so that it's clear what the app is. (I bet it gets
>> really
>> > crap ratings!).
>> >
>> > Joe
>> >
>> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> +1 science
>> >>
>> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <curtis.bryce@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Yes, I meant providing your own classes that inherit from our
>> >> >> CordovaChrome/WebView classes.
>> >> >>
>> >> >> From what I've observed recently, addJavascriptInterface is still
>> >> broken in
>> >> >> the emulator and on some (maybe small subset) of real phones.
>> >> >>
>> >> >
>> >> > I just tested it on the emulator.  However, I don't think this is an
>> >> issue
>> >> > on real phones.  When they wrote the switch, it was meant to allow
>> >> Android
>> >> > 2.3 to run on crap like the Quench.  So far, I have never seen a phone
>> >> that
>> >> > has less than 256 MB of RAM produced, not even the HTC Wildfire (and
>> that
>> >> > phone sucked!).  I honestly don't think that there's a single Android
>> 2.3
>> >> > phone that has this bug.
>> >> >
>> >> > I think I'm going to release an application to prove this point.  FOR
>> >> > SCIENCE!
>> >> >
>> >> > Joe
>> >> >
>> >> >
>> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com>
>> wrote:
>> >> >>
>> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
>> curtis.bryce@gmail.com
>> >> >> > >wrote:
>> >> >> >
>> >> >> > > I really haven't had time to look at this in detail, but agree
>> that
>> >> >> > > anything related to the webview should be in CordovaWebView.  As
>> Fil
>> >> >> > > mentioned, that includes the history, plugin manager,
>> whitelisting,
>> >> &
>> >> >> > > authentication + callback server.
>> >> >> > >
>> >> >> > > I assume that overriding chrome/view clients so the user can
>> specify
>> >> >> > their
>> >> >> > > own will still work.
>> >> >> > >
>> >> >> > >
>> >> >> > What do you mean overriding Chrome/View clients?  You can use your
>> own
>> >> >> > classes if they inherit from the CordovaChrome class or
>> CordovaWebView
>> >> >> > class, but if you just cram a vanilla WebViewClient or
>> >> WebChromeClient,
>> >> >> > Cordova won't work at all.  This has nothing to do with
>> >> CordovaWebView,
>> >> >> but
>> >> >> > instead is a consequence of the prompt hack that acts as our
>> current
>> >> >> > bridge.  If we want to make it so that we're not dependent on the
>> >> >> > ChromeClient, we should probably bring back addJavascriptInterface
>> and
>> >> >> put
>> >> >> > it in the view itself.
>> >> >> >
>> >> >> > BTW: Does the emulator still break when we do this on Android 2.3?
>>  I
>> >> >> think
>> >> >> > I'll have to look into that.
>> >> >> >
>> >> >> > Joe
>> >> >> >
>> >> >> >
>> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com>
>> wrote:
>> >> >> > >
>> >> >> > > > Sorry for late reply Joe!
>> >> >> > > >
>> >> >> > > > Looks great! As for outstanding issues as per your wiki article
>> >> [1],
>> >> >> I
>> >> >> > > > would say move everything WebView related, as well as
>> >> >> Cordova-specific
>> >> >> > > > such as the plugin manager, into CordovaWebView.java. My
>> thinking
>> >> >> here
>> >> >> > is
>> >> >> > > > that, none of scaffolding necessary to enable device APIs in
>> the
>> >> web
>> >> >> > view
>> >> >> > > > should be a burden on the user - the CordovaWebView class
>> should
>> >> >> handle
>> >> >> > > > all of that.
>> >> >> > > >
>> >> >> > > > It separates the cordova-y bits as something the WEbView needs
>> to
>> >> >> > manage
>> >> >> > > > on its own, as well, and cleans up the final Activity-extending
>> >> class
>> >> >> > to
>> >> >> > > > be simpler. Our end users should not have to worry about that
>> >> stuff,
>> >> >> > nor
>> >> >> > > > do they need to see it in their own activities, or the
>> generated
>> >> >> > > > activities the baseline tooling within cordova-android
>> provides.
>> >> >> > > >
>> >> >> > > > IMO: history, plugin manager, whitelisting, authentication,
>> should
>> >> >> all
>> >> >> > be
>> >> >> > > > handled by CordovaWebView.
>> >> >> > > >
>> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
>> >> >> > > >
>> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>> >> >> > > >
>> >> >> > > > >BUMP! Are we all on board with doing this?
>> >> >> > > > >
>> >> >> > > > >Joe
>> >> >> > > > >
>> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
>> bowserj@gmail.com>
>> >> >> > wrote:
>> >> >> > > > >
>> >> >> > > > >> Hey
>> >> >> > > > >>
>> >> >> > > > >> I've been working on the CordovaWebView branch, and I think
>> we
>> >> >> need
>> >> >> > to
>> >> >> > > > >> discuss where to put the CallbackServer and PluginManager in
>> >> the
>> >> >> new
>> >> >> > > > >> implementation.  I'm OK with it being in the view, but I did
>> >> have
>> >> >> it
>> >> >> > > in
>> >> >> > > > >>the
>> >> >> > > > >> Client before, and I'm wondering what people's thoughts are
>> on
>> >> >> that.
>> >> >> > > > >>Also,
>> >> >> > > > >> since these are core pieces of Cordova on Android, this may
>> >> break
>> >> >> > the
>> >> >> > > > >> branch, which is fine, but it'd be good if more people
>> looked
>> >> at
>> >> >> > this
>> >> >> > > > >> branch, and discussed how this should work.
>> >> >> > > > >>
>> >> >> > > > >>
>> >> >> > > > >>
>> >> >> > > > >>
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
>> >> >> > > > >>
>> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
>> >> >> > > > >>
>> >> >> > > > >> Joe
>> >> >> > > > >>
>> >> >> > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

We don't have enough crap Android devices running 2.3.  This is to also
help us buy devices for the device wall.  The application can be found here:

https://play.google.com/store/apps/details?id=com.infil00p.phoneTest

On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
<si...@gmail.com>wrote:

> Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
> know when it is up.
>
> But wait, isn't this a job for the PhoneGap Device Wall!
>
> http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
>
> On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> > OK, I published a test app on Google Play.  I'll post the link once it
> > actually shows up.  I want people to download and run it on their Android
> > 2.3 devices to see if we can find any that crash!  If so, it'll be
> recorded
> > in the Error Report.  That way we can finally know is this is a real bug
> or
> > something that only exists in the Emulator.
> >
> > I'll throw up the code on a repo somewhere as well.  I made sure to use
> > zero permissions so that it's clear what the app is. (I bet it gets
> really
> > crap ratings!).
> >
> > Joe
> >
> > On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> +1 science
> >>
> >> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <curtis.bryce@gmail.com
> >> >wrote:
> >> >
> >> >> Yes, I meant providing your own classes that inherit from our
> >> >> CordovaChrome/WebView classes.
> >> >>
> >> >> From what I've observed recently, addJavascriptInterface is still
> >> broken in
> >> >> the emulator and on some (maybe small subset) of real phones.
> >> >>
> >> >
> >> > I just tested it on the emulator.  However, I don't think this is an
> >> issue
> >> > on real phones.  When they wrote the switch, it was meant to allow
> >> Android
> >> > 2.3 to run on crap like the Quench.  So far, I have never seen a phone
> >> that
> >> > has less than 256 MB of RAM produced, not even the HTC Wildfire (and
> that
> >> > phone sucked!).  I honestly don't think that there's a single Android
> 2.3
> >> > phone that has this bug.
> >> >
> >> > I think I'm going to release an application to prove this point.  FOR
> >> > SCIENCE!
> >> >
> >> > Joe
> >> >
> >> >
> >> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >> >>
> >> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> curtis.bryce@gmail.com
> >> >> > >wrote:
> >> >> >
> >> >> > > I really haven't had time to look at this in detail, but agree
> that
> >> >> > > anything related to the webview should be in CordovaWebView.  As
> Fil
> >> >> > > mentioned, that includes the history, plugin manager,
> whitelisting,
> >> &
> >> >> > > authentication + callback server.
> >> >> > >
> >> >> > > I assume that overriding chrome/view clients so the user can
> specify
> >> >> > their
> >> >> > > own will still work.
> >> >> > >
> >> >> > >
> >> >> > What do you mean overriding Chrome/View clients?  You can use your
> own
> >> >> > classes if they inherit from the CordovaChrome class or
> CordovaWebView
> >> >> > class, but if you just cram a vanilla WebViewClient or
> >> WebChromeClient,
> >> >> > Cordova won't work at all.  This has nothing to do with
> >> CordovaWebView,
> >> >> but
> >> >> > instead is a consequence of the prompt hack that acts as our
> current
> >> >> > bridge.  If we want to make it so that we're not dependent on the
> >> >> > ChromeClient, we should probably bring back addJavascriptInterface
> and
> >> >> put
> >> >> > it in the view itself.
> >> >> >
> >> >> > BTW: Does the emulator still break when we do this on Android 2.3?
>  I
> >> >> think
> >> >> > I'll have to look into that.
> >> >> >
> >> >> > Joe
> >> >> >
> >> >> >
> >> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com>
> wrote:
> >> >> > >
> >> >> > > > Sorry for late reply Joe!
> >> >> > > >
> >> >> > > > Looks great! As for outstanding issues as per your wiki article
> >> [1],
> >> >> I
> >> >> > > > would say move everything WebView related, as well as
> >> >> Cordova-specific
> >> >> > > > such as the plugin manager, into CordovaWebView.java. My
> thinking
> >> >> here
> >> >> > is
> >> >> > > > that, none of scaffolding necessary to enable device APIs in
> the
> >> web
> >> >> > view
> >> >> > > > should be a burden on the user - the CordovaWebView class
> should
> >> >> handle
> >> >> > > > all of that.
> >> >> > > >
> >> >> > > > It separates the cordova-y bits as something the WEbView needs
> to
> >> >> > manage
> >> >> > > > on its own, as well, and cleans up the final Activity-extending
> >> class
> >> >> > to
> >> >> > > > be simpler. Our end users should not have to worry about that
> >> stuff,
> >> >> > nor
> >> >> > > > do they need to see it in their own activities, or the
> generated
> >> >> > > > activities the baseline tooling within cordova-android
> provides.
> >> >> > > >
> >> >> > > > IMO: history, plugin manager, whitelisting, authentication,
> should
> >> >> all
> >> >> > be
> >> >> > > > handled by CordovaWebView.
> >> >> > > >
> >> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> >> >> > > >
> >> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >> >> > > >
> >> >> > > > >BUMP! Are we all on board with doing this?
> >> >> > > > >
> >> >> > > > >Joe
> >> >> > > > >
> >> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <
> bowserj@gmail.com>
> >> >> > wrote:
> >> >> > > > >
> >> >> > > > >> Hey
> >> >> > > > >>
> >> >> > > > >> I've been working on the CordovaWebView branch, and I think
> we
> >> >> need
> >> >> > to
> >> >> > > > >> discuss where to put the CallbackServer and PluginManager in
> >> the
> >> >> new
> >> >> > > > >> implementation.  I'm OK with it being in the view, but I did
> >> have
> >> >> it
> >> >> > > in
> >> >> > > > >>the
> >> >> > > > >> Client before, and I'm wondering what people's thoughts are
> on
> >> >> that.
> >> >> > > > >>Also,
> >> >> > > > >> since these are core pieces of Cordova on Android, this may
> >> break
> >> >> > the
> >> >> > > > >> branch, which is fine, but it'd be good if more people
> looked
> >> at
> >> >> > this
> >> >> > > > >> branch, and discussed how this should work.
> >> >> > > > >>
> >> >> > > > >>
> >> >> > > > >>
> >> >> > > > >>
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> >> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> >> >> > > > >>
> >> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> >> >> > > > >>
> >> >> > > > >> Joe
> >> >> > > > >>
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Simon MacDonald <si...@gmail.com>.

Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
know when it is up.

But wait, isn't this a job for the PhoneGap Device Wall!

http://phonegap.com/2012/03/29/phonegaps-new-device-wall/

Simon Mac Donald
http://hi.im/simonmacdonald



On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> OK, I published a test app on Google Play.  I'll post the link once it
> actually shows up.  I want people to download and run it on their Android
> 2.3 devices to see if we can find any that crash!  If so, it'll be recorded
> in the Error Report.  That way we can finally know is this is a real bug or
> something that only exists in the Emulator.
>
> I'll throw up the code on a repo somewhere as well.  I made sure to use
> zero permissions so that it's clear what the app is. (I bet it gets really
> crap ratings!).
>
> Joe
>
> On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> +1 science
>>
>> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <curtis.bryce@gmail.com
>> >wrote:
>> >
>> >> Yes, I meant providing your own classes that inherit from our
>> >> CordovaChrome/WebView classes.
>> >>
>> >> From what I've observed recently, addJavascriptInterface is still
>> broken in
>> >> the emulator and on some (maybe small subset) of real phones.
>> >>
>> >
>> > I just tested it on the emulator.  However, I don't think this is an
>> issue
>> > on real phones.  When they wrote the switch, it was meant to allow
>> Android
>> > 2.3 to run on crap like the Quench.  So far, I have never seen a phone
>> that
>> > has less than 256 MB of RAM produced, not even the HTC Wildfire (and that
>> > phone sucked!).  I honestly don't think that there's a single Android 2.3
>> > phone that has this bug.
>> >
>> > I think I'm going to release an application to prove this point.  FOR
>> > SCIENCE!
>> >
>> > Joe
>> >
>> >
>> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >>
>> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com
>> >> > >wrote:
>> >> >
>> >> > > I really haven't had time to look at this in detail, but agree that
>> >> > > anything related to the webview should be in CordovaWebView.  As Fil
>> >> > > mentioned, that includes the history, plugin manager, whitelisting,
>> &
>> >> > > authentication + callback server.
>> >> > >
>> >> > > I assume that overriding chrome/view clients so the user can specify
>> >> > their
>> >> > > own will still work.
>> >> > >
>> >> > >
>> >> > What do you mean overriding Chrome/View clients?  You can use your own
>> >> > classes if they inherit from the CordovaChrome class or CordovaWebView
>> >> > class, but if you just cram a vanilla WebViewClient or
>> WebChromeClient,
>> >> > Cordova won't work at all.  This has nothing to do with
>> CordovaWebView,
>> >> but
>> >> > instead is a consequence of the prompt hack that acts as our current
>> >> > bridge.  If we want to make it so that we're not dependent on the
>> >> > ChromeClient, we should probably bring back addJavascriptInterface and
>> >> put
>> >> > it in the view itself.
>> >> >
>> >> > BTW: Does the emulator still break when we do this on Android 2.3?  I
>> >> think
>> >> > I'll have to look into that.
>> >> >
>> >> > Joe
>> >> >
>> >> >
>> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> > >
>> >> > > > Sorry for late reply Joe!
>> >> > > >
>> >> > > > Looks great! As for outstanding issues as per your wiki article
>> [1],
>> >> I
>> >> > > > would say move everything WebView related, as well as
>> >> Cordova-specific
>> >> > > > such as the plugin manager, into CordovaWebView.java. My thinking
>> >> here
>> >> > is
>> >> > > > that, none of scaffolding necessary to enable device APIs in the
>> web
>> >> > view
>> >> > > > should be a burden on the user - the CordovaWebView class should
>> >> handle
>> >> > > > all of that.
>> >> > > >
>> >> > > > It separates the cordova-y bits as something the WEbView needs to
>> >> > manage
>> >> > > > on its own, as well, and cleans up the final Activity-extending
>> class
>> >> > to
>> >> > > > be simpler. Our end users should not have to worry about that
>> stuff,
>> >> > nor
>> >> > > > do they need to see it in their own activities, or the generated
>> >> > > > activities the baseline tooling within cordova-android provides.
>> >> > > >
>> >> > > > IMO: history, plugin manager, whitelisting, authentication, should
>> >> all
>> >> > be
>> >> > > > handled by CordovaWebView.
>> >> > > >
>> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
>> >> > > >
>> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>> >> > > >
>> >> > > > >BUMP! Are we all on board with doing this?
>> >> > > > >
>> >> > > > >Joe
>> >> > > > >
>> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com>
>> >> > wrote:
>> >> > > > >
>> >> > > > >> Hey
>> >> > > > >>
>> >> > > > >> I've been working on the CordovaWebView branch, and I think we
>> >> need
>> >> > to
>> >> > > > >> discuss where to put the CallbackServer and PluginManager in
>> the
>> >> new
>> >> > > > >> implementation.  I'm OK with it being in the view, but I did
>> have
>> >> it
>> >> > > in
>> >> > > > >>the
>> >> > > > >> Client before, and I'm wondering what people's thoughts are on
>> >> that.
>> >> > > > >>Also,
>> >> > > > >> since these are core pieces of Cordova on Android, this may
>> break
>> >> > the
>> >> > > > >> branch, which is fine, but it'd be good if more people looked
>> at
>> >> > this
>> >> > > > >> branch, and discussed how this should work.
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
>> >> > > > >>
>> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
>> >> > > > >>
>> >> > > > >> Joe
>> >> > > > >>
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Bryce Curtis <cu...@gmail.com>.

Very cool idea, Joe!  Hopefully we will get a good response/sample size
with no failures.

On Thu, Mar 29, 2012 at 7:18 PM, Joe Bowser <bo...@gmail.com> wrote:

> OK, I published a test app on Google Play.  I'll post the link once it
> actually shows up.  I want people to download and run it on their Android
> 2.3 devices to see if we can find any that crash!  If so, it'll be recorded
> in the Error Report.  That way we can finally know is this is a real bug or
> something that only exists in the Emulator.
>
> I'll throw up the code on a repo somewhere as well.  I made sure to use
> zero permissions so that it's clear what the app is. (I bet it gets really
> crap ratings!).
>
> Joe
>
> On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > +1 science
> >
> > On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
> > > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <curtis.bryce@gmail.com
> > >wrote:
> > >
> > >> Yes, I meant providing your own classes that inherit from our
> > >> CordovaChrome/WebView classes.
> > >>
> > >> From what I've observed recently, addJavascriptInterface is still
> > broken in
> > >> the emulator and on some (maybe small subset) of real phones.
> > >>
> > >
> > > I just tested it on the emulator.  However, I don't think this is an
> > issue
> > > on real phones.  When they wrote the switch, it was meant to allow
> > Android
> > > 2.3 to run on crap like the Quench.  So far, I have never seen a phone
> > that
> > > has less than 256 MB of RAM produced, not even the HTC Wildfire (and
> that
> > > phone sucked!).  I honestly don't think that there's a single Android
> 2.3
> > > phone that has this bug.
> > >
> > > I think I'm going to release an application to prove this point.  FOR
> > > SCIENCE!
> > >
> > > Joe
> > >
> > >
> > >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> > >>
> > >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <
> curtis.bryce@gmail.com
> > >> > >wrote:
> > >> >
> > >> > > I really haven't had time to look at this in detail, but agree
> that
> > >> > > anything related to the webview should be in CordovaWebView.  As
> Fil
> > >> > > mentioned, that includes the history, plugin manager,
> whitelisting,
> > &
> > >> > > authentication + callback server.
> > >> > >
> > >> > > I assume that overriding chrome/view clients so the user can
> specify
> > >> > their
> > >> > > own will still work.
> > >> > >
> > >> > >
> > >> > What do you mean overriding Chrome/View clients?  You can use your
> own
> > >> > classes if they inherit from the CordovaChrome class or
> CordovaWebView
> > >> > class, but if you just cram a vanilla WebViewClient or
> > WebChromeClient,
> > >> > Cordova won't work at all.  This has nothing to do with
> > CordovaWebView,
> > >> but
> > >> > instead is a consequence of the prompt hack that acts as our current
> > >> > bridge.  If we want to make it so that we're not dependent on the
> > >> > ChromeClient, we should probably bring back addJavascriptInterface
> and
> > >> put
> > >> > it in the view itself.
> > >> >
> > >> > BTW: Does the emulator still break when we do this on Android 2.3?
>  I
> > >> think
> > >> > I'll have to look into that.
> > >> >
> > >> > Joe
> > >> >
> > >> >
> > >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
> > >> > >
> > >> > > > Sorry for late reply Joe!
> > >> > > >
> > >> > > > Looks great! As for outstanding issues as per your wiki article
> > [1],
> > >> I
> > >> > > > would say move everything WebView related, as well as
> > >> Cordova-specific
> > >> > > > such as the plugin manager, into CordovaWebView.java. My
> thinking
> > >> here
> > >> > is
> > >> > > > that, none of scaffolding necessary to enable device APIs in the
> > web
> > >> > view
> > >> > > > should be a burden on the user - the CordovaWebView class should
> > >> handle
> > >> > > > all of that.
> > >> > > >
> > >> > > > It separates the cordova-y bits as something the WEbView needs
> to
> > >> > manage
> > >> > > > on its own, as well, and cleans up the final Activity-extending
> > class
> > >> > to
> > >> > > > be simpler. Our end users should not have to worry about that
> > stuff,
> > >> > nor
> > >> > > > do they need to see it in their own activities, or the generated
> > >> > > > activities the baseline tooling within cordova-android provides.
> > >> > > >
> > >> > > > IMO: history, plugin manager, whitelisting, authentication,
> should
> > >> all
> > >> > be
> > >> > > > handled by CordovaWebView.
> > >> > > >
> > >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > >> > > >
> > >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > >> > > >
> > >> > > > >BUMP! Are we all on board with doing this?
> > >> > > > >
> > >> > > > >Joe
> > >> > > > >
> > >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bowserj@gmail.com
> >
> > >> > wrote:
> > >> > > > >
> > >> > > > >> Hey
> > >> > > > >>
> > >> > > > >> I've been working on the CordovaWebView branch, and I think
> we
> > >> need
> > >> > to
> > >> > > > >> discuss where to put the CallbackServer and PluginManager in
> > the
> > >> new
> > >> > > > >> implementation.  I'm OK with it being in the view, but I did
> > have
> > >> it
> > >> > > in
> > >> > > > >>the
> > >> > > > >> Client before, and I'm wondering what people's thoughts are
> on
> > >> that.
> > >> > > > >>Also,
> > >> > > > >> since these are core pieces of Cordova on Android, this may
> > break
> > >> > the
> > >> > > > >> branch, which is fine, but it'd be good if more people looked
> > at
> > >> > this
> > >> > > > >> branch, and discussed how this should work.
> > >> > > > >>
> > >> > > > >>
> > >> > > > >>
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > >> > > > >>
> > >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > >> > > > >>
> > >> > > > >> Joe
> > >> > > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

OK, I published a test app on Google Play.  I'll post the link once it
actually shows up.  I want people to download and run it on their Android
2.3 devices to see if we can find any that crash!  If so, it'll be recorded
in the Error Report.  That way we can finally know is this is a real bug or
something that only exists in the Emulator.

I'll throw up the code on a repo somewhere as well.  I made sure to use
zero permissions so that it's clear what the app is. (I bet it gets really
crap ratings!).

Joe

On Thu, Mar 29, 2012 at 4:46 PM, Brian LeRoux <b...@brian.io> wrote:

> +1 science
>
> On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
> > On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <curtis.bryce@gmail.com
> >wrote:
> >
> >> Yes, I meant providing your own classes that inherit from our
> >> CordovaChrome/WebView classes.
> >>
> >> From what I've observed recently, addJavascriptInterface is still
> broken in
> >> the emulator and on some (maybe small subset) of real phones.
> >>
> >
> > I just tested it on the emulator.  However, I don't think this is an
> issue
> > on real phones.  When they wrote the switch, it was meant to allow
> Android
> > 2.3 to run on crap like the Quench.  So far, I have never seen a phone
> that
> > has less than 256 MB of RAM produced, not even the HTC Wildfire (and that
> > phone sucked!).  I honestly don't think that there's a single Android 2.3
> > phone that has this bug.
> >
> > I think I'm going to release an application to prove this point.  FOR
> > SCIENCE!
> >
> > Joe
> >
> >
> >> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com> wrote:
> >>
> >> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com
> >> > >wrote:
> >> >
> >> > > I really haven't had time to look at this in detail, but agree that
> >> > > anything related to the webview should be in CordovaWebView.  As Fil
> >> > > mentioned, that includes the history, plugin manager, whitelisting,
> &
> >> > > authentication + callback server.
> >> > >
> >> > > I assume that overriding chrome/view clients so the user can specify
> >> > their
> >> > > own will still work.
> >> > >
> >> > >
> >> > What do you mean overriding Chrome/View clients?  You can use your own
> >> > classes if they inherit from the CordovaChrome class or CordovaWebView
> >> > class, but if you just cram a vanilla WebViewClient or
> WebChromeClient,
> >> > Cordova won't work at all.  This has nothing to do with
> CordovaWebView,
> >> but
> >> > instead is a consequence of the prompt hack that acts as our current
> >> > bridge.  If we want to make it so that we're not dependent on the
> >> > ChromeClient, we should probably bring back addJavascriptInterface and
> >> put
> >> > it in the view itself.
> >> >
> >> > BTW: Does the emulator still break when we do this on Android 2.3?  I
> >> think
> >> > I'll have to look into that.
> >> >
> >> > Joe
> >> >
> >> >
> >> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
> >> > >
> >> > > > Sorry for late reply Joe!
> >> > > >
> >> > > > Looks great! As for outstanding issues as per your wiki article
> [1],
> >> I
> >> > > > would say move everything WebView related, as well as
> >> Cordova-specific
> >> > > > such as the plugin manager, into CordovaWebView.java. My thinking
> >> here
> >> > is
> >> > > > that, none of scaffolding necessary to enable device APIs in the
> web
> >> > view
> >> > > > should be a burden on the user - the CordovaWebView class should
> >> handle
> >> > > > all of that.
> >> > > >
> >> > > > It separates the cordova-y bits as something the WEbView needs to
> >> > manage
> >> > > > on its own, as well, and cleans up the final Activity-extending
> class
> >> > to
> >> > > > be simpler. Our end users should not have to worry about that
> stuff,
> >> > nor
> >> > > > do they need to see it in their own activities, or the generated
> >> > > > activities the baseline tooling within cordova-android provides.
> >> > > >
> >> > > > IMO: history, plugin manager, whitelisting, authentication, should
> >> all
> >> > be
> >> > > > handled by CordovaWebView.
> >> > > >
> >> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> >> > > >
> >> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >> > > >
> >> > > > >BUMP! Are we all on board with doing this?
> >> > > > >
> >> > > > >Joe
> >> > > > >
> >> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > >> Hey
> >> > > > >>
> >> > > > >> I've been working on the CordovaWebView branch, and I think we
> >> need
> >> > to
> >> > > > >> discuss where to put the CallbackServer and PluginManager in
> the
> >> new
> >> > > > >> implementation.  I'm OK with it being in the view, but I did
> have
> >> it
> >> > > in
> >> > > > >>the
> >> > > > >> Client before, and I'm wondering what people's thoughts are on
> >> that.
> >> > > > >>Also,
> >> > > > >> since these are core pieces of Cordova on Android, this may
> break
> >> > the
> >> > > > >> branch, which is fine, but it'd be good if more people looked
> at
> >> > this
> >> > > > >> branch, and discussed how this should work.
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> >> > > > >>=shortlog;h=refs/heads/CordovaWebView
> >> > > > >>
> >> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> >> > > > >>
> >> > > > >> Joe
> >> > > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Brian LeRoux <b...@brian.io>.

+1 science

On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <cu...@gmail.com>wrote:
>
>> Yes, I meant providing your own classes that inherit from our
>> CordovaChrome/WebView classes.
>>
>> From what I've observed recently, addJavascriptInterface is still broken in
>> the emulator and on some (maybe small subset) of real phones.
>>
>
> I just tested it on the emulator.  However, I don't think this is an issue
> on real phones.  When they wrote the switch, it was meant to allow Android
> 2.3 to run on crap like the Quench.  So far, I have never seen a phone that
> has less than 256 MB of RAM produced, not even the HTC Wildfire (and that
> phone sucked!).  I honestly don't think that there's a single Android 2.3
> phone that has this bug.
>
> I think I'm going to release an application to prove this point.  FOR
> SCIENCE!
>
> Joe
>
>
>> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com
>> > >wrote:
>> >
>> > > I really haven't had time to look at this in detail, but agree that
>> > > anything related to the webview should be in CordovaWebView.  As Fil
>> > > mentioned, that includes the history, plugin manager, whitelisting, &
>> > > authentication + callback server.
>> > >
>> > > I assume that overriding chrome/view clients so the user can specify
>> > their
>> > > own will still work.
>> > >
>> > >
>> > What do you mean overriding Chrome/View clients?  You can use your own
>> > classes if they inherit from the CordovaChrome class or CordovaWebView
>> > class, but if you just cram a vanilla WebViewClient or WebChromeClient,
>> > Cordova won't work at all.  This has nothing to do with CordovaWebView,
>> but
>> > instead is a consequence of the prompt hack that acts as our current
>> > bridge.  If we want to make it so that we're not dependent on the
>> > ChromeClient, we should probably bring back addJavascriptInterface and
>> put
>> > it in the view itself.
>> >
>> > BTW: Does the emulator still break when we do this on Android 2.3?  I
>> think
>> > I'll have to look into that.
>> >
>> > Joe
>> >
>> >
>> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >
>> > > > Sorry for late reply Joe!
>> > > >
>> > > > Looks great! As for outstanding issues as per your wiki article [1],
>> I
>> > > > would say move everything WebView related, as well as
>> Cordova-specific
>> > > > such as the plugin manager, into CordovaWebView.java. My thinking
>> here
>> > is
>> > > > that, none of scaffolding necessary to enable device APIs in the web
>> > view
>> > > > should be a burden on the user - the CordovaWebView class should
>> handle
>> > > > all of that.
>> > > >
>> > > > It separates the cordova-y bits as something the WEbView needs to
>> > manage
>> > > > on its own, as well, and cleans up the final Activity-extending class
>> > to
>> > > > be simpler. Our end users should not have to worry about that stuff,
>> > nor
>> > > > do they need to see it in their own activities, or the generated
>> > > > activities the baseline tooling within cordova-android provides.
>> > > >
>> > > > IMO: history, plugin manager, whitelisting, authentication, should
>> all
>> > be
>> > > > handled by CordovaWebView.
>> > > >
>> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
>> > > >
>> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>> > > >
>> > > > >BUMP! Are we all on board with doing this?
>> > > > >
>> > > > >Joe
>> > > > >
>> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com>
>> > wrote:
>> > > > >
>> > > > >> Hey
>> > > > >>
>> > > > >> I've been working on the CordovaWebView branch, and I think we
>> need
>> > to
>> > > > >> discuss where to put the CallbackServer and PluginManager in the
>> new
>> > > > >> implementation.  I'm OK with it being in the view, but I did have
>> it
>> > > in
>> > > > >>the
>> > > > >> Client before, and I'm wondering what people's thoughts are on
>> that.
>> > > > >>Also,
>> > > > >> since these are core pieces of Cordova on Android, this may break
>> > the
>> > > > >> branch, which is fine, but it'd be good if more people looked at
>> > this
>> > > > >> branch, and discussed how this should work.
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > >
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>> > > > >>=shortlog;h=refs/heads/CordovaWebView
>> > > > >>
>> > > > >> http://wiki.apache.org/cordova/CordovaWebView
>> > > > >>
>> > > > >> Joe
>> > > > >>
>> > > >
>> > > >
>> > >
>> >
>>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis <cu...@gmail.com>wrote:

> Yes, I meant providing your own classes that inherit from our
> CordovaChrome/WebView classes.
>
> From what I've observed recently, addJavascriptInterface is still broken in
> the emulator and on some (maybe small subset) of real phones.
>

I just tested it on the emulator.  However, I don't think this is an issue
on real phones.  When they wrote the switch, it was meant to allow Android
2.3 to run on crap like the Quench.  So far, I have never seen a phone that
has less than 256 MB of RAM produced, not even the HTC Wildfire (and that
phone sucked!).  I honestly don't think that there's a single Android 2.3
phone that has this bug.

I think I'm going to release an application to prove this point.  FOR
SCIENCE!

Joe


> On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com
> > >wrote:
> >
> > > I really haven't had time to look at this in detail, but agree that
> > > anything related to the webview should be in CordovaWebView.  As Fil
> > > mentioned, that includes the history, plugin manager, whitelisting, &
> > > authentication + callback server.
> > >
> > > I assume that overriding chrome/view clients so the user can specify
> > their
> > > own will still work.
> > >
> > >
> > What do you mean overriding Chrome/View clients?  You can use your own
> > classes if they inherit from the CordovaChrome class or CordovaWebView
> > class, but if you just cram a vanilla WebViewClient or WebChromeClient,
> > Cordova won't work at all.  This has nothing to do with CordovaWebView,
> but
> > instead is a consequence of the prompt hack that acts as our current
> > bridge.  If we want to make it so that we're not dependent on the
> > ChromeClient, we should probably bring back addJavascriptInterface and
> put
> > it in the view itself.
> >
> > BTW: Does the emulator still break when we do this on Android 2.3?  I
> think
> > I'll have to look into that.
> >
> > Joe
> >
> >
> > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > > > Sorry for late reply Joe!
> > > >
> > > > Looks great! As for outstanding issues as per your wiki article [1],
> I
> > > > would say move everything WebView related, as well as
> Cordova-specific
> > > > such as the plugin manager, into CordovaWebView.java. My thinking
> here
> > is
> > > > that, none of scaffolding necessary to enable device APIs in the web
> > view
> > > > should be a burden on the user - the CordovaWebView class should
> handle
> > > > all of that.
> > > >
> > > > It separates the cordova-y bits as something the WEbView needs to
> > manage
> > > > on its own, as well, and cleans up the final Activity-extending class
> > to
> > > > be simpler. Our end users should not have to worry about that stuff,
> > nor
> > > > do they need to see it in their own activities, or the generated
> > > > activities the baseline tooling within cordova-android provides.
> > > >
> > > > IMO: history, plugin manager, whitelisting, authentication, should
> all
> > be
> > > > handled by CordovaWebView.
> > > >
> > > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > > >
> > > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > > >
> > > > >BUMP! Are we all on board with doing this?
> > > > >
> > > > >Joe
> > > > >
> > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > > > >
> > > > >> Hey
> > > > >>
> > > > >> I've been working on the CordovaWebView branch, and I think we
> need
> > to
> > > > >> discuss where to put the CallbackServer and PluginManager in the
> new
> > > > >> implementation.  I'm OK with it being in the view, but I did have
> it
> > > in
> > > > >>the
> > > > >> Client before, and I'm wondering what people's thoughts are on
> that.
> > > > >>Also,
> > > > >> since these are core pieces of Cordova on Android, this may break
> > the
> > > > >> branch, which is fine, but it'd be good if more people looked at
> > this
> > > > >> branch, and discussed how this should work.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > > > >>=shortlog;h=refs/heads/CordovaWebView
> > > > >>
> > > > >> http://wiki.apache.org/cordova/CordovaWebView
> > > > >>
> > > > >> Joe
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Bryce Curtis <cu...@gmail.com>.

Yes, I meant providing your own classes that inherit from our
CordovaChrome/WebView classes.

>From what I've observed recently, addJavascriptInterface is still broken in
the emulator and on some (maybe small subset) of real phones.

On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com
> >wrote:
>
> > I really haven't had time to look at this in detail, but agree that
> > anything related to the webview should be in CordovaWebView.  As Fil
> > mentioned, that includes the history, plugin manager, whitelisting, &
> > authentication + callback server.
> >
> > I assume that overriding chrome/view clients so the user can specify
> their
> > own will still work.
> >
> >
> What do you mean overriding Chrome/View clients?  You can use your own
> classes if they inherit from the CordovaChrome class or CordovaWebView
> class, but if you just cram a vanilla WebViewClient or WebChromeClient,
> Cordova won't work at all.  This has nothing to do with CordovaWebView, but
> instead is a consequence of the prompt hack that acts as our current
> bridge.  If we want to make it so that we're not dependent on the
> ChromeClient, we should probably bring back addJavascriptInterface and put
> it in the view itself.
>
> BTW: Does the emulator still break when we do this on Android 2.3?  I think
> I'll have to look into that.
>
> Joe
>
>
> > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > > Sorry for late reply Joe!
> > >
> > > Looks great! As for outstanding issues as per your wiki article [1], I
> > > would say move everything WebView related, as well as Cordova-specific
> > > such as the plugin manager, into CordovaWebView.java. My thinking here
> is
> > > that, none of scaffolding necessary to enable device APIs in the web
> view
> > > should be a burden on the user - the CordovaWebView class should handle
> > > all of that.
> > >
> > > It separates the cordova-y bits as something the WEbView needs to
> manage
> > > on its own, as well, and cleans up the final Activity-extending class
> to
> > > be simpler. Our end users should not have to worry about that stuff,
> nor
> > > do they need to see it in their own activities, or the generated
> > > activities the baseline tooling within cordova-android provides.
> > >
> > > IMO: history, plugin manager, whitelisting, authentication, should all
> be
> > > handled by CordovaWebView.
> > >
> > > [1] http://wiki.apache.org/cordova/CordovaWebView
> > >
> > > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > >
> > > >BUMP! Are we all on board with doing this?
> > > >
> > > >Joe
> > > >
> > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> > > >
> > > >> Hey
> > > >>
> > > >> I've been working on the CordovaWebView branch, and I think we need
> to
> > > >> discuss where to put the CallbackServer and PluginManager in the new
> > > >> implementation.  I'm OK with it being in the view, but I did have it
> > in
> > > >>the
> > > >> Client before, and I'm wondering what people's thoughts are on that.
> > > >>Also,
> > > >> since these are core pieces of Cordova on Android, this may break
> the
> > > >> branch, which is fine, but it'd be good if more people looked at
> this
> > > >> branch, and discussed how this should work.
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > > >>=shortlog;h=refs/heads/CordovaWebView
> > > >>
> > > >> http://wiki.apache.org/cordova/CordovaWebView
> > > >>
> > > >> Joe
> > > >>
> > >
> > >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <cu...@gmail.com>wrote:

> I really haven't had time to look at this in detail, but agree that
> anything related to the webview should be in CordovaWebView.  As Fil
> mentioned, that includes the history, plugin manager, whitelisting, &
> authentication + callback server.
>
> I assume that overriding chrome/view clients so the user can specify their
> own will still work.
>
>
What do you mean overriding Chrome/View clients?  You can use your own
classes if they inherit from the CordovaChrome class or CordovaWebView
class, but if you just cram a vanilla WebViewClient or WebChromeClient,
Cordova won't work at all.  This has nothing to do with CordovaWebView, but
instead is a consequence of the prompt hack that acts as our current
bridge.  If we want to make it so that we're not dependent on the
ChromeClient, we should probably bring back addJavascriptInterface and put
it in the view itself.

BTW: Does the emulator still break when we do this on Android 2.3?  I think
I'll have to look into that.

Joe


> On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > Sorry for late reply Joe!
> >
> > Looks great! As for outstanding issues as per your wiki article [1], I
> > would say move everything WebView related, as well as Cordova-specific
> > such as the plugin manager, into CordovaWebView.java. My thinking here is
> > that, none of scaffolding necessary to enable device APIs in the web view
> > should be a burden on the user - the CordovaWebView class should handle
> > all of that.
> >
> > It separates the cordova-y bits as something the WEbView needs to manage
> > on its own, as well, and cleans up the final Activity-extending class to
> > be simpler. Our end users should not have to worry about that stuff, nor
> > do they need to see it in their own activities, or the generated
> > activities the baseline tooling within cordova-android provides.
> >
> > IMO: history, plugin manager, whitelisting, authentication, should all be
> > handled by CordovaWebView.
> >
> > [1] http://wiki.apache.org/cordova/CordovaWebView
> >
> > On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >
> > >BUMP! Are we all on board with doing this?
> > >
> > >Joe
> > >
> > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > >> Hey
> > >>
> > >> I've been working on the CordovaWebView branch, and I think we need to
> > >> discuss where to put the CallbackServer and PluginManager in the new
> > >> implementation.  I'm OK with it being in the view, but I did have it
> in
> > >>the
> > >> Client before, and I'm wondering what people's thoughts are on that.
> > >>Also,
> > >> since these are core pieces of Cordova on Android, this may break the
> > >> branch, which is fine, but it'd be good if more people looked at this
> > >> branch, and discussed how this should work.
> > >>
> > >>
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> > >>=shortlog;h=refs/heads/CordovaWebView
> > >>
> > >> http://wiki.apache.org/cordova/CordovaWebView
> > >>
> > >> Joe
> > >>
> >
> >
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Bryce Curtis <cu...@gmail.com>.

I really haven't had time to look at this in detail, but agree that
anything related to the webview should be in CordovaWebView.  As Fil
mentioned, that includes the history, plugin manager, whitelisting, &
authentication + callback server.

I assume that overriding chrome/view clients so the user can specify their
own will still work.

On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <fi...@adobe.com> wrote:

> Sorry for late reply Joe!
>
> Looks great! As for outstanding issues as per your wiki article [1], I
> would say move everything WebView related, as well as Cordova-specific
> such as the plugin manager, into CordovaWebView.java. My thinking here is
> that, none of scaffolding necessary to enable device APIs in the web view
> should be a burden on the user - the CordovaWebView class should handle
> all of that.
>
> It separates the cordova-y bits as something the WEbView needs to manage
> on its own, as well, and cleans up the final Activity-extending class to
> be simpler. Our end users should not have to worry about that stuff, nor
> do they need to see it in their own activities, or the generated
> activities the baseline tooling within cordova-android provides.
>
> IMO: history, plugin manager, whitelisting, authentication, should all be
> handled by CordovaWebView.
>
> [1] http://wiki.apache.org/cordova/CordovaWebView
>
> On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>
> >BUMP! Are we all on board with doing this?
> >
> >Joe
> >
> >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> Hey
> >>
> >> I've been working on the CordovaWebView branch, and I think we need to
> >> discuss where to put the CallbackServer and PluginManager in the new
> >> implementation.  I'm OK with it being in the view, but I did have it in
> >>the
> >> Client before, and I'm wondering what people's thoughts are on that.
> >>Also,
> >> since these are core pieces of Cordova on Android, this may break the
> >> branch, which is fine, but it'd be good if more people looked at this
> >> branch, and discussed how this should work.
> >>
> >>
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
> >>=shortlog;h=refs/heads/CordovaWebView
> >>
> >> http://wiki.apache.org/cordova/CordovaWebView
> >>
> >> Joe
> >>
>
>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Filip Maj <fi...@adobe.com>.

Sorry for late reply Joe!

Looks great! As for outstanding issues as per your wiki article [1], I
would say move everything WebView related, as well as Cordova-specific
such as the plugin manager, into CordovaWebView.java. My thinking here is
that, none of scaffolding necessary to enable device APIs in the web view
should be a burden on the user - the CordovaWebView class should handle
all of that.

It separates the cordova-y bits as something the WEbView needs to manage
on its own, as well, and cleans up the final Activity-extending class to
be simpler. Our end users should not have to worry about that stuff, nor
do they need to see it in their own activities, or the generated
activities the baseline tooling within cordova-android provides.

IMO: history, plugin manager, whitelisting, authentication, should all be
handled by CordovaWebView.

[1] http://wiki.apache.org/cordova/CordovaWebView

On 3/28/12 4:06 PM, "Joe Bowser" <bo...@gmail.com> wrote:

>BUMP! Are we all on board with doing this?
>
>Joe
>
>On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> Hey
>>
>> I've been working on the CordovaWebView branch, and I think we need to
>> discuss where to put the CallbackServer and PluginManager in the new
>> implementation.  I'm OK with it being in the view, but I did have it in
>>the
>> Client before, and I'm wondering what people's thoughts are on that.
>>Also,
>> since these are core pieces of Cordova on Android, this may break the
>> branch, which is fine, but it'd be good if more people looked at this
>> branch, and discussed how this should work.
>>
>>
>> 
>>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a
>>=shortlog;h=refs/heads/CordovaWebView
>>
>> http://wiki.apache.org/cordova/CordovaWebView
>>
>> Joe
>>

Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap

Posted by Joe Bowser <bo...@gmail.com>.

BUMP! Are we all on board with doing this?

Joe

On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bo...@gmail.com> wrote:

> Hey
>
> I've been working on the CordovaWebView branch, and I think we need to
> discuss where to put the CallbackServer and PluginManager in the new
> implementation.  I'm OK with it being in the view, but I did have it in the
> Client before, and I'm wondering what people's thoughts are on that.  Also,
> since these are core pieces of Cordova on Android, this may break the
> branch, which is fine, but it'd be good if more people looked at this
> branch, and discussed how this should work.
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=shortlog;h=refs/heads/CordovaWebView
>
> http://wiki.apache.org/cordova/CordovaWebView
>
> Joe
>