Mark for installation

I'd propose a "mark for installation" checkbox feature as seen on most linux package managers.

Since I live off-grid, I could immediately see the advantage of this. With F-Droid, the downloaded repos remain in the app while offline, so I can study new apps at home. Could I pick and mark them for install, then they could be downloaded at the push of a button as soon as I am in town and on some WLAN. Also other types of users may benefit from the added flexibility in determining which work (here: picking and actually downloading/installing) to do when.

mentioned in issue #93 (closed)

In the same vein, a “Mark for update” would be great too.

I guess you wouldn't even need a checkbox, perhaps just let people hit the "install" or "update" menu buttons, and it can display a nice banner to tell them that it will happen when they are next connected to the internet. The banner could even have a button that says "Cancel" which un-marks it for installation.

If it works, it would be the same for me. From what I understand (which is not very much), this would mean integration with the android notification system. This is fine for notifications, but, at least from my experience, the android system is not reliable enough to entrust it an installation/update queue, and if it's the f-droid app that is to manage the hypothetical installation/update queue, then the user should be aware that he has to run f-droid the next time he is online if he wants to execute the queue. There should be a seperate tab for that queue, with the option of editing your choices before 'apply'ing. But yes, that said, an integration with the notification system would be nifty, and if it gets written, it should probably work the way Peter suggests.

P.S.: Of course f-droid could register to auto-start the installation process upon connectivity change, but I'd be against it: Imagine you just have 3 minutes changing buses and want to send that important email, but no way, after you connect to the bus station's free WiFi, 5 different apps compete for the internet connection, and the device is to slow to even take input. I believe FOSS is about empowering the user and giving choices, and at times have cursed f-droid when, out of the blue, it began updating its database. F-droid must have heard me swearing, it hasn't done that for a while.

mentioned in issue #291 (closed)

mentioned in issue #486 (closed)

Milestone changed to %1.1

@pserwylo this seems quite relevant to your !311 (closed) proposal. "Mark for Install" would put the app in the listing where in-progress installs are.

since !248 (merged), you can have it automatically download updates when there is wifi. Check the preferences. Then you should be able to install whenever. With the UX update #709 (closed), the "My Apps" section will also make queued installs visible.

#709 (closed) is a broad topic that leans more to the layout/feature/subfeature structure than the functionality side.

Today, if I am offline and try to install an item, after a time I get "Install unsucessfull", and there it ends. No queue, no trace. I have never talked about updates. And a dowloaded update is not the same thing as a queued install.

The behaviour I want, is I can browse the repositories offline nicely, [and finally (v.101 alpha) the description lines are getting wrapped again rather than cut, triple HOORAY,] so I can really pick what I want downloaded and installed the next time I'm connected, in an informed way. Only now, I have to take out my hammer, chisel and marble tablet to make a note. I find that cumbersome and harbour the hope that one fine day, I can delegate this chore to the electrone brain, and it can be automatised.

So if I choose a package for install while off line, it's the information about this intended download I want queued, not the package - that's still out of reach, on the server.

In other words, I want synaptic's ability to mark changes first and apply them at another time, only that I don't want f-droid to forget marked changes when quitting the app. Or I want a feature like Play's wishlist, only that I want fdroid to keep this list locally within the app, while google keep it on their servers, associated to an account. Or I want apt-get's ability to do a dry run and merely print out what would be done, which allows the output to be redirected to a file for later use.

Yeah, so either a complete change, where all listed repository items have checkboxes to mark them (persistently between app quittals) for download, not necessarily install yet, and then a big central apply changes button for when you're done marking packages. The added benefit is that you could now download multiple packages unattendedly, while so far, a download/install is getting aborted if you go back to the package list, forcing you to do installs one by one manually.

The less radical way to implement my proposal, rather a patch, would be catching the type of error that results from attempting an install without internet connection and queueing such failed installs; plus some tool to visualize and manage this new queue, the minimal version thereof being individual prompts for each package when f-droid detects the connectivity change and begins working off the queue. A next step of sophistication would be detection of duplicates in the queue, a full manager would look like and let me do what I can do in a playlist. Nearly. I don't precisely need shuffle and repeat.

So it's nice (errh, better than nothing) if you post in this thread, but pleeeease give me the impression that I've been understood, lest I grow loathsome and begin crossposting ;)

(alle Klarheiten beseitigt?)

j.

The way we're aiming to implement it is as transparent as possible: the main app listing interface looks the same whether offline or online. Clicking install while online will initiate the download immediately. Clicking install while offline will add the package to the queue to be downloaded next time there is Wi-Fi. The queued items will be listed in My Apps.

That probably means that apps in "My Apps" can have quite a range of different status' , the download queue would be there, but mixed with other elements that have nothing to do with it, or that's how I get it, a sort of pool, and let the different parts of f-droid identify what belongs to them. I haven't coded (save minute shell scripts) since the golden days of the 5 1/4" floppy disk, so I can't afford an opinion on that approach. But if it will work the way you describe it, it would clearly implement the functionality I am asking for. So thanks for attending to this, that was a swift answer :)

j.

mentioned in issue #836 (closed)

For those following along on this issue, this is now being fleshed out in https://gitlab.com/fdroid/fdroidclient/issues/840#note_23017673 to be implemented in the near future (I'm not sure what "near future" means sorry, but it is definitely on our radar).

That's more precise than former announcements, actually :)

Alrighty, we're getting somewhere with this now (in #885):

offline

mentioned in merge request !455

assigned to @pserwylo

mentioned in issue #1002