Persist a field to map back from a DownloadTask to the app own's entity

[mr-mmmmore]

Hi,

Here is a scenario for which I don't see a simple solution:

1. The user enqueues a list of tasks, from a list of Books. A map taskId → Book.id is kept somewhere in the app, but not persisted on the device.
2. The progress of downloads is monitored and the books are updated using the map.
3. The user leaves the app so the app goes to background and is later killed by the os. Meanwhile the downloads should continue (right?).
4. The user comes back to the app. The download state (the taskId → Book.id map) is lost, so the app get all the tasks using loadTasks() to correctly display the download states.
5. But, a DownloadTask doesn't have a field that can help in mapping back this task to a Book. Relying on fields such as filename or url is not robust as these may change (for example if the url contains changing GET parameters, of if the filename changes).

If in 1. we had persisted the map on the device, then this wouldn't be a problem, we would load it in 5. and would be able to map task states to Books.

But, it's somewhat awkward to have to do this since the plugin maintains a database entirely dedicated to storing the download queue state.

The above problem could be solved by adding a DownloadTask.extra field (dynamic or String) and save it to the database. Then, the Book.id would be stored into it (set in the enqueue method) and retrieved with loadTasks() or loadTasksWithRawQuery(). Ideally the callback would also reveive it as a fourth parameter upon status updates.

Note: I was initially considering using the headers field to do so (by adding an X-Book-Id header for example), but this field is only settable from the enqueue method and not present in the DownloadTask class, although it's part of the database record. Also adding it in DownloadTask could be usefull.

[mr-mmmmore]

Anybody on this?

It seems to me that this is a must-have feature because, if I understood well how the plugin works:

• The case where the app is killed while the download queue continues in the background WILL occur at some point. I haven't experienced it yet, but the plugins is designed to work this way, correct me if I'm wrong.
• When the app starts again we have to query the tasks using loadtasks() in order to update the states in the app according to the latest download updates.
• In order to bind these tasks back to the entities in the app (task.id -> Entity), we have no other way than persisting this binding in some way in the app.

As said before, this imposes the need to manage a database in parallel to the plugins's database, and keep it in sync with it, which is teddious and error-prone and could be avoided by just adding the proposed extra field.

[mr-mmmmore]

This can be closed as it is a duplicate of #195