FlutterNativeView "send" method should not suppress detached view exception

[diesersamat]

This issue is about an issue with Flutter API in native Android code.

In FlutterNativeView.java there is a function called send(String channel, ByteBuffer message, BinaryReply callback):

public void send(String channel, ByteBuffer message, BinaryReply callback) {
        if (!this.isAttached()) {
            Log.d("FlutterNativeView", "FlutterView.send called on a detached view, channel=" + channel);
        } else {
            this.dartExecutor.send(channel, message, callback);
        }
    }

As you can see, if the view is not attached, nothing happens. I think we should call callback with an error message or maybe return something from the function.

I faced this issue trying to call channel.invokeMethod("launch", type); — if the view is not attached, there is no way to react to that case. Even if you call channel.invokeMethod("launch", type, callback);, the callback will not return onError, because, as you saw, in the case when the view is not attached, nothing will happen.

Steps to Reproduce

You can face the issue, for example, in quick_actions plugin.

1. Install the example app and run it on Android
2. If you try to use the Shortcut item, it should work fine
3. Now, open the app again, and click Back button
4. Click the Shortcut icon again
   As you can see, the quick action will not be called and the app will not be opened this time. The main issue here is that the quick_actions plugin tries to call channel.invokeMethod("launch", type);, but the view has been already detached and the only thing that happens is "FlutterView.send called on a detached view, channel= message in Logcat. And there is no way to fix this behavior because there is no way to react to such a case.

[collinjackson]

FYI @matthew-carroll

[matthew-carroll]

@diesersamat would it be acceptable from your perspective to throw an exception that is caught by the caller?

@jason-simmons do you have any opinions on this?

CC @xster

[diesersamat]

@matthew-carroll I see two options right now:
There is callback reference in send function, so, maybe, we can use onError with a specific message.
Or, to throw an exception, but it can blow a lot of apps up, for example, those using quick_actions plugin.

[matthew-carroll]

@mklim do you have thoughts on a best practice here? I'm leaning towards throwing an Exception but that may have unacceptable consequences...

[mklim]

What exactly would be calling the top level send and catching the Exception? I'm having trouble tracking down the execution flow. Would it fall onto any and all plugins?

Assuming that, I think callback.onError makes the most sense here. That way the response isn't just dropped on the floor like it is now, but there also isn't going to be a user visible crash when there wasn't before. I don't think this would be a breaking change in behavior, since it would just be correctly reporting when something failed instead of silently failing.

I wouldn't want to throw and introduce a breaking change in behavior that would end up crashing more often. For example in the repro case mentioned in the first comment the failure is that nothing happens at all, but changing to a throw would upgrade that to a runtime crash. I'd also rather avoid exceptions in general unless something has gone extremely wrong. Which I don't think this case really is.

[TahaTesser]

Hi @diesersamat
Is this issue still valid?
Thank you

[jmagman]

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!

Thanks for your contribution.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.