feat: First offer selecting an app version then download

[oSumAtrIX]

Feature description

Right now selecting an app brings you to the download screen if not installed. That screen needs to first load in order to display versions. Instead the user should first be prompted to chose a version , or all versions should show up and a loading icon can be displayed next to it. Once it found a download for that version, it could say it with a label in place of the loading icon "Can download". Versions that can not be downloaded should be prompted to be selected from storage when clicked on. The app should then check the version once it is selected and warn the user if the version doesn't match.

The suggested version should also be highlighted. Right now it only shows this for example:

A list with one item is for example quite weird to a user seeing this screen for the first time.

Acknowledgements

• This issue is not a duplicate of an existing feature request.
• I have chosen an appropriate title.
• The feature request is only related to ReVanced Manager

[Ushie]

The app doesn't download at this stage, the app download begins once you enter the patcher screen, upto that point it is nothing more than just a setting

[oSumAtrIX]

The app doesn't download at this stage, the app download begins once you enter the patcher screen, upto that point it is nothing more than just a setting

It crawls at this stage which is an unnecessary delay. This should be done asynchronously, when a version is selected the other parallel tasks in search for a download can be stopped and once the download for that version is found it can proceed.

[Axelen123]

Closing this as not planned because this feature is very expensive relative to the benefit it brings. The feature is not compatible with the current flow and there are several problems that have to be solved first. For example:

• The viewmodel would have to drive the pager in order to find selected versions. The paging3 library might not support this nicely and swapping it out would require a new plugin API design
• How shoud manager throttle the pager in order to avoid rate limits? (this is not a problem for the current implementation because the pager is lazy)
• Manager cannot assume that every source will have the desired version. What should be done if the user selects a version that the source does not have? How will manager figure out if a source has the version or not?
• What should manager do if the user has not selected a downloader? that flow will probably have to be redesigned
• How should the UI present errors?
• How should apps with no particular recommended version be handled?

Solutions to these problems may very well exist, but they have to be discovered and discussed in detail first before implementing them to avoid creating something with different problems.

[oSumAtrIX]

is very expensive relative to the benefit it brings

Can you elaborate on how selecting one version and potentially making just one API call is more expensive than first making the user wait to load a list of all versions potentially making multiple API calls out of which the user needs one? To me it sounds like the suggested approach is at max as slow and potentially faster than the current.

The viewmodel would have to drive the pager in order to find selected versions

Paging is something the plugin can implement itself. Its not an API that manager should provide. Each plugin has to decide on its own if it needs paging and implement it. We can provide such helper functions to the API if seen necessary later.

How shoud manager throttle the pager in order to avoid rate limits

Manager is not supposed to page or anything. As this is the job of the implementation of the downloader the downloader can figure out throttling on its own.

Manager cannot assume that every source will have the desired version. What should be done if the user selects a version that the source does not have? How will manager figure out if a source has the version or not?

There are several options to that. If the user selects a version which the downloader later on can not find, the user can be asked to use a different version or supply the app from storage or try a different downloader. Alternatively, manager can rotate to the next downloader automatically and try finding the version. With this approach we also remove the need from the user selecting a downloader (we can have an option "auto rotate" later if necessary). (downloaders.orderBy(settings.userSelectedOrder).first { it.get(app, version) != null }).

What should manager do if the user has not selected a downloader? that flow will probably have to be redesigned

After selecting the version, the user can be prompted to select a downloader. Ideally of course this rotating system would select a downloader instead of the user. This way the user can create an order of downloaders to try from first to last in the settings for example. If the system is complex to implement, this can be done later too and for now the user simply selects the downloader after the version.

How should the UI present errors?

After selecting a downloader, manager could ask the downloader for the app+version. A loading icon can be present that says "Finding a download" or similar. If no download is found, the user is presented to select that version from storage, cancel or chose another downloader (if auto rotate isn't present). If the manager should ask the downloader first in the patcher screen like it is being done now, the patch is canceled and the user could go back to chose a different downloader/select from storage etc.

How should apps with no particular recommended version be handled?

I believe the downloader API can have a nullable version argument: downloader.get(app). It'll be the downloaders job to provide an APK on its own. It could download the latest for example, If we explicitly want it to download the latest we could create an API for that too of course.

[oSumAtrIX]

Merging to #1474