@vashworth I think I may have misspoken. I was thinking we could get rid of this since we would be sending the FlutterViewController. I decided to send the FlutterPluginRegistry though since that makes more sense to send the abstraction that is more apropos. We could potentially allow people to get the binary messenger from the FlutterPluginRegistry if we wanted to get rid of it.

if we have to issue breaking changes, we might as well introduce a registry.registrar(forChannel:) for sanity

registry.registrar(forChannel:) wouldn't quite be the right API since a registrar has a BinaryMessenger which you specify the channel name on.

Registry.binaryMessenger would be the convenience we want but that completely circumvents the need for the registrar.

I think Registry.unaffiliatedRegistrar would probably be what we want, something like that.

Let me know if you are fine with shelving this decision for later since it's a convenience that will be added to the existing API. The PR in it's current state is just using what is already present.

Ya I think we can leave it. Maybe add some comments to registrar(forPlugin:) saying it's also ok for non-plugins? Or explain in the instruction website?

Can we get the FlutterViewController and get the binary messenger from it?

Can we get the FlutterViewController and get the binary messenger from it?

If someone has a FlutterViewController they can get the binary messenger and the FlutterViewController is a FlutterPluginRegistry. There's no concept the represents both of those things. Having them both doesn't make sense because accessing the binary messenger invalidates the need for a registrar.

Making register callback send in a FlutterViewController would make that possible, but I didn't want to do that because that leaves us tied to a concrete class which gives us less options in the future.

Okay last ditch comment: I really dislike using forPlugin, it's confusing since it's not a plugin. Plugin means something specific in Flutter, so I think it'd be confusing for users too.

From my understanding, forPlugin is used to get the registrar to hook up a method channel with the plugin and/or publish the plugin. With this use case, we never intend to do those things.

What if we have another method called registrarForKey, which basically does the same under the covers but has a slightly different intention?
Maybe something like this:
master...vashworth:flutter:registar_for_key

WDYT?

That is overloading the concept of a plugin name and a key now, which are functionally the same. We know that but it is confusing to someone. "Can you have a key and a plugin name with the same values?"

It also makes people have to come up with a key which they didn't have to in the past. I think FlutterPluginRegistry.registrar is better. It just gives you an unincorporated registrar, which matches the semantics we had previously.

We have to think hard if we want to continue to support that though.

if we have to issue breaking changes, we might as well introduce a registry.registrar(forChannel:) for sanity