Live data from Hacker News

New F-Droid repository format for faster and smaller updates

f-droid.org

131–140 of 146 posts

Re: New F-Droid repository format for faster and smaller updates

#131

Earlier quoted context omitted.

if you prefer old f-droid interface, you can try foxy droid https://f-droid.org/en/packages/nya.kitsunyan.foxydroid/

Update. I like it, it's very similar to the old F-D v0.102.3 mentioned. Reckon I'm not alone, seems Foxy Droid's author shares similar views. Thanks. :-)

Much later....

This story has subsequently appeared on HN, it seems absolutely apt to include it here as it's directly relevant to the F-Droid UI matter: https://letterstoanewdeveloper.com/2023/03/06/understanding-...

Re: New F-Droid repository format for faster and smaller updates

#132
post #4

Earlier quoted context omitted.

>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.

I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.

Right, but my main point here is that if your business logic cares about the distinction, you've created a pointless footgun 99% of the time. If you care because you're worried about formatting issues or string corruption, there are a million better ways to check for those.

Re: New F-Droid repository format for faster and smaller updates

#133
This is a full revamp of a bunch of the key guts of the app. We hope that other F-Droid-compatible clients like Classic, Foxy, NeoStore, droid-ify, etc. can benefit from this revamp as well: we've split out this core functionality into libraries. This should fix lots of stability issues. I think it is also important to point out that the official F-Droid client is stable for the core contributors, and that's mostly because a) we are the devs and we fix the bugs we encounter, and b) we report the bugs we can't fix.

I think most F-Droid contributors are using Google-free devices these days, so that's where it works best, especially when built into the ROM like CalyxOS, Lineage-for-microG, etc. Unfortunately, that means we pay less attention to how things run on Google devices. So if you're running F-Droid on a Google device, please be sure to report issues so we are aware of them!

Re: New F-Droid repository format for faster and smaller updates

#134

Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was d…

Hey @pserwylo, great to hear from you, and I especially appreciate your message here with the background. And I'd like to highlight your point that there is much less contributor time than people imagine. If anything, the F-Droid client UX design process back in 2016 has proven to be an immensely efficient exercise it putting together a UX that still works decently. Plus we managed to predict that bottom nav would rise in popularity and those sliding sidebars, which were recommended back in 2016, would fade.

You're of course welcome to contribute again! The hard part is that app stores are large and complicated apps, when done fully, so that makes it hard to contribute to. We do mark issues with "first-timer" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... and "help-wanted" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... if anyone is looking for a place to jump in. I think we can also see this in all the various other clients like G-Droid, M-Droid, Foxy, Droid-ify, NeoStore, etc. Many rapidly stop being maintained, and others leave out key functionality like localization and automatic mirror selection because it is a lot of work to implement. The new libraries should make it a lot easier for forks to implement these features.

Re: New F-Droid repository format for faster and smaller updates

#135
post #50

Why not just use a SQLite db ? Far more size efficient than JSON.

Exactly my thoughts. JSON is totally the wrong format in the first place.

JSON is the file format, it is then parsed and stored in the local SQLite

Re: New F-Droid repository format for faster and smaller updates

#136
post #88

Earlier quoted context omitted.

That's essentially what they're announcing, isn't it?

Woops, yes. I didn't read the article, and thought it was referring to apk diffs, my apologies. That said, apk diffs seem important as well, some updates are significantly large (more than 100MB) and see frequent updates. Although in that case it might need to cache apks which requires space as well (I would opt in, though!).

We welcome contributions to support APK diffs, it would make a big impact: https://gitlab.com/fdroid/fdroidclient/-/issues/450

Re: New F-Droid repository format for faster and smaller updates

#137

Thank you f-droid for having a consistent UI since years.

