Compatibility with other plugins

[alexelisenko]

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.

browser plugin: https://github.com/pichillilorenzo/flutter_inappbrowser

[ryanheise]

This seems to be the type of error mentioned at the bottom of the audio_service README page, and the solution would be to submit a bug report for that other project. Before I explain the error, I want to suggest an alternative plugin called webview_flutter which is an official plugin from Google. If you want to use the pre-AndroidX version of this plugin, add the following to your pubspec.yaml:

  webview_flutter: 0.2.0 # Last release before AndroidX

If you prefer to use flutter_inappbrowser and are willing to submit a bug report to that project, here is a little bit of an explanation of what's going on.

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.

Anyway, I recommend just using webview_flutter ;-)

It's still useful to know how this works, though, because that error message you posted over on the iOS issue, and the reason why you had to upgrade your Flutter to the latest version to get the newest APIs, has something to do with iOS's equivalent to what I described above. This new iOS API apparently brings the iOS implementation of Flutter background execution on par with the Android implementation so that it is possible for background dart code on iOS to load plugins via the registry.

[alexelisenko]

@ryanheise Thank you for the explanation, its very helpful.

I will take a look atwebview_flutter, but in my initial search for using webviews in flutter, every plugin had issues with brining up the keyboard in the webview, and/or missing some js injection methods I needed, but I'll take another look.

I have submitted a bug report to flutter_inappbrowser

As a last resort, I will fork flutter_inappbrowser and make the changes myself.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service.