-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MissingPluginException : the plugin works but an exception is throwed #13
Comments
the exception seems to be caused by the return of |
Issue #9 covers adding an example plugin, including the Dart side, to the example, to avoid people having to try to figure out the Dart side. In this case, I think it's a plugin bug. The existing Dart code for interacting with this is using OptionalMethodChannel which means this never came up. |
Update on this: doing a quick fix for this is pretty easy, but in looking into it I filed issue #45 which ideally I'll do first. It is definitely a plugin bug, which the current API makes much more likely than it should be. |
Rework macOS plugin API Replaces the synchronous plugin response using raw data with an asynchronous response using a much higher-level abstraction that makes sending non-empty responses much easier. The API changes are based very closely on the iOS Flutter plugin API, so that it will be familiar to Flutter plugin developers, and make code sharing easier. This includes using that APIs naming and terminology whenever possible. This is an incremental change, in that some aspects of the iOS API (most notably message channel registration and method codecs) are still not present in this API. A future change will further align the macOS API with iOS, but this portion makes most of the changes that would significantly change the structure of a plugin (allowing for rich, async responses). This addresses the macOS portion of issue 45. Also fixes issue #13 on macOS.
Replaces the synchronous plugin response using raw data with an asynchronous response using a much higher-level abstraction that makes sending non-empty responses much easier. This makes the Linux plugin API consistent with the current state of the macOS plugin API. It follows Flutter's Java plugin API response object pattern, since without RTTI the ObjC approach of determining response type in a single callback isn't viable. As with the macOS rework, this is an incremental change. A future change will further align the macOS API with mobile, but this portion makes most of the changes that would significantly change the structure of a plugin (allowing for rich, async responses). This addresses issue #45 and issue #13
The plugins now return correct response objects, using the new API. |
Hi,
first : thanks for sharing this project ! it's really exciting :)
I started to play and tried to use plugins, but even if the call works, I get a MissingPluginException.
For instance when I use this method to open the colorPicker, the picker is opened, but I see an exception log.
Did I missed something ?
The text was updated successfully, but these errors were encountered: