Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ios): Change CAPBridgeViewController class access to open #1972

Closed
wants to merge 1 commit into from

Conversation

playerx
Copy link

@playerx playerx commented Sep 17, 2019

Motivation:

I need to create new child class CustomCAPBridgeViewController from CAPBridgeViewController to extend its functionality. In my case I need to override viewWillTransition

Problem:

When I created new CustomCAPBridgeViewController and inherited it from CAPBridgeViewController I got error from xcode. It seems that if you want to inherit class it should be declared as open (this change was introduced in Swift 3)

Sources:

@jcesarmobile
Copy link
Member

I'm not really sure if we want people to subclass CAPBridgeViewController.

For extending it you can create an extension like this:

import Capacitor

extension CAPBridgeViewController {
    override public func viewWillTransition(to size: CGSize,
                            with coordinator: UIViewControllerTransitionCoordinator) {
        print("view will transition")
    }
}

@jcesarmobile
Copy link
Member

Will close for now as the extension is enough for the use case.

Might reconsider in the future if we find a real use case for subclassing CAPBridgeViewController that can't be done with an extension.

@codeincontext
Copy link

In my case I need access to webView(_ webView: WKWebView, didFailProvisionalNavigation navigation: WKNavigation!, withError error: Error). I'm not the best with swift but I see the following options:

  • Fork capacitor for the time being
  • Capacitor gets an API to forward WKNavigationDelegate methods
  • Capacitor opens CAPBridgeViewController and WKNavigationDelegate methods
  • Swizzling?

For now I'm going to open up CAPBridgeViewController locally and subclass in my project

@fkirc
Copy link
Contributor

fkirc commented Aug 27, 2020

I believe that subclassing is helpful for "embedded capacitor".

In my app, I have two different CAPBridgeViewController's for two different features of the app.
Furthermore, I have a custom plugin that behaves differently depending on which CAPBridgeViewController is currently shown.
It would be helpful to subclass CAPBridgeViewController in order to customize this behavior at runtime.

Note that a simple extension like above does not work for my case because I want to differentiate between different kinds of CAPBridgeViewControllers.

Overally, I believe that "embedded capacitor" is still missing some features and helper functions (e.g. configure a URL postfix dynamically).
Moreover, I believe that more openness is the only short-term action that makes embedded capacitor possible (except of forking or code-copying, which are cumbersome ways of openness).

Therefore, do you consider to re-open and merge this PR?
There will always be multiple ways to solve the same problem, but my point is that customizing Capacitor should be made as easy as possible. I fully understand that you cannot take every PR, but this is a very lightweight change that has a high demand for different use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants