One of the key tenets of "slim bindings" is that you only bind the type(s)/method(s) that you need to use. Unfortunately this does not work for a normal binding project because your desired types likely derive from other unbound types or take unbound types as method parameters or return types.
Example:
public class MapView extends MapViewBase implements MappableComponent {
public MapView (Activity activity, MapViewOptions options) { ... }
public PinResult AddPin (string name, PinCoordinates coordinates) { ... }
}
Trying to bind just MapView would fail because it also needs the types: MapViewBase, MappableComponent, MapViewOptions, PinResult, and PinCoordinates. Binding each of those types may require further types, and you essentially end up needing to bind the entire library.
Slim Bindings
The way slim bindings fixes this is that you write a Java wrapper around the API you need that does not expose these custom types to C#. This may look something like:
public class MyMapView extends android.view.View {
private MapView mv;
public MyMapView (Activity activity, string option1, bool option2) {
var options = new MapViewOptions (option1, option2);
mv = new MapView (activity, options);
}
public bool AddPin (string name, long latitude, long longitude) {
var result = mv.AddPin (name, new PinCoordinates (latitude, longitude);
return result.Success;
}
}
In effect, it performs "type erasure" of custom types in order to bind the class.
One potential downside to this is that users must write a Java wrapper in order to expose the correct API, and many users may not know Java or would prefer to remain in C#.
Flutter's New jingen Bindings
Either as a conscience choice or because it is very early in development, jnigen does not expose any custom types in their bindings. Every non-primitive type is exposed as jni.JObject. (Their ~equivalent of Java.Lang.Object.)
So their binding of the above class would look like this (in a C#-looking language rather than dart):
public class MyMapView : Java.Lang.Object {
public MyMapView (Java.Lang.Object activity, Java.Lang.Object options) { ... }
public Java.Lang.Object AddPin (string name, Java.Lang.Object coordinates) { ... }
}
Basically, they are performing the same "type erasure" that our slim bindings require.
Vaguely Typed Slim Bindings
Applying the automatic type erasure that jnigen does to our generator process would provide a nice "hybrid" approach:
Bindings could be generated automatically without the user needing to write and maintain a Java wrapper.
Binding everything as JLO would eliminate nearly all errors that prevent typed bindings from automatically working today:
Missing implementations of abstract base type methods
Missing implementations of interface methods
Covariant return type issues
Generics
Mismatched override signatures
The downside is that you lose all C#/compile time type checking and type checks are performed at runtime by Java. For this reason, it feels better to keep these as "slim bindings" that are used sparingly on a few types rather than binding an entire library without types.
Example:
// Works correctly:
var activity = my_activity;
var map_view = new MapView (activity, null);
// Compiles, but throws a Java exception like IncompatibleClassException or something at runtime
var context = my_activity.Context;
var map_view = new MapView (context, null);
We would need a way to specify which types to bind, perhaps in MSBuild?
Inevitably you will need to work with some additional "real" types from a library. Consider the AddPin method, which requires a PinCoordinates parameter and returns a PinResult type.
Assuming they do not come from a typed binding of a dependency, we would need to additionally bind them:
Background
One of the key tenets of "slim bindings" is that you only bind the type(s)/method(s) that you need to use. Unfortunately this does not work for a normal binding project because your desired types likely derive from other unbound types or take unbound types as method parameters or return types.
Example:
Trying to bind just
MapView
would fail because it also needs the types:MapViewBase
,MappableComponent
,MapViewOptions
,PinResult
, andPinCoordinates
. Binding each of those types may require further types, and you essentially end up needing to bind the entire library.Slim Bindings
The way slim bindings fixes this is that you write a Java wrapper around the API you need that does not expose these custom types to C#. This may look something like:
In effect, it performs "type erasure" of custom types in order to bind the class.
One potential downside to this is that users must write a Java wrapper in order to expose the correct API, and many users may not know Java or would prefer to remain in C#.
Flutter's New
jingen
BindingsEither as a conscience choice or because it is very early in development,
jnigen
does not expose any custom types in their bindings. Every non-primitive type is exposed asjni.JObject
. (Their ~equivalent ofJava.Lang.Object
.)So their binding of the above class would look like this (in a C#-looking language rather than dart):
Basically, they are performing the same "type erasure" that our slim bindings require.
Vaguely Typed Slim Bindings
Applying the automatic type erasure that
jnigen
does to ourgenerator
process would provide a nice "hybrid" approach:JLO
would eliminate nearly all errors that prevent typed bindings from automatically working today:override
signaturesThe downside is that you lose all C#/compile time type checking and type checks are performed at runtime by Java. For this reason, it feels better to keep these as "slim bindings" that are used sparingly on a few types rather than binding an entire library without types.
Example:
We would need a way to specify which types to bind, perhaps in MSBuild?
Theoretically this is all that should be required to create a vaguely typed binding for the
MyMapView
class.Flutter also includes the ability to exclude problematic members if needed, which could be something like:
Or it could use XPath.
Working With Vaguely Typed Slim Bindings
Inevitably you will need to work with some additional "real" types from a library. Consider the
AddPin
method, which requires aPinCoordinates
parameter and returns aPinResult
type.Assuming they do not come from a typed binding of a dependency, we would need to additionally bind them:
We can now create instances of these types, or use
JavaCast<T>
to convertJLO
to a type: