Skip to content

Using already generated bindings when generating new bindings #621

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

Closed
pdegand opened this issue May 31, 2023 · 1 comment
Closed

Using already generated bindings when generating new bindings #621

pdegand opened this issue May 31, 2023 · 1 comment

Comments

@pdegand
Copy link

pdegand commented May 31, 2023

Hi,

I generated bindings for the androidx.security-crypto library based on the example for Health Connect and everything went smoothly.

As the builder of the EncryptedSharedPreference needs a Context, I added android.content.Context to the list of classes in the JNIGen config file.

And I packaged my generated bindings in a reusable package.

Now let's say I would like to generate binding for HealthConnect, or any other Jetpack library.
Those library will almost certainly use the Context class so I will have to also add the Context class in the config file for my new binding.
If I package these new bindings in a reusable package as well and I use both my package of security-crypto & heathConnect, I will have twice the binding for the Context class.

Is there a way to generate the binding for Context once, package it into a reusable library and use this library for both the bindings of security-crypto & HealthConnect so that in the end, I will have only 1 implementation for the bindings for android.content.Context ?

Side question : is this even a good "practice" to generate binding of such a big class as Context or should I rather just use the context as JObject and calling its method with callMethodByName ?

Thank you :)

@dcharkes
Copy link
Collaborator

Hi @pdegand!

This is being tracked in:

And @HosseinYousefi landed some initial work today to support this! 🎉

Please follow the mentioned issue.

@dcharkes dcharkes closed this as not planned Won't fix, can't repro, duplicate, stale May 31, 2023
@HosseinYousefi HosseinYousefi transferred this issue from dart-archive/jnigen Nov 17, 2023
parlough pushed a commit to parlough/native that referenced this issue Apr 8, 2024
* Fix dart-lang#614

* Update test expectations

* Hacky fix

* Refactor

* Fix analysis

* Fix analysis

* Fix analysis
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

No branches or pull requests

2 participants