Consistency is good. But I find the update flow to be annoying. Touch 'updates' tab, doesn't show you the updates until you pull down (with no affordance), update are summarised but not listed in the big space for updates to be listed, "update all" then doesn't update all but instead lists the updates in that big space, tap "update" on each item listed, you get a popup asking if you want to update it (because the two…

Interesting points, I agree the Updates tab could do better there. Update All is implemented if you have F-Droid Privileged Extension installed, it could also be implemented when it is directly installed, if someone wants to contribute there.

Re: New F-Droid repository format for faster and smaller updates

#138
post #8

I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100%…

>I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues I've used Fdroid for years, downloaded and updated apps hundreds of times across multiple devices and never encountered a single thing you described. Death, taxes, and people confidently generalizing from one-off cases of highly unusual experiences. >I didn't realize the app was still being worked on. By my count…

I don't encounter all the same bugs gp does, but I do encounter several on a regular basis. These issues show up regularly on both my tablet and my phone, and they showed up regularly on my previous phone and two tablets over a range of ~5 versions of Android (8-12)

1. Every so often I turn on my tablet or phone and see a notification that fdroid has crashed, asking me to submit the information (I used to, I don't anymore). I wasn't using fdroid recently, I don't leave it open in the background; the only background task it has is fetching update lists and downloading new versions to install later. If it crashes, it loses the downloaded updates.

2. Occasionally fdroid crashes on start, providing the same notification as above. Force-stopping the app and removing the activity from recents is the only way to get past this--if I force stop and restart from recents, it crashes again. If I remove from recents and don't force stop, it crashes again. I'm guessing whatever parameters it launched with are causing the crash to happen again.

3. The background service frequently stops while updating package lists (not while downloading packages). The notification remains. This is regardless of whether the update is manual or automatic; there is no foreground update. At 11:00pm I regularly have a non-dismissable sticky notification, last updated at 5:00am, that fdroid is updating repos. Tapping it does nothing, I have to open the fdroid app, which may or may not crash on opening. If it crashes, the only way to reset the notification is to force-stop it. This is also the only way to open fdroid after such a crash (see #2). While I have no confidence that the crashing issue is fixed, it sounds like the new index is intended to prevent repo updates from taking this long. Personally, I'd prefer to just download an SQLite file directly from a server and just dump that in the app to query.

4. After downloads are complete, the download list frequently doesn't update. I can initiate the install from either the page for that specific app or from the download notification, but the main downloads list just shows that it's still downloading.

5. Not really a bug so much as missing feature: there's no way to do partial update checks. No way to check for updates to a single app without downloading the entire repo. I know there's an update available for X Y Z apps and want to update them on the bus, but because #3, 30 minutes is likely not long enough to do so. There's also no way to check a single repository for updates, and trying to bypass this by toggling that repo off and back on causes fdroid to update all repos in the order they were added. If I want to install an app from a new repo, I have to wait for all my other repos to finish updating first.

6. I have ~10 repos in fdroid. I regularly get a notification that the format is incorrect or the server couldn't be contacted or some such. It doesn't tell me what repo that is. My only option is to go through and toggle all my repos off, enable them one at a time, and

I've mostly given up. I can't get the latest update for apps from the website because fdroid doesn't make that available, I can't install updates automatically because I'm not rooted (and thus can't just trust that it'll eventually succeed in installing). I used to run my own fdroid repo for these apps; I don't anymore, because it's not worth the effort to try and get fdroid to install them.

It's not because I'm using some obscure hardware or ROM; I've had these issues with: Nexus 7 lineage, Nvidia shield lineage, Moto G6, Moto G6 lineage, Samsung A32 stock, Samsung Galaxy Tab S6 stock. Fdroid is usually the first thing I install after getting a new device or after rooting a device; I've had fdroid crash on the third time starting it on a brand new device, before I've done more than enable adb to install fdroid.

*This is _not_ a one-off case, this is an ongoing issue that I've had for years at this point*

Instead, for the few apps I actually care about keeping up to date, I use Obtainium, which checks GitHub releases (among others) instead of fdroid (it can check fdroid's website, but that's not kept up to date). As a bonus, this also allows me to keep track of apps that aren't included in fdroid (mostly Tachiyomi forks). Obtainium can't check for updates for individual apps without fetching and parsing the entire catalog, because fdroid only provides a full catalog (see #5)

Re: New F-Droid repository format for faster and smaller updates

#139

My F-Droid would not auto-update, attempting to manually get the update through the app refused to load at all, and downloading from their homepage gave me an old version. I had to download the specific version directly from their package page via a browser: https://f-droid.org/packages/org.fdroid.fdroid/ This seems to have resolved the self-auto update issue I had as well. I can now see the F-droid client page from…

> downloading from their homepage gave me an old version.

This is because the FDroid website does not expose the latest version of apps. The website itself is a static Jekyll website, and I've never found any information to indicate that the app listings aren't part of that, apart from them being missing from the source repos (which they would be if it's generated from the index at runtime).

Re: New F-Droid repository format for faster and smaller updates

#140

Earlier quoted context omitted.

>I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues I've used Fdroid for years, downloaded and updated apps hundreds of times across multiple devices and never encountered a single thing you described. Death, taxes, and people confidently generalizing from one-off cases of highly unusual experiences. >I didn't realize the app was still being worked on. By my count…

I guess you have enough answers, but I agree with the others. It's a very, very buggy app. It does the important task that it promises so we all love it despite its flaws. But if this was a commercial app, the rating would probably sit somewhere between 1 and 3 stars.

And again, as I said to others, the idea that F-droid is not updating itself is almost self-evidently false, the issues people have reported with not being able to update apps involve some elementary conceptual errors that are being erroneously attributed to the app that have been explained by some comments here, and lastly subjective reports from people in a comment section are not a sound basis for generalization.
Post reply on HN