Hacker News Reader

Comment by RicoElectrico | Hacker News Reader

It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.

I've got mixed feelings about that as well, but on the whole it's about even and I'm not sad that the search is local and instant. It's not that big a deal to me to download a few megabytes on top of the f-droid apk.

Then again, to download anything (including screenshots and other app info, let alone the app itself) you need a server connection so it's only mildly useful to not have to ask a server. And the search algorithm is... nonexistent I think is the most correct word to use. You get what you ask for. The top three hits for "camera" are Telegram and two identical looking SIP clients, of course. (There's not being influenced by algorithms and there's this.) I wonder if te project would accept a better algo if I'd contribute one; I've made one before at work for a not dissimilar dataset so I have some notion of what works, though it's not rocket science anyway.

It's not strictly necessary, but if the entire repo can fit inside 8MiB of compressed data I can understand why they chose this rather than server-side search. That's "three clicks on Twitter" in terms of data, not exactly the end of the world, though less is always better. F-Droid's main servers are always overloaded anyway, so just sending a nice and cacheable compressed archive seems like a fine trade-off to me.

It would be nice to use some kind of delta compression to only download latest changes. There could be a version-stamp on your local data, the client would send the timestamp to the server, and it would send a delta from your version to current version of db (easy to cache). Integrity checks would be important I think.

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

Offline search and metadata is a really nice feature to have. I'm glad it is present and I'm happy to see it being improved rather than abandoned.

I don't won't to be tethered 24/7 to the internet to use my mobile phone. Data exchange isn't free, both in money and in environmental impact. That's a flawed assumption to begin with.

You're talking about an app store here though - by definition it needs to retrieve the app itself and assets related to each entry (e.g. screenshots), so it's not like you're achieving anything useful by downloading the database offline.

This isn't something like a news reader.

It is useful to me. It allows me to search for apps while offline, and wait for non-metered data to actually download it; it's something I find myself using a lot

On the other hand having to download all app details at once takes many MBs, not always fast. You can instead cache details of some applications.

I think homebrew moved away from repository approach too.

I usually update repos while on wifi, then search, then use wifi again to download. I like the flexibility of not having to be connected, my phone has more than enough storage space to store a few MBs of repo database

Yeah you have wifi. Not everyone has. In rural India, for example, mobile data is predominant way of getting internet.

Then you would need to check every app on the phone against some server.

Your assumption on how it works is flawed to begin with. Check the comment from one of the original authors https://news.ycombinator.com/item?id=35003844

I believe the whole repo is also used to check available app updates

Reply on news.ycombinator.com