Annotation processor should consider RealmObjects that were generated by other annotation processors

[Zhuinden]

Currently the processor runs only once, but as multiple rounds are executed, it would be possible to generate RealmProxy classes for RealmObjects that were generated by other annotation processors.

[bmeike]

Yeah. We should do this. I came really close to doing it when I refactored the processor, a few weeks ago, but I didn't understand the impact completely.

[cmelchior]

It is not as trivial as it sounds. I originally investigated that route when doing the initial implementation of modules. There are a few challenges:

• We want to support ProGuard as much as possible, which means we want to allow obfuscating model classes. This, in turn, makes finding model classes non-trivial when doing multiple rounds.
• We want to minimise reflection.

The current approach solves both of these constraints quite nicely in the sense that only the DefaultRealmModule must be accessible through reflection. All the other information can then be read through this class including how to find obfuscated model classes.

One solution that comes to my mind could perhaps be to create a RealmDefaultModuleMediator_Round<X> class instead and then combine those at runtime through the CompositeMediatorClass.

Compared to the current approach it would add one extra reflection lookup + handling the associated ClassNotFoundException. That would probably be acceptable, especially considering that we only need minimal changes to do it.

[alexmerkle]

Are there any plans to implement this "minimal" solution in the near future? I just started working with realm and some custom annotation processors. With the ability of generating RealmObjects I could get rid of some boilerplate.