This document will describe how to add new functionality to Easer, especially how to add new Event(s) (and Condition(s)) and/or Operation(s). It may also say something about the design of the structure of Easer.
(Notice: Profile is merely a collection of Operation(s), so if you want to extend the function of Profile, you just need to create new Operation(s).)
Additionally, v0.7.7 introduced
USource to unify the authoring for Event and Condition. This mechanism is still consider as early stage, so this document does not describe it yet (but it’s similar to the previous ways).
Add new Event/Operation
In Easer, all Events and Operations are abstracted as skills, located in the package
skills. More precisely, Events are under
skills.event，Operations are under
You can use the provided scripts in the “utils” directory to automatically generate the skeleton of a skill; or creating everything manually.
Use the script
Under “utils” directory, two scripts are provided (
new_operation.py) to automatically generate the skeleton of a new Event/Operation skill, as well as other related resources (e.g. tests).
After executing the script, you only need to fill in each of the “TODO”s in the directory for the new skill. Then, after registering in
LocalSkillRegistry (see below), the new skill will appear in Easer.
Detailed explaination of each component are presented below.
In order to add a new Event or Operation, there are two main steps:
- Implement the functions of your new Event or Operation (by inheriting corresponding interfaces and implementing relevant contents)
- Register your new skill in
- For new Events, inherit
- For new Operations, inherit
To register you new skill in
LocalSkillRegistry, you only need to add one line new code in its
init() method (following existing codes).
Strongly recommend to follow the way that existing skills do and put your new skill into the relevant package.
OperationSkill are commented in some detail.
OperationSkill will need to implement it relevant UI, by implementing a subclass of
Some common subclasses are already in
skills or its sub-package. You can use them as you wish.
Usage of related interfaces / abstract classes
DataFactory are the general interfaces, and only their sub-interfaces (e.g.
EventSkill) will be used. Because each component of a skill will use its data, the data class (i.e. its subclass of [the sub-interface of]
StorageData) will be used as the generics parameter.
- Entrance of a skill. The use of a skill starts with the calling of methods in the entrance.
- Data of a skill. Every instance is “fixed” after creation; modification of data creates new instances.
- Generally, the internal value (e.g. fields of the class) will only be used inside the skill. Therefore, there is no access interfaces to the outside.
- The data will be persisted (e.g. saving to a file), so there is
serialize()interface defined; see
- Data will be passed across Android components, so
Parcelableinterface is implemented.
- Data during runtime is created from here.
parse()interface is used to create instance of corresponding
StorageDatafrom previous persisted data.
- The UI part when editing the skill, used to interact with the user.
- When “loading”, if there is initial data, UI will be initialized with this data.
- When “saving”, corresponding
StorageDatawill be created for future process (e.g. persist).
- Used in
EventSkill, for monitoring (listenting to) events and notify state change.
- Generally, monitoring is done by registering
- When satisfied, call
changeSatisfiedState()method to notify (relevant Easer components) about the state change.
- When Easer is running, every Event in the EventTree will has it own
Slotcreated (this behaviour is to be optimized).
- Used in
- The place where an Operation is carried out / loaded.