Refactoring : bind validators and processors #368

Activity

1. yDelouis commented on May 29, 2013

   

   yDelouis

   on May 29, 2013

   Contributor

   More actions

   Hi,

   I also think it would be a good idea to refactor a part of the code of androidannotations and to change a bit its architecture, because:

   • Some parts (EBeanHolder for example) become very messy (which is a pity for a project whose aim is to make code clearer).
   • And above all, the current model leads to some issues because some annotations can interfere with others :
     Ex: try to use the annotation @OnActivityResult in an Activity annotated with RoboGuice and you'll have two methods onActivityResult in the generated class.

   I have started to work on this issue in my fork (branch 368_refactor) and propose the following model:

   • A class extending EComponentHolder for each enhanced component: EActivityHolder for @EActivity, EServiceHolder for @EService, etc... These classes replace the current class EBeanHolder which is very messy. These classes are responsible for creating methods, fields and blocks used by the AnnotationHandlers. These blocks are got using getters which enables to create methods only if they are used thanks to lazy instantation.
   • A class extending AnnotationHandler for each annotation which is responsible for the validation and the processing and which contains the annotation it handles. From the list of all AnnotationHandlers, we can have the list of all annotations. AnnotationHandlers doesn't create any methods in EComponentHolders and only use blocks provided by the EComponentHolder. If an AnnotationHandler works on different kind of EComponentHolder (like @ViewById), an interface is created and implemented by targeted EComponentHolders.
   • GeneratingAnnotationHandler extending AnnotationHandler for each annotation @EXxxxx which is also responsible for instantiating a new EComponentHolder depending on the annotation. GeneratingAnnotationHandlers generate only the code implied by the annotation and don't create the whole generated class like now. Ex: the GeneratingAnnotationHandler for @EActivity only set the layout and doesn't create the IntentBuilder. (The EActivityHolder is responsible for that).

   This model has some advantages:

   • Only one list to maintain instead of three : (Validators, Processors, Annotations -> AnnotationHandlers).
   • Code is clearer, easier to understand, to maintain and to extend.
   • Only used methods are generated thanks to lazy instantiation.
   • Annotations doesn't interfere because it's the EComponentHolder which creates the methods and fields.

   Refactoring the whole project is quite a big task, and I'm at the beginning so I would like to have some feedback, and to know if it could be integrated into the project to know if and how I continue my work.
2. yDelouis commented on Jun 11, 2013

   

   yDelouis

   on Jun 11, 2013

   Contributor

   More actions

   Same issue than #282
3. DayS commented on Dec 16, 2013

   

   DayS

   on Dec 16, 2013

   Contributor

   More actions

   Finally merged :) Thanks
4. DayS

   closed this as completedon Dec 16, 2013