On pre-lolipop devices, there is a limitation of 65k methods that can fit into the first dex.
Henson contributes to it: if a class A uses Henson to open an intent targeted to class B, then A.class will transitively depend on B.class. Placing A.class in the first dex would include all activity classes that can be reached by Henson in the first dex, making it too big.
The problem is that Henson will use an B$$IntentBuilder that knows about B.class. A workaround is to use reflection to load target activity classes and hence avoid to reference them indirectly from source classes.
Henson has to know about the intent builder types, so it can't use reflection to load them. We need the types there to be known at compile time and reach the DSL state machine. But IntentBuilders themselves only use the token / type litteral of the target class name. They would be a good candidate to use reflection and cut the branch of the tree of dependencies between classes.
Actually, by doing so, Henson would solve a larger problem in Android and mask reflection usage to reach other activities. There are other workarounds like using reflection in new Intent manual calls, or using implicit intents. But having Henson hiding reflection calls to load classes would just be so much more elegant than former workarounds..
stephanenicolas
commented
8 years ago
On pre-lolipop devices, there is a limitation of 65k methods that can fit into the first dex.
Henson contributes to it: if a class A uses Henson to open an intent targeted to class B, then A.class will transitively depend on B.class. Placing A.class in the first dex would include all activity classes that can be reached by Henson in the first dex, making it too big.
The problem is that Henson will use an B$$IntentBuilder that knows about B.class. A workaround is to use reflection to load target activity classes and hence avoid to reference them indirectly from source classes.
Henson has to know about the intent builder types, so it can't use reflection to load them. We need the types there to be known at compile time and reach the DSL state machine. But IntentBuilders themselves only use the token / type litteral of the target class name. They would be a good candidate to use reflection and cut the branch of the tree of dependencies between classes.
Actually, by doing so, Henson would solve a larger problem in Android and mask reflection usage to reach other activities. There are other workarounds like using reflection in new Intent manual calls, or using implicit intents. But having Henson hiding reflection calls to load classes would just be so much more elegant than former workarounds..