Provide callback instead of doing UI tasks of calling app #49

[sunkup]

Purpose

cert4android shouldn't show the TrustCertificateActivity and a notification by itself. Instead it should execute a callback which is provided by the calling application.

Short description

• stop passing the foreground state (appInForeground) to cert4android
• start passing callback function getUserDecision and the coroutine scope in which it should run
• adapt tests

Note

I would like to avoid the delay(1000) in testCheck_MultipleDecisionsForSameCert_Negative, but I could not make it work using a countdown latch and using a mutex quickly became complicated too. I also thought of launching a 6th seperate coroutine which would watch registry.pendingDecisions.size with a while loop and release the semaphore as soon as 5 pending decisions are reached, but could not make that work either. In the end the delay(1000) is quite simple and seems to work well, but let me know if you find a cleaner way.

[rfc2822]

Looks good! Can you add more documentation for parameters, especially scope and what it does exactly (cancel waiting for a decision when the scope is cancelled I guess)?

[rfc2822]

The Continuation logic is still hard to understand for me because it's so low-level. I have tried to add a few comments to make it better understandable.

Looks good otherwise.

Please have a final look at 47b9aca, then we can merge

[sunkup]

The Continuation logic is still hard to understand for me because it's so low-level. I have tried to add a few comments to make it better understandable.

Makes sense. I added a missing @param and also saw that we can replace the iterator with a forEach.

It's still complicated, but moving the scope.launch{} inside the synchronized block was a good idea. I feel it's easier to reason about now. It's a lot better than before 👍

[rfc2822]

Ok bad news from my side regarding cert4android. I must say that I don't understand the complexity of the current flow, including what exactly the scope does, what happens when it's cancelled, what happens when the check is cancelled, etc.

So I'm afraid that merging this may introduce new bugs in very rare cases (which we want to reduce).

I had originally thought that we could just "pull out" the UI as a first part of the redesign, but I guess I had underestimated the consequences and complexity that's still in there.

So an unfortunate (because of the work you have already put into this) question: shall we wait with this until we have the time to redesign the cert4android API from scratch in a better way? It's not perfect until it now is but it works in most cases.

When we would redesign the API at a later time, we could take the time to think about all known cases and side-cases.

[sunkup]

As you like. I learned a lot, so it was not useless work for me 👍

It's true that with a better designed API we could probably do this way cleaner.

[rfc2822]

So let's only keep https://github.com/bitfireAT/cert4android/pull/50/files/12f1b4596fd26750094877df8be908c4930bf61e#r1991806967 ?

.. in a new PR.

[rfc2822]

So let's only keep https://github.com/bitfireAT/cert4android/pull/50/files/12f1b4596fd26750094877df8be908c4930bf61e#r1991806967 ?

.. in a new PR.

Created #52 for that new PR