Faster downloads about java-youtube-downloader

[sealedtx]

@Grodou Thank you for reporting this problem. Actually I didn't notice it before. I will check it.
Can you show exact example of usage of these extra params, please?

[Grodou]

@sealedtx Hi, you're welcome :)
I don't think there's any unit test on another itag than i18. You can try i135 on DESPACITO_ID.

Can you show exact example of usage of these extra params, please?

For a 1st part of 2 Mo: &cver=2.20200903.02.02&range=0-2097151&rn=1

[sealedtx]

@Grodou Where did you get these tips to speedup download by partions? Can you provide source link if any present. Thank you.
BTW: I am reviewing some of your code in last commit, great work, but, please, avoid new Java language features (such as lambdas, try-with-resources, etc), because this library should support old Android versions, where, as I know, java 8+ is not supported.

[Grodou]

@sealedtx Hi, here are some responses.

Where did you get these tips to speedup download by partions?

By looking at network requests in Firefox.

avoid new Java language features (such as lambdas, try-with-resources, etc)

I understand your concern. I avoid try-with-resources (not supported until API 19), there's only a couple in a unit test. I thought it was not a problem there, but I'll remove it.
Lambdas are supported: https://developer.android.com/studio/write/java8-support#supported_features. I can remove them too.
But streams, and some classes like Predicate, are not. YoutubeVideo.findFormat(filter) will not work for Android. I created a Filter class to replace it.

Should I create a pull request ?

[sealedtx]

@Grodou Thank you for sharing the link, because I don't follow android dev news.

In addition to the Java 8 language features above, plugin versions 3.0.0 and later extend support for try-with-resources to all Android API levels.

If you're building your app using Android Gradle plugin 4.0.0 or higher, the plugin extends support for using a number of Java 8 language APIs without requiring a minimum API level for your app.

This means, that there no restrictions for Java 8 language features anymore. So you may leave lambdas and even java.util.stream.*.
Correct me if I am wrong.

[Grodou]

@sealedtx Hi, I gave it a try with graddle plugin 4.0.1:

• try-with-resources and lambdas work fine, both in imported libraries and directly in the code.
• streams work too, but only inside libraries (via "desugaring"), still can't use them directly in the code.

That means, for an API:

• we can use streams inside methods or as parameters for private ones
• we can not expose any parameter related to streams, like Predicate, it doesn't work

As a conclusion, I think we should:

• get rid of streams in the main code to avoid any problem
• use try-with-resources and lambdas as we want, no restriction
• do whatever we want in unit tests
• maybe add some information for Android in the README.md

[sealedtx]

@Grodou Great, thank you for diving into this problem. If you have time and inspiration you may create PR to remove usage of java.util.streams.* from public api, or even from private too, so it won't make confusion for us in future.

[sealedtx]

@Grodou I see that you have commited to the same branch as 'faster downloads', not a very big problem, but in future, please, follow the rule - new branch for a new feature/fix. It is easier to merge and to view changes history.

[Grodou]

@sealedtx Understood, I will.
Actually, this commit fixes another problem, related to format selection. While testing the Filter class, I noticed no audio format where available even if some of them had a mime type like "audio/...". Fix is in DefaultParser line 327.
Tell me if you want a dedicated issue, just a PR, or if it's OK to keep it in this commit.

[sealedtx]

@Grodou For now keep it as it is, and thank you for noticing that bug.

[Grodou]

@sealedtx OK, I guess it's time to create a PR ?

[sealedtx]

@Grodou sure