Conductor: Annotation process to generate controller builders

[EricKuck]

Picking up the discussion started with @sockeqwe on #3 here. I've done some work with annotation processors in the past (LoganSquare), but your FragmentArgs lib is much closer to what this would take than anything I've ever done. Any suggestions for proceeding?

I'm sure you've already put a lot of thought into this for FragmentArgs, but has anyone thought of a way to skip the step of having to build the project before the builder is generated? With LoganSquare I was able to abstract the generated code away enough that developers didn't need to care about whether or not the generated code was actually there or not, but my use case was quite a bit different. I have a feeling there probably isn't a way to abstract that away when the builder itself is what's being generated.

[burntcookie90]

No, unfortunately I don't think that's possible :/ since you're directly referencing the generated code.

[sockeqwe]

This should be an optional module or third party library and not build in into Conduct core.
I'm not sure if in times of kotlin an annotation processor is needed. Extensions functions and delegated properties could do (almost) the same job.

but has anyone thought of a way to skip the step of having to build the project before the builder is generated

It's not possible, since annotation processing runs when javac runs.
The Problem is the "Builder", reading the arguments could be hidden behind some reflection magic.

But the builder could be defined by the user similar to auto-value, but I'm not sure if this really reduces writing boilerplate code.

We could also discuss about alternatives to annotation processing i.e. custom gradle plugin (Hugo alike), ASM (bytecode manipulation, not sure if it still works with jack&jill) or use android class transformation api. But all of them (as far as I know) require to build the project to be triggered. It would be nice to somehow "magically" add a constructor with the given arguments as parameters.

[burntcookie90]

I think the only way to "magically" do this would be how data binding generates virtual classes for it's bindings. I don't think it's worth it at that point

[burntcookie90]

https://github.com/dinosaurwithakatana/freight

Here's a POC for an extras handler. It currently supports the _majority_ of the bundle API (missing ArrayList stuff, but that's coming). Also, it also creates a builder for the controller.

Still needs to handle required extras and default values, but that shouldn't be too tough.

[sockeqwe]

SavedState and ViewState should work with others like Icepick. But for now
you can't distinguish between view state and saved state ( would require
two separated annotations?)

adi1133 [email protected] schrieb am Mo., 25. Apr. 2016, 03:21:

Currently Conductor allows saving/restoring state with multiple bundles:

• Arguments (KEY_ARGS) - set in constructor, restored in constructor,
  are available with getArgs()(mutable)
• Instance State (KEY_SAVED_STATE) onSaveInstanceState()
  onRestoreInstanceState()
• View State (KEY_VIEW_STATE) onSaveViewState() onRestoreViewState(),
  this is separate from the bundle passed to the view to save/restore itself.

It would be nice to have a codegen module that handles the first two
bundles. I think the view state bundle will be used more rarely (since
custom views also handle this).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/bluelinelabs/Conductor/issues/7#issuecomment-214084375