Open levibostian opened 6 years ago
Funny, after creating this issue I have found a reason to keep PendingTasksFactory
!
So, while I continue to use Wendy in my everyday apps, I will decide what to do with PendingTasksFactory
which would include keeping it.
Some of the inspiration and design of the Wendy lib is from evernote/android-job. If you notice from the docs, it uses a tag/factory functionality as well to map a job to a string.
With that in mind, I am not sure if there is currently a way to fix this.
The purpose of the
PendingTasksFactory
is to construct instances ofPendingTask
subclasses when Wendy has decided it is time for thatPendingTask
to run.Problems with
PendingTasksFactory
:PendingTask
to add/remove/change dependencies.PendingTasksFactory
when you create newPendingTask
subclassesPendingTask.tag
exists is to be used withPendingTasksFactory
. I describe thetag
property as "in the way" as it doesn't identify the data and how it should be run by Wendy, it identifies the subclass. The tag is still required, but housing the information someway else would be a benefit to the API.Can we remove the need to create a
PendingTasksFactory
?No: As this issue explains, there needs to be a way to construct instances of each
PendingTask
along with their dependencies.Yes: Maybe we could create a compile time annotation processor to generate a
PendingTasksFactory
for you? Android libraries, especially those like Moshi, are able to take a constructor of a class and generate code to construct instances of that class. Instead of using aPendingTask.tag
property, we could create an annotation that has a property inside of that annotation fortag
. This solution would cross off each item on the list above of problems with the factory.