While AppHooks were cool, the real draw of Sinister is the Filtering, the AppHooks are built upon it after all!

​
What is Classpath Filtering?

Classpath filtering allows you to run some reflection code on every class in the classpath. The SDK uses this to look for their own AppHooks, and is how they look for your OpModes with the @Teleop, @Autonomous and @Disabled annotations.

Unlike the SDK, Sinister is ‘bootstrapping’, which means it discovers SinisterFilters through its own scanning process, rather than requiring direct registration.

This means that libraries can easily declare their own SinisterFilters and Sinister will automatically find and run them, as opposed to the SDK, where filters can only be added by modifying the FtcRobotControllerActivity.java file. This needs to be done manually for every repository that needs an additional filter added, and while as of SDK version 9.X.X this is still possible, however, FIRST have announced that they are no longer going to be supporting this going forward.

Nice!

Ok, how do we do it?

Lets implement a SinisterFilter that:

  1. Looks for instances of classes that implement our custom EventReceiver interface with our own custom annotation.
  2. Stores the instances it finds, and notifies all EventReceivers when the user publishes an Event.

EventReceiver:

Filter:

These examples are also available in the TeamCode module in the Dairy mono repo.

​
TargetSearches

TargetSearches allow you to prefilter the packages that your filter will search.

You can easily create your own, they have standard include and exclude methods that are super intuitive to use.

Each of these can be subclassed and used as a base, with your own modifications:

Easy!

AppHooks