Capacitor v3: Make plugins usable for native code

[BorntraegerMarc]

On our side there is a need to use plugins from native code.

To give an example:

• We use the LocalNotification plugin in our ionic app to trigger notifications
• We have in our custom native code complex logic to handle push notifications (Firebase Cloud Messaging)

Ideally we'd like to use the LocalNotification plugin in our custom code so we can use the same parameters as we use in our ionic app. To ensure the notification style is always the same -> Whether one is triggered from ionic or custom native code.

The same concept applies for other plugins like AES encryption capacitor plugins -> We want to use the same encryption code from our web app & the custom native code.

[imhoffd]

Agreed. The core/official plugins are being split out and refactored (see #3227). It's a shift in how plugins are developed, for sure. We plan to have the main plugin class be native-first and then have a layer for communicating with the web view that uses it, as opposed to all the logic being in the layer and forsaking native.

[BorntraegerMarc]

Great! Very glad to hear :)

Having the plugins usable available on native side is a very important first step. One should also think about the API of how those plugins will be consumed by custom native code. I would find, having some sort of dependency injection model (like angular) really awesome.

[jcesarmobile]

Can you provide more information about what you need and why current implementation is not good for you?

At the moment you can get a plugin like this to use it's methods

On Android

App appPlugin = (App) bridge.getPlugin("App").getInstance();

On iOS

let appPlugin = self.bridge?.getOrLoadPlugin(pluginName: "App") as? CAPAppPlugin

[jcesarmobile]

Yeah, that's because plugins are meant to be used from javascript, not from native. We only use that to call a few plugin methods that don't expect a plugin call, like firing some plugin event.

[imhoffd]

We can easily allow them to be used in native as well by implementing what I mentioned in my answer. The bulk of the logic would be in a native-first class, and then the plugin would be a thin wrapper around it. At the very least, this is good programming (separation of concerns).

[BorntraegerMarc]

Exactly what @dwieeb said 👆

I would say this is more a code structure change than a technical challenge.

That being said: I don't know if it makes sense for every plugin to be callable from custom native code. Our use cases were for the LocalNotifications & Storage plugin specifically. I don't know if it makes sense for all of them.

[jcesarmobile]

The LocalNotifications plugin is a set of 12 classes, most of the functionality is in LocalNotificationManager and NotificationChannelManager classes. Most of their methods are public and don't need a PluginCall, so your native code can use those classes without using the plugin class.
As I understand what dwieeb says is doing something like that so users use the other classes and not the plugin class, that's how it works already. Of course it could be improved, some of the private methods could be public if needed. That's why I wan't to know what problems are you facing with current implementation to see what could be improved.
But if you want to communicate with the javascript side, that needs to be done through the plugin class, and is already possible by getting the plugin as I mentioned in my previous message.

Storage, is just a wrapper around SharedPreferences, so not sure if it's worth wrapping the wrapper.

[BorntraegerMarc]

some of the private methods could be public

Right. I think that was the main pain point: some of the methods we wanted to use, weren't public. E.g: #2908

#2648 This feature request was also a problem at some point but now it's solved. Linking for reference.

Storage, is just a wrapper around SharedPreferences, so not sure if it's worth wrapping the wrapper.

Right. Agreed. However the prefs name property was private. So one would have needed to copy & paste the name. Not so nice if it would change in the future:

capacitor/android/capacitor/src/main/java/com/getcapacitor/plugin/Storage.java

Line 17 in d131a5f

private static final String PREFS_NAME = "CapacitorStorage";

Also one idea to explore: what we wanted to achieve with the storage plugin was actually less storage sharing and more something like LiveData between webview & native: https://developer.android.com/topic/libraries/architecture/livedata