This document will describe how to add new functionality to Easer, especially how to add new Event(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).)
Add new Event/Operation
In Easer, all Events and Operations are implemented as plugins, located in the package
ryey.easer.plugins. More precisely, Events are under
ryey.easer.plugins.event，Operations are under
You can use the provided scripts in the “utils” directory to automatically generate the skeleton of plugin; 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 plugin, 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 plugin. Then, after registering in
PluginRegistry (see below), the new plugin 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 plugin in
- For new Events, inherit
- For new Operations, inherit
To register you new plugin in
PluginRegistry, you only need to add one line new code in its
init() method (following existing codes).
I strongly recommend you to follow the way that existing plugins do and put your new plugin into the relevant package.
OperationPlugin are commented in some detail.
OperationPlugin will need to implement it relevant UI, by implementing a subclass of
Some common subclasses are already in
ryey.easer.plugins 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.
EventPlugin) will be used. Because each component of a plugin 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 plugin. The use of a plugin starts with the calling of methods in the entrance.
- Data of a plugin. 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 plugin. 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 of the plugin, 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
EventPlugin, 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.