Jonathan Pryor

Results 112 comments of Jonathan Pryor
trafficstars

`Java.Interop.Dynamic` is an interesting alternate approach, but iirc when @mattleibow explored it in #508, it had *huge* perf implications (i.e. the first call was iirc ~10 *seconds*; subsequent calls were...

@Redth [wrote](https://github.com/xamarin/java.interop/issues/940#issuecomment-1015866322): > this seems very difficult to solve properly without making our binding nuget packages describe the artifact so you can infer its identity (so, maven group id, artifact...

@Redth [asked](https://github.com/xamarin/java.interop/issues/940#issuecomment-1015901832): > how would you generate dealing with Java initiated call backs though? The "glib" answer is "manually"!: ```csharp [SlimBinding ("android/view/View$OnClickListener")] partial interface IMyViewOnClickListener { [SlimBinding ("onClick")] void OnClick...

@jpobst [wrote](https://github.com/xamarin/java.interop/issues/940#issuecomment-1015884815): > For example, many people have requested we bind AndroidX.SplashScreen just for one method, but we are holding off because it's still an alpha… This feels like another...

Things that we'd want to make optional: https://github.com/xamarin/java.interop/blob/ba6b013c04c209675905dc42c5d7d908624e64d6/src/Java.Interop/Java.Interop/JniValueMarshaler.cs https://github.com/xamarin/java.interop/blob/ba6b013c04c209675905dc42c5d7d908624e64d6/src/Java.Interop/Java.Interop/JniBuiltinMarshalers.cs

Background: changing `type` is usually considered Bad™, because the `type` value is used to compute the JNI signature for member lookups, and if it changes it could prevent the member...

Also of note is that the JNI signature changed, which is to be expected, e.g. ```diff - const string __id = "onBindViewHolder.(Landroidx/recyclerview/widget/RecyclerView$ViewHolder;I)V"; + const string __id = "onBindViewHolder.(Landroidx/leanback/preference/LeanbackListPreferenceDialogFragment$ViewHolder;I)V"; ``` (I...

There are four scenarios to consider: **Non-`abstract` `Foo` and resolvable `Fooable`**: This is what we currently require. *That said*, `Fooable` need not be a public type! If it's a Kotlin...

> We should make sure we use the right calling convention on different platforms. *Should* we? We need to make sure that we use the *right calling convention*: the C#...