Artyom Drozdov

Oh, true. But rewriting manifest is much simplier. Moreover, actualy I'm not sure that there is some real need for declare them in the manifest - gradle already processes manifest...

Moreover, you don't need to declare generated class in manifest in situations: 1. The class is a fragment 2. The class is a bean 3. The class is a view...

Yep. I'm not sure that there is some way to avoid generated intent builders, but maybe we will get some clue while implementing other classes. So, I'll try to implement...

It also will be useful, if the factory class will have some way to set a strategy of instantiation. In this case it will be easier to mock up objects...

Yeah, looks great! But actually I would like to do it in another way - iterate over array while looking for creator is not the best idea, map of class...

I'll try to implement the same thing but without reflections. Looks like I need to make @fredszaq and @yDelouis approaches work together to achieve this. As for `IntentBuilders` I don't...

Hey, I'm not suggesting to drop compatibility :) Just to add a new way for creating intents, without removing the old one. And `IntentBuilder` is not supposed to be generated...

It is called from here: [link](https://github.com/excilys/androidannotations/blob/develop/AndroidAnnotations/androidannotations-api/src/main/java/org/androidannotations/api/BackgroundExecutor.java#L125). Right now it can't be called without synchronization because of iteration through static list of task, wich is not thread safe.

There is another funny side-effect in method Task.postExecute(). Because of picking the next task by the serial, if you have more serials then threads in pool, tasks without a serial...

Maybe. But it leads to almost completely rewriting the BackgroundExecutor because of its way to manage the tasks.