Conversation
martinzigrai
left a comment
There was a problem hiding this comment.
Awesome job! 👏 Left some comments here.
There was a problem hiding this comment.
To make it completely thread-safe, we should ensure all external calls happen after releasing the lock. The abstract flow should look like this:
For setting the listener (flush):
-
Lock -> Assign the listener -> Copy cache to a temp list -> Clear cache -> Unlock.
-
Iterate over the temp list and invoke the listener.
For dispatching a new event:
-
Lock -> Check if the listener exists.
-
If YES: Grab the listener reference -> Unlock -> Invoke the listener.
-
If NO: Add the event to cache -> Unlock.
There was a problem hiding this comment.
same as in the ExecutionStateDispatcher.kt
There was a problem hiding this comment.
Since this handles execution and device states too, should we rename it? (e.g. PluginSecurityHandler.kt)
| /// Android only | ||
| locationSpoofing, | ||
|
|
||
| /// This method is called when automation is detected |
There was a problem hiding this comment.
Missing 'Android only' comment here
| @@ -26,9 +25,4 @@ class RaspExecutionStateCallback extends pigeon.RaspExecutionState { | |||
|
|
|||
| /// Callback invoked when all security checks are completed. | |||
| final VoidCallback? onAllChecksDone; | |||
There was a problem hiding this comment.
Should we rename this to onAllChecksFinished to match the other platforms?
| @@ -90,7 +88,8 @@ internal object TalsecThreatHandler { | |||
| * [EventSink] is not destroyed but also is not able to send events. | |||
| */ | |||
| internal fun suspendListener() { | |||
There was a problem hiding this comment.
Shouldn't we also include the executionStateDispatcher in the suspend/resume logic here? Currently, only the threatDispatcher is handled
freeRASP X.Y.Z
Pre-release checklist
pubspec.yamlversion updatedPost-release checklist
Type of Changes
Description