Listen to all PendingTask updates by a piece of data instead of by ID.

[levibostian]

Let's say that you are creating vacation planning app. On the main screen, you have a list of all of the different vacations that you are planning on going on.

When you click on one of the vacation ideas in the list, you are taken to a new list that lists your itinerary. One list item per day of your vacation. Inside of each day you can add text and upload images.

This mobile app uses Wendy to allow users to create new vacations, add or remove days to their itinerary, add text or images to the itinerary.

In the main list UI of the app, I would like to show a progress bar for each vacation idea that has any Wendy PendingTasks that have not been successfully executed yet. This is to tell the user they have unsaved changes within the app.

I am proposing adding the ability within Wendy to listen to each of the vacation ideas individually and be notified if they have any pending tasks or not for each of them.

[levibostian]

One thought that I had was that you could have any class, give it to Wendy saying, "Map this object to this PendingTask" where Wendy would then keep a reference to that object (via the object's class name perhaps) and the task_id of the PendingTask.

Example: I have a model, GroceryStoreItem. I have 3 PendingTask subclasses that an instance of GroceryStoreItem could align with: CreateGroceryStoreItem, UpdateGroceryStoreItem, DeleteGroceryStoreItem.

It would be a pain for the developer to have to hold onto reference of 1+ separate task_ids onto the GroceryStoreItem to show in the UI to the user of the app saying, "this grocery store item is not yet fully synced".

Potential issue: What if the developer later on devices to rename GroceryStoreItem to GroceryStoreModel later?

Maybe I create an annotation processor? Be able to have a model have an annotation saying what PendingTask subclasses it could be associated with? This would fix the rename issue because we can care about the annotation value instead of the name of the class.

[Grohden]

Potential issue: If we have foomodel with id of 1 and barmodel with id of 1?

@levibostian we already have the groupId, could it be used to solve that? something like:
WendyConfig.addGroupRunnerListener(groupId) where we listen to the group tasks instead of the data id

[levibostian]

@Grohden I edited the description of this issue because I feel I did not do a good job originally explaining it. Read the edited description and see if it makes sense to you.

Great suggestion about using the groupId! I am asking myself why I did not think of that before. That seems like it would be a good solution to the problem.

I am not a fan of adding more and more listeners to the WendyConfig class. I feel we could think of a better API for that. However, that is a separate issue we can create for a later time.

For now, adding a addGroupRunnerListener(groupId, listener) to WendyConfig is a great way to solve this problem.

[levibostian]

From the suggestion by @Grohden in this issue, I will close this issue at this time and assume that this new feature request issue will solve this problem.

We can re-open this issue if this feature request does not solve the problem or there is another idea brought up.