Increasing flexibility of CrashDialog

[F43nd1r]

See #489. This is now fully backwards compatible, so it does no harm.

[william-ferguson-au]

What is org.acra.CrashReportDialogImpl?

[F43nd1r]

A generated class which extends the class annotated with @AcraDialog, if there is one.

[F43nd1r]

Example:
This is an (admittedly useless) simple implementation using a different superclass

@AcraDialog
public abstract class MyCrashReportDialog extends AppCompatActivity implements ICrashReportDialog {
    @Override
    public void init(@Nullable Bundle savedInstanceState) {
        Toast.makeText(this, "This is a CrashReportDialog", Toast.LENGTH_SHORT).show();
        sendCrash(null, null);
    }
}

The compiler will now generate this for it:

public final class CrashReportDialogImpl extends MyCrashReportDialog {
    private final CrashReportDelegate delegate;

    public CrashReportDialogImpl() {
        delegate = new CrashReportDelegate(this);
    }

    @Override
    public void onCreate(Bundle arg0) {
        super.onCreate(arg0);
        if(delegate.loadFromIntent(getIntent())) {
            init(arg0);
        }
        else {
            finish();
        }
    }

    @Override
    public void cancelReports() {
        delegate.cancelReports();
    }

    @Override
    public void sendCrash(@Nullable String arg0, @Nullable String arg1) {
        delegate.sendCrash(arg0, arg1);
    }

    @Override
    public ACRAConfiguration getConfig() {
        return delegate.getConfig();
    }

    @Override
    public Throwable getException() {
        return delegate.getException();
    }
}

[william-ferguson-au]

Does this resolve #485?
Does this resolve #486?

[F43nd1r]

Yes and yes. Users can choose any subclass of activity for their CrashReportDialog. They will have to use the compiler though.

[william-ferguson-au]

I don't understand how this is supposed to work at all.

There is nothing here that will generate CrashReportDialogImpl.
That is not how annotations work.

[F43nd1r]

No, annotations cannot do that. Annotation processors can.
Due to some limitations annotation processors cannot be packaged in an aar, which is why I currently keep it in its own Repo: https://github.com/F43nd1r/acra-compiler

[william-ferguson-au]

But the annotation processor is not referenced anywhere within ACRA.
How is it meant to be used?

[F43nd1r]

Currently the user has to add a separate dependency. I'll investigate what happens if Acra references it directly.

[F43nd1r]

If the dependency is added in acra, it has to be compiled. This adds an unnecessary 700kb to the final apk, which is not acceptable.

So, I'll go with the separate dependency.
I just checked around and all the big annotation processing libraries (ButterKnife, AndroidAnnotations) seem to do the same: One compile and one provided (or apt) dependency, where the provided one includes the annotation processor.

[william-ferguson-au]

Thanks, but I think #487 and #488 are the better way to go.

[william-ferguson-au]

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