-
Notifications
You must be signed in to change notification settings - Fork 658
Tasker Plugin #1435
base: master
Are you sure you want to change the base?
Tasker Plugin #1435
Conversation
…ill need to implement dynamic event activity.
Wow, that's very nice! I will review this (and some other PRs) tomorrow. |
Though this might bring us the NonFreeAdd AntiFeature ("promoting" a non free app) at F-Droid, I can't wait to see this 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made it through the review 😄, looks great, thanks again 👌
Since I don't have an XWatch, I'll adapt it to the Bip to try it out. AFAICS it's just a few lines of code.
@Override | ||
public boolean equals(Object o) { | ||
if (this == o) return true; | ||
if (o == null || getClass() != o.getClass()) return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: usually one uses instanceof instead of comparing the classes by identity. Otherwise it would be impossible for (technical) subclasses to be equal to the superclass. One example would be subclassing for testcases.
* | ||
* @param <T> Bluetooth LE support class extends {@link AbstractBTLEDeviceSupport} | ||
*/ | ||
public class TaskerBleProfile<T extends AbstractBTLEDeviceSupport> extends AbstractBleProfile<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a very creative idea to make tasker support pluggable and reusable 😄
Subclasses of AbstractBleProfile
are reusable implementations of BLE profiles (e.g. for setting time, alarms, heart rate, etc.).
This is rather an event handler that does no further BLE communication. Need to think&check if we can add an interface for that, in addition to the profiles without duplicating code (just thinking loud for now, no action required).
} | ||
|
||
public TaskerEventType withIndex(int index) { | ||
TaskerEventType taskerEventType = new TaskerEventType(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The builder-like approach (create().withIndex().withLocalization()) looks nice, but IMHO one or two constructors would be more sensible, since the events would be immutable then.
/** | ||
* Creates a {@link android.widget.Toast} for the user to show that Tasker is enabled but no task is defined. | ||
*/ | ||
public static void noTaskDefinedInformation() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use GB.toast()
that does all the event loop handling (and logging in addition) for you.
return TaskerEventType.BUTTON; | ||
} | ||
if (data[0] == XWatchService.COMMAND_CONNECTED) { | ||
return TaskerEventType.CONNECTION; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that such events would rather be handled generically via GBDevice#getState() changes (see GBDevice#sendDeviceUpdateEvent()).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The AbstractDeviceSupport#handleGBDeviceEvent() methods are probably also good candidates for a generic implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you give me more info on that.
I will be on it tomorrow. Thanks for the review! |
@cpfeiffer Ive done some of your fixes but i dont know what to do with getState. |
Thanks for the updates! GBDevice#getState() is used all over the place. It's the state describing whether a device is disconnected, connected, initializing, busy, etc. I thought that these state changes would be good candidates for tasker interaction, especially since they could be handled in a device independent way. The *Support-classes usually only set the state, but don't react to any changes. |
Please let me know if I should explain in more details. |
Tasker Plugin
Features
Implemeted devices
Quickstart
To implement a device add a
TaskerDevice
likeall you need is a
DeviceType
and aTaskerSpec
. Last thing is to add theTaskerBleProfile
to yourAbstractBTLEDeviceSupport
likeTasker Hook
Tasker hook is done with
TaskerBleProfile
as anAbstractBleProfile
(correct me if this is not the best way).Tasker Service
The
AbstractTaskerService
is used to scheduleTaskerTask
's. The threshold is used to cumulate calls. TheTaskerEvent
is then send with the specific amount of calls within that threshold.The default service for the hook is
SpecTaskerService
.It uses the
TaskerSpec
'sTaskerSettings
as configuration. There is aTaskerService
implementation for programmatic use.Tasker Event
The default
TaskerEventType
's areYou can easly add more types via
TaskerEventType
class. It does not effect the already implemented devices.Don't forget to add your type to
And for device support add it to the device's
TaskerSpec
Tasker Settings
Tasker user settings are implemented via
TaskerActivity
As main entry point from
SettingsActivity
. It listsTaskerDevice
's and has a enabled preference for overall tasker support.Forwards to
TaskerEventsActivity
.TaskerEventsActivity
Lists all event types from
TaskerSpec
'sgetSupportedTypes()
method.Forwards to
TaskerEventActivity
.TaskerEventActivity
Has preferences for
ToDo
Commit Information