Scan for Existing HB Apps

[Ninjistix]

Is your feature request related to a problem? Please describe. When launching HB Appstore it does not scan the directory or sdcard to see if there's any pre-existing homebrew apps, like if you download a HB bundle such as Kosmos etc.

Describe the solution you'd like A clear and concise description of what you want to happen. --- when you launch HB Appstore it should scan the director for any pre-existing homebrew applications

Platform: Is this for the Switch, Wii U, or both versions? Both I guess...

[vgmoose]

I'd like this! The Wii U version actually has this through meta.xml in some apps, which HBL expects. This information is used to check for "local" packages and detect updates against the version number in the meta.xml.

So there is a precedent there, in isPreviouslyInstalled(): https://github.com/vgmoose/libget/blob/master/src/Package.cpp#L331-L370

There's also a check for the hb app store itself, whether or not it's already installed.

Unfortunately though for Switch, package structure isn't always this consistent. I think the closest we could do without having Hint files support (#20), is matching on the NRO binary path, and then peeking inside the NRO metadata to compare the version number against the one in the repo.

Given that some packages are just an NRO in /switch, the tricky part is lining up NRO version numbers with the ones in our repo. (to know whether or not to display an update or not). It is doable, but will take a little bit of care.

[vgmoose]

To clarify, in the section of code I highlighted, if we think a match is found, the isPreviouslyInstalled() method should return LOCAL or UPDATE, depending on whether or not the version string matches.

[vgmoose]

I’m more inclined to vote for a hashing based solution after seeing how devs treat the version field. A random sampling of the hint files should be good enough, only concern is it being a potentially slow operation.

Perhaps file size is also a good indicator, as it can be measured without opening the hint file

In my eyes this issue is the next remaining client feature that’s really needed to provide a good experience for the user. It’s super annoying to not see “installed” apps as installed

[hrvylein]

Can't we just search for filenames (not full path) in manifest.json and then, if found, reinstall the newest version? Maybe ask the user for permission before doing this?

[vgmoose]

Checking to see if all files that are in the manifest are expected is an interesting way to detect if a package is "complete" or is missing some files for an update.

libget isn't fully able to handle this (right now we don't the manifest data without installing an app), however we have started generating some repo summaries which would contain this information

If the newer version of a package has the same files/manifest content as what's on SD, however, wouldn't this still be unable to tell if it's out of date / needs updating? I suppose knowing it's installed is better than nothing and could be prompted to be updated.

Ideally this would still be coupled with filesize or a quick hash, to prevent needlessly updating already-up-to-date app. (Although, in theory this update should be ok, if they both really are up-to-date)

[hrvylein]

My premise is, that the step of detecting installed software is only needed once for the most homebrew users. I primarily used sdsetup to setup atmosphere and then update all the packages and atmosphere when eventually a new switch firmware update was safe to install.

So my take on this would be to detect all installed .nro-files and then check them against an api call to the appstore submitting the filename/filesize/hash, which would respond with the corresponding manifest and install data which could be placed (or further checks and moving of files done) in the right directory. By this we could easily get a file hash to check if the version installed matches the newest version. If we can't safely determine the version number it would be strongly encouraged to update the nro to the latest version (even though it could be the newest version).

What do you think?

[vgmoose]

Been having a few conversations with @ITotalJustice and I'm feeling confident that we can get an initial version of currently-installed detection in the next release

So my take on this would be to detect all installed .nro-files and then check them against an api call to the appstore submitting the filename/filesize/hash, which would respond with the corresponding manifest and install data which could be placed (or further checks and moving of files done) in the right directory. By this we could easily get a file hash to check if the version installed matches the newest version. If we can't safely determine the version number it would be strongly encouraged to update the nro to the latest version (even though it could be the newest version).

I agree, the only concern is that hashing might be kind of expensive. Although, we can get around this by caching the hash result and only re-hashing if the file timestamp changes. And then on the repo end, tracking the "latest" hash and nro/wuhb version.

So on the repo end, this involves adding: hash and metadata version On the client: Hashing and caching the result, invalidating based on timestamp, and comparing hash/metadata/install state to determine if an update is needed.

Also on the client it should use a newer state, to track locally-installed-apps that we think need an update. Chart of states would be like:

So, if the package is not installed, but the binary is present, and we think it belongs to an existing package, it will receive "Local" or "Unsynced" depending on if it (probably) needs an update or not.

[vgmoose]

Currently, the "Local" state is only used for legacy Wii U apps that have XML metadata, and for hb-appstore itself (If it's running from an NRO, but hasn't technically been "installed" as a package). Introducing the new "Unsynced" state would change the meaning of "Local" slightly, but I think that's good.

Flow charts of how it works today vs how it should work in the future:

Current Logic (No detection)

This is how the four states are used today:

Future Logic (Detection)

The potential future way that the five states would used (slight change in "Local" meaning, and introduction of "Unsynced"):

[vgmoose]

We are preparing to release 2.4 soon™ and a new method of previously-installed detection won't make it in unfortunately. I do really want to support this use-case, but it needs to work well first.