ReVanced
feat: Improve app selector screen
Feature description
Currently the app selector list items mention a suggested version and patches. It is unclear to the user why these information are shown. The user was asked to select an app, but why is a version now being suggested? The patches count label should probably also say "Supported by X patches"
In addition to that it should be possible to view which patches support the app, which versions of the app are supported and how many patches are available for each patch. A button to "Show more" or similar can be added to realise this.
Some apps have no description at all. If at all, they should say "Suggested version: Any" for example.
Apps that are not installed should be divided into a new section "Not installed"
Clicking on an app that is not installed should show a popup that says:
"This app is not installed but there are patches for this app. Do you want to download and patch the app"?
Right now the select from storage option is presented right above downloadable apps:
The user would be asking themselves, why should I select an app from my storage if i can click right below it since it appears in the list? Separating the not installed apps to their own section will clarify that situation.
Acknowledgements
- [X] This issue is not a duplicate of an existing feature request.
- [X] I have chosen an appropriate title.
- [X] The feature request is only related to ReVanced Manager
"This app is not installed but there are patches for this app. Do you want to download and patch the app"?
Downloader plugins are not yet in place, but the plan is to make the Version Selector Screen non-dependent on a downloader plugin, if no downloader plugins are present then it would display the versions, and clicking on it will search for the app, similar to how it is currently in the flutter version of revanced manager, there would be instructions on how to move forward when returning to the app
In regards to that I have opened an issue with details on how this could work: https://github.com/ReVanced/revanced-manager/issues/1988
Apps that are not installed should be divided into a new section "Not installed"
My thoughts on this is that, to ReVanced Manager it is irrelevant whether or not the app is installed, as most likely you'll be required to pass in an APK from the internet, not through what is currently installed. it is unnecessary information to the user, ReVanced Manager should handle it
The reason it should be put in a section is to explain what this is:
That item does not convey anything. The user is confused about the package name wondering why the app shows up like this or why it even shows up in the app selector when it is not installed on their device. The new section solves this problem.
This is a problem to be resolved in other ways, as I've previously suggested we can host an App Info API, the infrastructure team does not prefer this.
My other plan, which is probably better is for downloader plugins to expose methods to get the application info
we can host an App Info API
That does not solve:
why the app shows up like this or why it even shows up in the app selector when it is not installed on their device
Because that app screen is to select apps supported by the patch bundle, not to patch apps from the device, what the device has installed is irrelevant to the patch bundle
Because that app screen is to select apps supported by the patch bundle
Still, it is a semantical problem. We had this issue in the past with ReVanced Manager flutter where people asked why these apps show up. Moving not installed apps to a not installed section cleanly clarifies that these apps are not installed but patches are available for the app (A description can be added).
The questions were highly amplified by the fact that people did not know what they were seeing, but download plugins adding support for app info providers would remove the confusion, as people realise that these are apps that they can patch
I think it is a bigger semantical problem to bind the concept of patchable apps to installed apps, as using installed apps to patch is suggested against
The questions were highly amplified by the fact that people did not know what they were seeing
Yes, this is already a clear signal that something needs to change. It should be intuitive, even at first sight
I think it is a bigger semantical problem to bind the concept of patchable apps to installed apps, as installed apps make essentially no effect on the process at all and are unpreferred
Can you please elaborate what the problem is with adding a new section? So far you only argued to not do it , but didn't explain why not. In my opinion it solves the semantical issue i mentioned.
Because the concept of installed apps and not installed apps is unnecessary, all that there should be is patchable apps
How app info is obtained is irrelevant, whether it's from the already installed package, a download plugin, or an API, it makes no difference, I don't think it is necessary to solve this problem as it is only trying to make it less of a problem rather than a solution to the problem
Because the concept of installed apps and not installed apps is unnecessary
How is it unnecessary when it solves a semantical problem. Something is unnecessary if it were not useful at all.
all that there should be is patchable apps
But there's two types of patchable apps. Those that are and those that arent installed.
How app info is obtained is irrelevant
I didn't say to add app info to the apps. Thats something you suggested.
as it is only trying to make it less of a problem rather than a solution to the problem
Well the problem is not deniable, it exists. The user is asked to select an app and sees apps like tiktok that arent even installed on their device. Them blending in with other apps and having a weird title (package name) makes this even worse from a user standpoint. Putting them in a section will convey to the user that these are apps that are not installed because the section would exactly say that "Not installed apps" for example. A description could be accompanied to further explain that those are apps that can be patched but are not currently installed and can be downloaded.
The user is asked to select an app and sees apps like tiktok that arent even installed on their device. Them blending in with other apps and having a weird title (package name) makes this even worse from a user standpoint.
The user is asked to select a package that the patch bundle supports, the difference between the installed and not installed apps is that the app info is available for the installed one, there's no difference between them other than that, this could be solved in the way I mentioned which is offering more ways to fetch the app info, that way the user will not see a random package name anymore
A description could be accompanied to further explain that those are apps that can be patched but are not currently installed and can be downloaded.
This description would only be necessary if there is a distinction made between installed and not installed, which is something that your solution tries to introduce
The user is asked to select a package that the patch bundle supports
No the user right now is asked to "Select an app" nothing more and nothing less:
At the second they see their own installed apps they will automatically know "Oh , this is the list of my installed apps". Once they scroll through the page and see a weirdly named app called com.musically their initial thought starts to conflict with what they are seeing. This conflict is causing confusion.
With a new section the user would first see the section name saying "Apps not installed but can be downloaded and patched" and their previous assumption remains correct. The conflict is avoided and no confusion is caused.