Skip to content
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

Compatibility with other plugins #80

Closed
alexelisenko opened this issue Apr 9, 2019 · 3 comments
Closed

Compatibility with other plugins #80

alexelisenko opened this issue Apr 9, 2019 · 3 comments

Comments

@alexelisenko
Copy link

I am using the flutter_inappbrowser plugin in my project, as well as audioservice.

If I open a browser view before ever starting the audio service, all is okay, but if I start the audio service, then open the browser, the app crashes with the error:

08:54:03.581 145 info flutter.tools E/AndroidRuntime(31364): Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String android.content.Context.getPackageName()' on a null object reference

The call stack stops around here:

08:54:03.583 148 info flutter.tools E/AndroidRuntime(31364): 	at com.pichillilorenzo.flutter_inappbrowser.InAppBrowserActivity.show(InAppBrowserActivity.java:309)
08:54:03.583 149 info flutter.tools E/AndroidRuntime(31364): 	at com.pichillilorenzo.flutter_inappbrowser.InAppBrowserActivity.prepareView(InAppBrowserActivity.java:98)
08:54:03.583 150 info flutter.tools E/AndroidRuntime(31364): 	at com.pichillilorenzo.flutter_inappbrowser.InAppBrowserActivity.onCreate(InAppBrowserActivity.java:69)

I suspect this could be related to audioservice requiring a custom MainApplication class, but I don't have much Android development experience, so any insight/help would be much appreciated.

audioservice plugin: https://github.com/ryanheise/audio_service

@alexelisenko
Copy link
Author

Some helpful details from developer of audio_service plugin:

When you use audio_service, your app is going to set up two Android contexts for running code: The "activity" context for running UI code, and the "service" context for running background audio code. The idea is that even if the activity context is destroyed, the service context will live on and audio playback will continue without the UI. Because we want to run Dart code in both contexts, we have to initialise a plugin registry for each context which allows dart code running in that context to make use of plugins. When the plugin registry is initialised, it basically calls registerWith on all of your plugins. The problem is that a lot of older plugins were unfortunately coded assuming that they can just call the Android Flutter method registrar.activity() to get the current activity and use it as a context to do various things (in Android, you basically need a reference to a context to be able to perform many API calls). But when registerWith is called from the background service context, registrar.activity() will return null, and attempting to use this context will result in a NullPointerException. If the plugin is not intended to be run in the background, the plugin should still check if registrar.activity() returns null and then do nothing. Remember that there are two plugin registries so each plugin is registered twice. It's fine for the one being registered in the background to simply do nothing, but it should at least guard against crashing with a NullPointerException.

When I look at the code for flutter_inappbrowser, I see that it's also storing the registrar in a static field which is problematic. Since there are two registries, registerWith will be called twice on the same plugin, one in each context, and you don't want the second one (probably the service) to override the first one (probably the activity). So that should be changed to an instance field also. There seem to be many other static fields too, so the plugin author may need to figure out which ones need to be distinct within each plugin registry and change them to instance fields.

@pichillilorenzo
Copy link
Owner

This should be fixed with the new version 1.2.0

This was referenced Jul 6, 2020
Copy link

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 and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants