Support podspec module_name to avoid name clash with native iOS frameworks

[rmtmckenzie]

Use case

A recent update to flutter (on master, not sure if it has reached other branches yet) has broken a plugin I use, Objectbox. The issue is that they have a native package called 'objectbox' which is included by the dart plugin. Before this version they were able to get away without having any objc/swift code and therefore didn't have a framework, and so there was no name collision. However, with the new changes in master it seems as though having a plugin implementation is required.

They could theoretically get around this by publishing a separate package, but that seems really silly and leads to package bloat on pub.dev as well as more difficulty for whoever is maintaining it.

Proposal

Instead, I'd like to propose supporting something that cocoapods has support for - setting the s.module_name. If this is set to something else, it eliminates the collision with the native package (i.e. objectboxdart). However, in the GeneratedPluginRegistrant.m file, it always generates it with name 'objecbox'.

If the flutter tooling supports it, it'd be great if it could be read from the podspec, but I'm going to guess that'd not possible so a perfectly great alternative would be the ability to define it directly in the pubspec.yaml for the package, something like this:

flutter:
  plugin:
    platforms:
      android:
        package: io.objectbox.flutter
        pluginClass: ObjectboxPlugin
      ios:
        pluginClass: ObjectboxPlugin
        moduleName: objecboxdart

I've been able to get a project including the plugin to compile by adding this to the objectbox.podspec:

  s.module_name      = 'objectboxdart'

And the only thing that needs changing is the GeneratePluginRegistrant.m file:

#if __has_include(<objectbox/ObjectboxPlugin.h>)
#import <objectbox/ObjectboxPlugin.h>
#else
@import objectboxdart;
#endif

It might make sense for the symlinks etc to be changed as well (so that it'd be objectgboxdart/ObjectboxPlugin.h in the above, but being able to change the @import statement is enough to get it working for me.

With this change implemented, if the moduleName isn't defined, it could default to the package name exactly as it does now. This would allow for easy overlap with native frameworks that have the same name as the flutter packages.

[Cloudef]

We are also running into this issue. We named our flutter plugin 'indooratlas' the podspec has to have the same name as the flutter plugin, but we can't depend on 'indooratlas' cocoapods dependency on the trunk now then.

Does anybody have good workaround that does not require renaming the flutter plugin itself?
It seems like simple fix:

flutter/packages/flutter_tools/bin/podhelper.rb

Line 264 in 2df7dca

pod plugin_name, :path => File.join(relative_symlink_dir, 'plugins', plugin_name, platform)

[Cloudef]

Any update for this? Would you accept a PR that implements @rmtmckenzie's proposal?

[stuartmorgan]

Would you accept a PR that implements @rmtmckenzie's proposal?

I would expect so; it seems like a reasonable feature. @jmagman Any concerns you can see with that option?

[jmagman]

@jmagman Any concerns you can see with that option?

No concerns, it sounds like a good change.