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

feat(ios): Plugin Registration and Plugin Instance Support #6072

Merged
merged 7 commits into from
Nov 22, 2022

Conversation

Steven0351
Copy link
Member

feat(ios): Adds support for manual registration for plugins and the ability to register instances of plugins so that plugins can be instantiated by the user instead of relying on the bridge.

ability to register instances of plugins so that plugins can be
instantiated by the user instead of relying on the bridge.
@Steven0351
Copy link
Member Author

Steven0351 commented Nov 11, 2022

This is an effort to solve problems we see in Portals as we now have customers using Capacitor with new use cases:

  1. Being able to isolate what plugins are available to the Capacitor runtime. As it exists today, all plugins visible to Objective-C are auto-registered, which may not be desirable if multiple Capacitor instances are running in an application. This provides users the ability to explicitly decide what native functionality a Capacitor application has (similar to Android today).
  2. Being able to control when and how a plugin is initialized. Capacitor plugins are now being used in cases where they may need to participate in the business logic of the native application. This is in contrast to the more traditional role they take in providing access to native API's through a web interface. This allows allows for plugins that are purpose built for participating in the programming paradigms of the native application.

All of these features are additive and do not affect status quo Capacitor users and is explicitly opt-in.

}

/**
Register a single plugin.
*/
func registerPlugin(_ pluginClassName: String, _ jsName: String, _ pluginType: CAPPlugin.Type) {
func registerPlugin(_ jsName: String, _ pluginType: CAPPlugin.Type) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed pluginClassName because it was no longer used. It being internal I removed it to avoid having to do NSStringFromClass to pass in a value that wasn't used.

definition to its own file. Make `autoRegisterPlugins` a get-only
property since the bridge decides whether or not to auto-register on
initialization and setting it at any time after init would do nothing.
@Steven0351 Steven0351 merged commit 9f1d863 into main Nov 22, 2022
@Steven0351 Steven0351 deleted the ios-plugin-instance-support branch November 22, 2022 20:38
@co-dax
Copy link

co-dax commented Dec 15, 2022

Hey @Steven0351, does this change (and related android change) allow to load plugins dynamically at runtime as/when/if needed? I am aksing this we are having several plugins in our app and this is causing slow application start so deferring the plugin loading would be great. Also, some of the users would never need some of the plugins so by loading them if needed would reduce app start time.

Thanks!

@Steven0351
Copy link
Member Author

Steven0351 commented Dec 15, 2022

Hey @Steven0351, does this change (and related android change) allow to load plugins dynamically at runtime as/when/if needed? I am aksing this we are having several plugins in our app and this is causing slow application start so deferring the plugin loading would be great. Also, some of the users would never need some of the plugins so by loading them if needed would reduce app start time.

Thanks!

@co-dax, I can't say for sure since that wasn't the use case I created this for and I didn't test for it. However, you might give it a try and see what happens. I think the question on whether or not it would work depends on how eagerly the parts of your app that depend on those plugins are loaded in the webview. With code-splitting it may not be much of an issue, but I'm sure that can change on a case-by-case basis.

@co-dax
Copy link

co-dax commented Dec 23, 2022

thanks @Steven0351 !
I will give it a try.

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.

None yet

4 participants