Dart & Henson 3 Specs draft. RFC

Hi @f2prateek , we wanna change Henson and release a new version. Dart would be changed optionally as well, see below.

The problem we are facing is that Henson doesn’t, and cannot in its current form, work well with modules:

• if 2 activities in 2 different modules want to navigate to each other, then Henson cannot handle that because it would create a compilation cycle between the modules to reflect the navigation cycle, which is legitimate.

We have found a work around, and we ask for your comments on this. We want to move fast.

Proposed Henson API changes

We are gonna change Henson to work completely the opposite of its actual state:

• instead of generating intent builders from annotated activities that can refer to a navigation model, we want to generate the same intent builders from an annotated navigation model that will refer to the activity.
• it will mean people who use multiple modules will have to create a separate module, or more, to contain the navigation models and use henson on this module. This navigation module will have the following properties:
  • it will not have any dependency on any other module
  • it will be the first to be compiled, other modules will depend on it
  • models will use an annotation to be detected/processed by henson and the annotation will refer to the name of the target activity, using its FQN, not the class as it would introduce a cyclic dependency.
  • the Henson class will be generated in the same way as before and will contain methods to obtain all intent builders
  • variant and flavors can differ and generate different Henson classes
  • we didn’t start working on it yet, but we think this work will put us in a much better position to tackle instant apps navigation as well as modularization is an essential part of instant apps.
  • $$IntentBuilders will be renamed to __IntentBuilders to follow ButterKnife conventions and remove the ambiguity with inner classes
  • we are gonna refactor the code to make it cleaner at the annotation processor level
  • we are considering using Auto services in Dart, also as standard

Proposed Dart API changes

• We are also thinking of renaming the @InjectExta annotation to @BindExtra in the same release. It will follow more closely the evolution of Butterknife and will disambiguate with DI annotations which are confusing for junior devs.
• we will also change the name of the dart binding method
• the $$ExtraInjectors will be renamed to __ExtraBinders and remove the ambiguity with inner classes

Please note that all this work will also make it easier to work on an incremental version of Dart & Henson.

[stephanenicolas]

@f2prateek I am gonna merge a PR that will transform master into a new Dart 3 master. The current version 2 master is now on branch version-2 in the repo if we want to patch it.

[stephanenicolas]

@fansmc can we discuss the topic in a new issue. We are not against the idea, but we would like to understand / discuss things more in-depth. This will not be addressed in 3.0, but could be done quickly after. And even faster if you contribute a PR 😉