nailing down the F-Droid direction

[eighthave]

So I've been a bit MIA on this, too many things hit me at once in the past few months. I've been working non-linearly on this, now I want to nail down the plan for the rest of the time.

Based on various discussions, it seems that the various offline use cases are the most interesting to focus on, like the Cuban app store. Here's my sketch of the work points so far:

smooth out swap • harmonize user experience with Viento projects and Android Go • automate as much of the process as possible • work with SD cards • index El Paquete for rapid access

offline malware tools • many devices are out of date, don't get updates • scan for exploits when adding to collections • increase visibility by making F-Droid Nearby app for Google Play

conserve • only load graphics/screenshots on wifi or sneakernet, not on metered connections • battery conservation through Android schedule tricks • pre-crunch/optimize all images that are added to F-Droid app repositories

How does this sound? @cstiens @n8fr8

[cstiens]

@eighthave @n8fr8 I think your overview covers nearly everything. I'll put together the settings I'd recommend for the 'smart profiler' which touch on the 'conserve' section. There are a few other items I'd add—

• The other use case to address is the trainee with a low-end phone and limited storage using F-Droid mainly offline or over a spotty network, with the main intention of getting a set of apps from a trainer nearby. We talked about this on the last call. Rather than auto-syncing F-Droid repo, we could offer the option. I've included a mockup below. The wording could use a little work. But, it gives a general idea. We could show this only in cases where the user have limited storage and no SD card. If they have an SD card and low storage, we could automatically sync to the SD card.

• There's one more item I would add to nearby (swap)—that is to QA test and fix bugs. Getting 8+ people in a room to use nearby at the same time would be a good test of functionality.

• Develop a way to allow non-technical trainers to easily load a repo to library box (from repomaker) and share it with a group. For the group, we may need to adjust the swap workflow slightly.

[eighthave]

Automatically syncing to the SDcard would be nice, but unfortunately my experience with using the SDcard in apps is that is really brittle. So it is really hard to use without making the app crashy. Lots of devices have external SDcards, they often jiggle loose. Or the user might just remove it for a little while. These cases are all really difficult to handle well. For the devices that have a built-in, non-removeable SDcard, the app storage is the same disk as the SDcard, so using the SDcard doesn't change anything.

[eighthave]

We don't be able to do a partial app listing with the amount of time we have. The current model is one full app index in a single file. Adding a partial index would take a chunk of time to get right. Also, I think the issue was more about using bandwidth than storage space. The app index is a 1MB download. It needs something like ~4MB when unpacked to the database. So max 5MB storage. The 1MB file will be auto-deleted by the cache cleaner.

Things like installed apps, icons, screenshots are cached, then there is a cache cleaner controlled by the "Keep cached apps" preference. That's something we could easily set based on limited storage. Like automatically default it to 10 minutes if storage is low. It currently defaults to 1 day. That then increases bandwidth usage, since it'll redownload icons and screenshots as the user browses. But if that stuff is forced to happen on unmetered internet, then it should not affect the user's bandwidth bills.

I think this screen should just disable the main F-Droid repo, then show the switch to enable it. The question is should there be a button that takes the user to the Reposirities overview to enable reports, or should it just show the switch for the F-Droid repo right there on that screen.

[eighthave]

Here's a quick, ugly sketch:

[n8fr8]

Instead of SDCard, thinking about attached external USB flash Drives. This is a very popular use case in Asia, and will increase as everything moves to USB-C, since laptop/desktop flash drives will use the same port as on mobile.

[n8fr8]

This would provide support for F-Droid repos distributed through an El Paquete style network

[eighthave]

We definitely want to support USB drives and SDcards as a source of full repos, that would be a totally different part of the UX. That would be based on auto-detecting whether USB drives/SDcards are present, and whether they contain any fdroid repos. The use of the SDCard I was referring to was like moving F-Droid itself to the SDcard, that's really problematic, or having F-Droid store required files on the SDcard.

So in the case of this screen, it wouldn't say anything about USB drives unless the user plugged one in. I imagine that we should use the same "add repo" dialog when a new repo is found on a USB drive or SDCard. If the user has already added the repo, then it would just show up automatically when detected. We can do this based on the signature on the repo index.

[n8fr8]

Ah right, sorry for the confusion

[cstiens]

Recap of our convo on the scrum—

Wording if the storage space is low: "Free up space to see the 2,000 apps available from F-Droid."

• 5MB are required for the listing. We could set the threshold at 10-15 MB. If the user clears up space, the listing would automatically download if the user is connected. We should determine if this is on a metered or only unmetered connection by default depending on the user.

If the user is not connected to the internet, we would want to handle this view differently. Just a thought— we could also make the nearby view the default view on first use if the user is not connected to internet.

[eighthave]

My concern as discussed in the meeting is scaring off new users by talking about "repos" before they've even used F-Droid. So this screen could show up when the disk space is low, then automatically go away if disk space is freed up. Then we can make the "repos" stuff less prominent, and optional to avoid introducing a new, hard concept to people when they start using F-Droid. Like people can go to "See All Repos" if they know what they are doing, or want to learn.

[eighthave]

I guess my take away is that the first recommended action can be "free up space, then F-Droid will show all available apps". Then "see all repos" would be the "advanced" action.

[eighthave]

I guess that's really ""free up space and find an internet connection, then F-Droid will show all available apps"

[cstiens]

@eighthave

[eighthave]

I opened a new issue to discuss "update "Only on WiFi" preference to handle very low bandwidth better": https://gitlab.com/fdroid/fdroidclient/issues/1381