Annotation processing

[F43nd1r]

I recently discovered the power of annotation processing. I think this could be of help with the inheritance problems we had in the recent past, because it allows us to subclass the users classes instead of requiring the opposite.
(Also compile time annotation processing gives a small performance boost.)

For now I have a project here and here is the respective acra branch.

How this is used:

• Add the compiler as provided dependency
• Add the @ReportsCrashes annotation as normal.
• Optional: Make the Application class implement IAcraApplication. This allows you to perform code manipulations with the ConfigurationBuilder.
• Set the application name in the manifest to org.acra.AcraApplication. This is the class which will be generated by the compiler.

If this is well received, I'll add similar code for the CrashReportDialog, which will allow users to choose any superclass.

Some more interesting points:

• This decouples Acra initialization from the user. I predict Acra might need to become non-static in the future to support instant run. (Android Studio is already giving me warnings about static context fields.) This and similar changes would be easier if my method was the status quo.
• We can check if users used the annotation correctly. (E.g. let the build fail if the annotation is on an activity instead of an application)

[william-ferguson-au]

Can you send me a link to a simple project that uses it so I can see what you mean.

[F43nd1r]

This is my standard acra test module. I keep it parallel to acra, so it's not a project, but a gradle module. acratest.zip

[F43nd1r]

Or for convenience, here is the full gradle project including acra and the compiler. Acra.zip

[F43nd1r]

I've had some time and created code for the dialog too. It has just one problem: Configuration at runtime (using ConfigurationBuilder) will not work (as it is impossible to discover a runtime call at compile time).

[william-ferguson-au]

Is your last comment still relevant for #502 ?

[F43nd1r]

No. The dialog can be configured in any of the old ways. However, if it should be processed by the compiler, it should not be configured by any of the old ways and instead annotated with @AcraDialog.

By the way, would you favor @ACRADialog? It is consistent with other class names, however I was taught to not capitalize acronyms.

[william-ferguson-au]

I'm closing this as I have merged #487 and #488