Releases: lingochamp/FileDownloader
Releases · lingochamp/FileDownloader
v0.3.5
Fix
- Fix(SQLiteFullException): Cover the case of SQLiteFullException during the entire downloading process, and ensure the exception can be carried back to
FileDownloadListener#error
. Closes #243 - Fix(directory-case): Fix in the case of the provided path is a directory, and the task already completed, if you start the task again you will receive
FileDownloadListener#completed
directly, but thetargetFilePath
may be null in theFileDownloadListener#completed
callback method. Closes #237
Enhancement
- Improve Practicability: Add thread name to all threads used in FileDownloader.
- Improve Performance: Change the count of core thread for block-completed-thread-pool: 5->2, reduce redundant resource waste.
v0.3.4
New Interfaces
- Add
FileDownloader#clear
: clear the data with the task id in the filedownloader database. Closes #218.
Enhancement
- Improve Practicability: Add return value to the method
FileDownloader#start(FileDownloadListener, boolean)
: Whether start tasks successfully. Closes #215. - Improve Practicability: Pause tasks with the same download-id rather than just pause one task through there are more than one task in downloading.
Fix
- Fix(init-crash): Fix the crash about the list of running-app-process-info from
ActivityManager
is null when to init FileDownloader. Closes #210. - Fix(minor-crash): Fix the NPE-crash when to execute receiving snapshot-message after FileDownloadService already onDestroy. Closes #213.
- Fix(message-keep-flow): Delete the target file before start downloading, ensure can't get the
completed
status when another same task is downloading. Closes #220 - Fix(start-serial): Assemble non-attached-tasks to start rather than assemble tasks just refer to FileDownloadListener, fix no possibility to start two queues with the same
FileDownloadListener
. Closes #223. - Fix(free-messenger): Free the messenger of Task before call back 'over-message' to FileDownloadListener instead of after callback, ensure Task can be reused in FileDownloadListener callback method. Closes #229.
Others
- Upgrade dependency okhttp from
3.3.1
to3.4.1
.
v0.3.3
New Interfaces
- Add
FileDownloadUtils#getTempPath
: Get the temp path is used for storing the temporary file not completed downloading yet(filename.temp
). Refs #172. - Add
FileDownloader#getStatusIgnoreCompleted(id:int)
: Get the downloading status without cover the completed status(If completed you will receiveINVALID
). - Add
FileDownloader#getStatus(id:int, path:String)
: Get the downloading status. - Add
FileDownloader#getStatus(url:String, path:String)
: Get the downloading status. - Add
FileDownloadUtils#isFilenameConverted(context:Context)
: Whether tasks from FileDownloader Database has converted all files' name fromfilename
(in old architecture) tofilename.temp
, if it is not completed downloading yet. - Add
FileDownloadUtils#generateId(url:String, path:String, pathAsDirectory:boolean)
: Generate aDownload Id
which can be recognized in FileDownloader. - Add
BaseDownloadTask#setPath(path:String, pathAsDirectory:boolean)
: IfpathAsDirectory
istrue
, thepath
would be the absolute directory to store the downloading file, and thefilename
will be found incontentDisposition
from theresponse#header
as default. - Add
BaseDownloadTask#isPathAsDirectory
: Whether the result ofBaseDownloadTask#getPath()
is adirectory
path ordirectory/filename
path. - Add
BaseDownloadTask#getTargetFilePath
: Get the target file path to store the downloading file. - Add
FileDownloadQueueSet#setDirectory
: Set thedirectory
to store files in this queue.
Enhancement
- Improve Practicability: Support the
path
of the task as the directory to store the file, and in this case, thefilename
will be found incontentDisposition
from theresponse#header
as default. Refs #200. - Improve Practicability: Using the temp path to store the file not completed downloading yet(
filename.temp
). Refs #172. - Improve Performance: FileDownloader doesn't store completed tasks in Database anymore, and check whether the task has completed downloading with
File#exists()
directly. Refs #176, #172. - Improve Robust: Choosing the task which status is
INVALID
orprogress
to receivecompleted
message preferentially, to ensure the callback ofprogress
can be handled. Refs #123 - Improve Robust: Expanding task-sync-lock to the outside of getting-same-id-downloading-task, to fix some messages can't be consumed because status changed during getting-same-id-downloading-task and waiting for task-sync-lock.
Fix
- Fix(DB-maintain): Keeping models, whose status is
pending
and downloaded so far bytes is more than 0 because it can be used for resuming from the breakpoint. Closes #176. - Fix(crash-NPE): FileDownloader might occur NPE when the download-listener was removed, but the task is still running in FileDownloader. Closes #171.
v0.3.2
New Interfaces
- Add
BaseDownloadTask#setCallbackProgressMinInterval
: Set the minimum time interval between each callback of 'progress'. Closes #167. - Add
FileDownloader#setMaxNetworkThreadCount
: Change the number of simultaneous downloads(the number of the simultaneously running network threads) at the code side. Closes #168. - Add
FileDownloader#init(Context,OkHttpClientCustomMaker,int)
: Accept initializing the number of simultaneous downloads(the number of the simultaneously running network threads) with the FileDownloadService initializes. Closes #168.
Enhancement
- Improve Robust: Ensure the minimum time interval between each callback of 'progress' is 5ms, To prevent internal callback of 'progress' too frequent happening. Closes #167.
- Improve Practicability: Print the 'warn' priority log when a request does something in the FileDownloadService but it isn't connected yet.
- Improve Performance: Using the
SparseArray
instead ofHashMap
for mapping allFileDownloadModel
.
Fix
- Fix(crash): Fix provided wrong params in formatting character string when to starting download runnable occur the unexpected downloading status.
- Fix(force-re-download): Fix the wrong logic: In the case of
BaseDownloadTask#setForceReDownload(true)
and the task has already downloaded will trigger 'warn' callback. Closes #169 . - Fix(class-type): Keep the class type of
SocketTimeOutException
, and no longer care about whether the message of Throwable is empty, this is very redundant.
Others
- Upgrade dependency okhttp from
3.2.0
to3.3.1
.
v0.3.1
v0.3.0
v0.2.9
New Interfaces
- Add
BaseDownloadTask#isUsing():boolean
: Whether this task object has already started and used in FileDownload Engine. Closes #137 .
Fix
- Fix(high-concurrency-NPE): Providing the default snapshot when a task's status is unexpected, preventing the NPE is occurred in this case.
- Fix(response-416): Covering the response status code is 416 or still resume from breakpoint when it's so far bytes more than or equal to total bytes.
v0.2.8
New Interfaces
- Add
BaseDownloadTask#getId():int
: deprecategetDownloadId()
, and using thegetId()
instead, forBaseDownloadTask
.
Enhancement
- Improve Robust: Refactor the launcher for launching tasks more make sense, and expire tasks with listener or expire all waiting-tasks more stable.
- Improve Robust: Refactor the architecture which is used to handle the event send to
FileDownloadListener
, the new architecture just like a messenger and message-station, each tasks would write snapshot messages to message-station. - Improve Robust: Cover all high concurrent situations about pausing a task, remove some expected warn logs about it.
- Improve Performance: Reduce the FileDownloader database I/O.
- Improve Performance: Reduce creating object(less allocating memory request, friendly to GC) for each call-back, Taking a message snapshot for a status updating, and through whole communication architecture just use it.
Fix
- Fix: Provide the definite locale for formatting strings, prevent unexpected-locale as Default happening. Closes #127
v0.2.7
New Interfaces
- Add
FileDownloader#setTaskCompleted(taskAtomList:List<FileDownloadTaskAtom>)
: Used to telling the FileDownloader Engine that a bulk of tasks have already downloaded by other ways.
Enhancement
- Improve Robust: Throw the Fatal-Exception directly when you request to bind the FileDownloadService in the
:filedownloader
process manually. Closes #119 .