Provide for programmatic, non-static configuration

[GoogleCodeExporter]

This is a request for an enhancement of the configurability of ACRA. The 
annotation-based configuration of ACRA, while convenient for simple cases, is 
very limiting in more advanced usage.  I believe that everything that is 
configurable using the annotations should be exposed in the ACRA API.

Also, certain things aren't configurable at all, but really should be, such as 
the e-mail subject for e-mail reports.

Original issue reported on code.google.com by cherry...@gmail.com on 30 Aug 2011 at 10:36

[GoogleCodeExporter]

This is really needed. There are somethings that one might want to change at 
runtime, or simply not put in the annotation. E.g., formUri might change when 
'pro' features are enabled; basic auth password might change and shouldn't be 
visible in the source (open source project, etc.).

Original comment by nikolay....@gmail.com on 7 Oct 2011 at 4:32

[GoogleCodeExporter]

I really had a need for programmatic configuration so I modified the ACRA.java 
init method slightly to inject a ReportsCrashes instance, like:

 public static void init(Application app, ReportsCrashes reportsCrashes) {

        if (mApplication != null) {
            throw new IllegalStateException("ACRA#init called more than once");
        }

        mApplication = app;
        mReportsCrashes = reportsCrashes;
        /*
        mReportsCrashes = mApplication.getClass().getAnnotation(ReportsCrashes.class);
        if (mReportsCrashes == null) {
            Log.e(LOG_TAG, "ACRA#init called but no ReportsCrashes annotation on Application " + mApplication.getPackageName());
            return;
        }
        */
.....

I had to remove the check for the annotation... should be relatively 
straightforward to add this and still be backwards compatible..

Original comment by magnus.o...@gmail.com on 1 Nov 2011 at 2:48

[GoogleCodeExporter]

I have started to implement dynamic settings for res* annotation parameters as 
a workaround for projects based on Android Library Projects.

I have added setters to org.acra.ACRA which have to be called before 
ACRA.init().

Do you really need full dynamic setters (which could be called at any moment 
during the application lifecycle ?) or would you all be happy with pre 
ACRA.init() calls ?

Kevin

Original comment by kevin.gaudin on 1 Nov 2011 at 10:46

[GoogleCodeExporter]

Personally, I need these settings to be configurable at runtime so that a user 
could change a configuration option from within the application.

Original comment by cherry...@gmail.com on 1 Nov 2011 at 10:59

[GoogleCodeExporter]

My use-case is slightly different - the app I am working on currently needs to 
support multiple "skins", for each "skin" the app needs a different error 
report URL configured. I have no need to set all things dynamically after init, 
we just read the URL property from a config file at app-startup and init ACRA 
with it.

Original comment by magnus.o...@gmail.com on 2 Nov 2011 at 8:57

[GoogleCodeExporter]

I am OK with one-time initialization (before ACRA.init()). 

Original comment by nikolay....@gmail.com on 2 Nov 2011 at 9:10

[GoogleCodeExporter]

Full programmatic configuration has been implemented in the trunk.

Original comment by kevin.gaudin on 22 Dec 2011 at 9:04

• Changed state: Fixed
• Added labels: Milestone-Release4.3

[GoogleCodeExporter]

Original comment by kevin.gaudin on 7 Sep 2012 at 9:31

• Changed state: Verified