Bug 29140

Summary: Cannot typecast to CastClass.IApplicationConnectionResult
Product: Android Reporter: Prashant Cholachagudda <prchol>
Component: GeneralAssignee: Jonathan Pryor <jonp>
Status: CONFIRMED ---    
Severity: enhancement CC: fredx21, jon.douglas, mono-bugs+monodroid
Priority: High    
Version: 4.20.0   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS   
Tags: Is this bug a regression?: ---
Last known good build:

Description Prashant Cholachagudda 2015-04-16 03:14:54 UTC
XA fails to cast the object received from IResultCallback.OnResult, while Android version give us the Generic version of `OnResult` method

C# sample:
class MyMediaRouterCallback
{
    private void Load()
    {
        IPendingResult result = Android.Gms.Cast.CastClass.CastApi.LaunchApplication(/*...*/);
        result.SetResultCallback(new ResultCallbackWrapper(this));
    }

     public void OnResult(Java.Lang.Object result) {
                //throws an exception
		CastClass.IApplicationConnectionResult  r = result as CastClass.IApplicationConnectionResult;
    }
}

Refer attached sample code.
Comment 2 Jonathan Pryor 2015-04-16 09:56:19 UTC
This is Bug #16604, which at the time was closed NOT_ON_ROADMAP, because I didn't want to enumerate all interfaces that a type implemented in preference to checking the base classes when determining the "best fit" wrapper type.

Theoretically, we could check interface types if the default base-class strategy fails. The problem with checking interfaces at all is that JNI doesn't expose a way to enumerate all the interfaces a class implements, which means to do so we would need to use JNI to invoke java.lang.Class.getInterfaces()...which is certainly possible.

In the meantime, use result.JavaCast<CastClass.IApplicationConnectionResult>() instead of the `as` operator.
Comment 3 Jon Douglas [MSFT] 2017-07-03 18:01:30 UTC
Marking CONFIRMED as to same behave described in https://bugzilla.xamarin.com/show_bug.cgi?id=29140#c1

Although https://bugzilla.xamarin.com/show_bug.cgi?id=29140#c2 describes a NOT_ON_ROADMAP scenario, I am leaving this as CONFIRMED until further movement.