WP8 Plugin Architecture & Access to CordovaView

[Dan Polivy <da...@busstop.org>]

Hello,

I'm fairly new to Cordova, but so far have found it pretty easy to get my existing mobile website up and running as an app using various native components. Thanks for all of your work to get to this point! As I progress in my development, I find myself with an architectural/dev question about the framework that I'd appreciate hearing your input on.

At the moment, I am focused on the WP8 and iOS versions of my app. For plugins, I've noticed that the iOS CDVPlugin class contains a reference to the main UIWebView, the Android CordovaPlugin class gets the CordovaInterface and CordovaWebView references, but on the WP8 side, the BaseCommand class seems fairly well isolated from the corresponding CordovaView. I have a scenario using the FileTransfer plugin which requires the WebRequest to utilize the same cookies as the main WebBrowser for my file transfer to succeed. I believe I can make this work by setting the WebRequest.CookieContainer = WebBrowser.GetCookies() (pseudo-code) - but getting access to the WebBrowser from the plugin seems difficult the way things are.

I was going to look at plumbing the CordovaView through to the BaseCommand class, similar to how it's done on the iOS side, and submit a pull request to the cordova-wp8 repo when I'm done. But first, I wanted to check with you to see if this was a terrible idea, or if you had any better suggestions on how to implement this? I'd much prefer to give something back than hack a one-off solution for myself.

Thanks,
Dan

Re: WP8 Plugin Architecture & Access to CordovaView

[Jesse <pu...@gmail.com>]

This is by design, to prevent every plugin from pumping its own cruft into
the DOM.
However, there are some cases where it is required, and I am considering
some achitecture changes to make this easier.

In the meantime, you can get a reference to the Cordova WebBrowser like
this:

Deployment.Current.Dispatcher.BeginInvoke(() =>
{
    PhoneApplicationFrame frame = Application.Current.RootVisual as
PhoneApplicationFrame;
    if (frame != null)
    {
        PhoneApplicationPage page = frame.Content as PhoneApplicationPage;
        if (page != null)
        {
            CordovaView cView = page.FindName("CordovaView") as CordovaView;
            if (cView != null)
            {
                WebBrowser br = cView.Browser;
                // do something with the cordova browser.
            }
        }
    }
});





@purplecabbage
risingj.com


On Wed, Mar 19, 2014 at 6:27 PM, Dan Polivy <da...@busstop.org> wrote:

> Hello,
>
> I'm fairly new to Cordova, but so far have found it pretty easy to get my
> existing mobile website up and running as an app using various native
> components. Thanks for all of your work to get to this point! As I progress
> in my development, I find myself with an architectural/dev question about
> the framework that I'd appreciate hearing your input on.
>
> At the moment, I am focused on the WP8 and iOS versions of my app. For
> plugins, I've noticed that the iOS CDVPlugin class contains a reference to
> the main UIWebView, the Android CordovaPlugin class gets the
> CordovaInterface and CordovaWebView references, but on the WP8 side, the
> BaseCommand class seems fairly well isolated from the corresponding
> CordovaView. I have a scenario using the FileTransfer plugin which requires
> the WebRequest to utilize the same cookies as the main WebBrowser for my
> file transfer to succeed. I believe I can make this work by setting the
> WebRequest.CookieContainer = WebBrowser.GetCookies() (pseudo-code) - but
> getting access to the WebBrowser from the plugin seems difficult the way
> things are.
>
> I was going to look at plumbing the CordovaView through to the BaseCommand
> class, similar to how it's done on the iOS side, and submit a pull request
> to the cordova-wp8 repo when I'm done. But first, I wanted to check with
> you to see if this was a terrible idea, or if you had any better
> suggestions on how to implement this? I'd much prefer to give something
> back than hack a one-off solution for myself.
>
> Thanks,
> Dan
>