On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie <[email protected]> wrote:
> > First is that there is no way to use a custom WebView / WebViewClient / > > ChromeClient class within the CLI system, without writing custom native > > code after your project has been created. > > Not sure about the CLI system, don't really use it. Call me old school but > I love my jars 'n frameworks. There is of course another reason for this; > Cordova is very much a framework for me, NOT a platform. I think it's > crucial to remember there are many reasons to use Cordova in a project, it > can often be just as a means to get a little extra accessibility and > browser standardisation out of the WebView. The rest of the app could be > 80% native with heaps of other SDKs... > That is absolutely a valid use of Cordova, and underscores the point that the tools which underlie CLI should be even more stable than CLI itself. (Which I think is true right now) If you're using Cordova in that way, then most of this discussion wouldn't even apply -- your start-of-project flow can just be "cordova-android/bin/create newproject com.example.newproject", and then you can start editing (or just throw away) the default Activity class. Nothing here is going to get in the way of that. > > >For Mobile Chrome Apps, we have a need to subclass the CordovaChromeClient > >class used by our applications. There's not currently a way to do that in > >the CLI world > > Ian, I know you are using CLI, but IF you were not, you would subclass > CordovaChromeClient on your application's main Activity?? I see no sensible > way to do it on a Plugin without going thread crazy... I can separate a > thread if you want to keep this CLI related, but I feel the plugin > developer use case should be considered in this thread too. > The only reason I can imagine for me not to use CLI would be if I was creating a single-platform application, for which I knew that I was going to be making a lot of native code modifications. In that case, I would absolutely introduce my own subclass of CordovaChromeClient, and import it in my main Activity, and override init() to create the right objects. But that only works for my application; it doesn't give me anything that I can share with other developers without also instructing them to modify their code in the same way. There's no way right now to encapsulate this sort of change in a plugin. The CordovaWebView/Client/ChromeClient are necessarily singletons, and it's probably not a good idea to allow plugins to arbitrarily replace them. We could conceivably come up with a new sort of plugin that can do it -- and you could only install one such plugin per project -- but people could also just distribute custom app templates which do pretty much the same thing. > > I'm 100% hopeful that at a minimum more methods (WebView and WebViewCient) > can be exposed to the Plugins. > For individual methods, right now lets just name them specifically, and we can add delegation to the plugins for them. Later, I think we can move to a generic registration / notification architecture, once we have a good design for that. I've heard calls for: - disableTouchEvents - registerGestureHandler - onReceivedHttpAuthRequest - getHttpAuthUsernamePassword We can create some issues for those, and get them implemented. Ian
