Proposal: Vaguely Typed Slim Bindings

[Jonathan Pobst]

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:

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 conscious 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?

<ItemGroup>
  <AndroidMavenLibrary Include="map.company:MyMaps" Version="1.0.0" />
  <AndroidBindType Include="map.company.MyMapView" />
</ItemGroup>

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:

<AndroidBindExcludeMember Include="map.mycompany.PinResult map.mycompany.MyMapView.AddPin (string, map.mycompany.PinCoordinates)" />

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 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:

<AndroidBindType Include="map.company.PinCoordinates" />
<AndroidBindType Include="map.company.PinResult" />

We can now create instances of these types, or use JavaCast<T> to convert JLO to a type:

public void DoMapStuff (MyMapView map)
{
  var coords = new PinCoordinates (0, 0);
  var result = map.AddPin ("Null Island", coords).JavaCast<PinResult> ();

  Console.WriteLine ("Adding pin was successful: " + result.Success.ToString ());
}