Feature
s are the main draw of Dairy, and they power a lot of the additional
utilities provided by Core and other libraries.
Feature
s add a lot of additional hooks to the OpMode lifecycle, and are
capable of doing a lot of powerful work and tasks in the background of user
code.
A hook is an update callback. Basically, when an event occurs in code, if that code is written to expose hooks, it will all all the hooks which are attached to that event.
Dairy adds hooks to the OpMode life cycle, which means that when your OpMode
code runs (init
, init_loop
, start
, loop
, stop
), Dairy makes it so that
other Objects in code receive updates about these events occurring, without any
added code for you.
If you are using OpMode, you donāt need to add any code, if you are using LinearOpMode, then additional lines of code to enable the hooks MUST be added.
The āpreā hooks run in order of Feature
s being activated, while āpostā hooks
run in the reverse order. This ensures that less important Feature
s are always
enclosed by the code of the more important ones.
This is important to keep in mind when writing a Feature
.
Feature
s generally fall into two categories:
Feature
s that are instantiated during an OpMode, generally during
init
. These Feature
s generally register
themselves with the
FeatureRegistrar
when they are instantiated, or it must be done manually.
Oftentimes they are meant to only exist for one OpMode, and so deregister
themselves when it ends.Feature
s that are global singletons and are registered via
Sinister
, rather than by themselves. They exist all the time, and use the
Dependency
system, usually with annotations to attach to OpModes on demand.Dairy offers utilities that come in both forms.
In your own code, you might use the static singleton approach for subsystems, if
youāre doing them yourself, rather than with Mercurial
, or a big global
utility system.
In comparison, the dynamic approach is good for when the utility is needed on demand, and just needs to receive updates about the OpMode.
Weāll take a look at both the static and the dynamic approach.
Static:
@BulkReads.Attach
.
featuredev.[jdoc|kdoc]
package of the Dairy
examples.Dynamic:
featuredev.[jdoc|kdoc]
package of the Dairy
examples.Iām not going to actually write the proper code this time, as would add a decent
number of lines of code to the examples, and it would just add noise to what
this is being demonstrated. If you donāt like Dairy Controller
s, then you
could finish off this class and use it. This could easily be done with a
pre-done PID class from another library, or you could fill in the blanks here by
writing it yourself, it isnāt hard.
Now, lets look at how to use these in an OpMode:
featuredev.[jdoc|kdoc]
package of the Dairy
examples.Feature
s are the main draw of Dairy, and they power a lot of the additional
utilities provided by Core and other libraries.
Feature
s add a lot of additional hooks to the OpMode lifecycle, and are
capable of doing a lot of powerful work and tasks in the background of user
code.
A hook is an update callback. Basically, when an event occurs in code, if that code is written to expose hooks, it will all all the hooks which are attached to that event.
Dairy adds hooks to the OpMode life cycle, which means that when your OpMode
code runs (init
, init_loop
, start
, loop
, stop
), Dairy makes it so that
other Objects in code receive updates about these events occurring, without any
added code for you.
If you are using OpMode, you donāt need to add any code, if you are using LinearOpMode, then additional lines of code to enable the hooks MUST be added.
The āpreā hooks run in order of Feature
s being activated, while āpostā hooks
run in the reverse order. This ensures that less important Feature
s are always
enclosed by the code of the more important ones.
This is important to keep in mind when writing a Feature
.
Feature
s generally fall into two categories:
Feature
s that are instantiated during an OpMode, generally during
init
. These Feature
s generally register
themselves with the
FeatureRegistrar
when they are instantiated, or it must be done manually.
Oftentimes they are meant to only exist for one OpMode, and so deregister
themselves when it ends.Feature
s that are global singletons and are registered via
Sinister
, rather than by themselves. They exist all the time, and use the
Dependency
system, usually with annotations to attach to OpModes on demand.Dairy offers utilities that come in both forms.
In your own code, you might use the static singleton approach for subsystems, if
youāre doing them yourself, rather than with Mercurial
, or a big global
utility system.
In comparison, the dynamic approach is good for when the utility is needed on demand, and just needs to receive updates about the OpMode.
Weāll take a look at both the static and the dynamic approach.
Static:
@BulkReads.Attach
.
featuredev.[jdoc|kdoc]
package of the Dairy
examples.Dynamic:
featuredev.[jdoc|kdoc]
package of the Dairy
examples.Iām not going to actually write the proper code this time, as would add a decent
number of lines of code to the examples, and it would just add noise to what
this is being demonstrated. If you donāt like Dairy Controller
s, then you
could finish off this class and use it. This could easily be done with a
pre-done PID class from another library, or you could fill in the blanks here by
writing it yourself, it isnāt hard.
Now, lets look at how to use these in an OpMode:
featuredev.[jdoc|kdoc]
package of the Dairy
examples.