Add package as a dependency to the package created by EvalWidget?

[dlabs-matic-leva]

When we are using EvalWidget, we are creating new package with libraries, right? Is it possible to add some 3rd party package as dependency and then import a library from included package?

Using example from docs, I'd like to achieve this:

EvalWidget(
  packages: const {
    'example': {
      'main.dart': '''
        import 'package:flutter/material.dart';
        import 'package:url_launcher/url_launcher.dart';
    
        class MyWidget extends StatelessWidget {
          MyWidget();
    
          @override
          Widget build(BuildContext context) {
            return TextButton(
              child: Text('Click me '),
              onPressed: () {
                launchUrl(
                  Uri.parse(
                    "https://google.com",
                  ),
                );
              },
            );
          }
        }
''',
    }
  },
  assetPath: 'assets/program.evc',
  library: 'package:example/main.dart',
  function: 'MyWidget.',
  args: [],
);

[ethanblake4]

Hi!

It is impossible for dart_eval to access the packages directly, this is a Dart limitation. There are two ways to do it - either you can create bindings or you can compile with the dart_eval CLI. However because url_launcher uses native platform code I believe you will have to create bindings for it. I would recommend cloning the url_launcher package and using the dart_eval CLI to auto generate wrappers.

Best of luck!

edit: one other very simple way to do it is just to pass in a $Closure wrapping the launchUrl function, if that's all you need to do.

[dlabs-matic-leva]

Thank you for the insights! I'm trying to evaluate what's the easiest way to do OTA updates in Flutter ecosystem and flutter_eval looks the most promising.

So, if we have a package of commonly used widgets, your recommendation would be to use wrapper interop to expose these widgets to Eval environment?

url_launcher was actually just first piece of code that we could migrate to flutter_eval, I didn't think it would require special treatment. But, writing and thinking about it, couldn't we just create a wrapper (in pure programming sense, not dart_eval's sense) for url_launcher and then generate wrapper interop for said wrapper? url_launcher is already compiled and included with our app, there's no need to compile it to EVC bytecode, right?

[ethanblake4]

I didn't think it would require special treatment

I realized I didn't really explain this well. flutter_eval does support method channels so technically it could directly compile all of url_launcher's code. However, it does not currently support Flutter platform interface plugins, so it couldn't work automatically. That's why I think it's easier to use a wrapper.

couldn't we just create a wrapper (in pure programming sense, not dart_eval's sense) for url_launcher and then generate wrapper interop for said wrapper?

Yes, this is absolutely possible.

url_launcher is already compiled and included with our app, there's no need to compile it to EVC bytecode, right?

If you use a wrapper, yes.