Allow updating apps through command line

[fbis251]

With raccoon v3 the -u flag was used to update apps through the command line. This feature is no longer available in raccoon v4

[onyxbits]

I really don't want to add a commandline mode again. It always ends in novice users expecting me to walk them through, double the work ensuring that both CLI and GUI behave in the same way:

You deprecate something in the GUI -> it needs to be removed from the CLI as well -> lots of users complaining that their scripts break now -> you grudgingly put the CLI option back in -> novice user tells you that s/he really wants/needs the deprecated feature -> you give in an tell them about the CLI -> three more emails explaining how to operate the shell.

[ghost]

That's unfortunate. My Raccoon lives in a Docker container, together with an FDroid server.

[onyxbits]

I totally understand why a CLI is desirable. The reasoning above is not a strict "no", but rather a "what I want to avoid at all costs" thing:

• Novice users being forced to use the commandline because some quick and dirty feature is only available there.
• Quick and Dirty features that break between versions and hence scripts that depend on them as well.

The concrete problem with a -U is:

• The transfermanager code is not currently not prepared for headless operation -> it needs to be either rewritten or a lot of code needs to be duplicated.
• In the long run, I want Raccoon to be able to download from other markets (e.g. humble bundle, f-droid, maybe amazon, ...) too, so a general -u would become ambigous.
• Raccoon v4 uses a database now instead of the filesystem to store all of its meta data. Naturally, only one process at a time can open it -> you can't run an update script AND browse Play at the same time. Some kind of daemon mode would be nescessary here.

I guess, the thing I am trying to say is: if there's suppose to be a commandline mode, it needs to be carefully crafted.

[fbis251]

The nice thing about raccoon 3 is that you can automate your app updates. You run raccoon on a timer and no longer have to worry about manually checking for apps.

If writing a CLI only approach isn't possible, would it be possible to add an option to automatically check for and download updates when the GUI launches? Although it wouldn't work on headless servers it would still be useful for automation

The way I see it is this could be done in with two toggles

• Check for and download updates on launch
• Automatically close raccoon after x seconds once updates are downloaded or no updates were found

[onyxbits]

I think, that would result in a usability nightmare. Not to mention that its kinda annoying if software automatically does updates even though you started it for a different purpose (even getting a list of apps to update already is a considerable amount of network trafffic).

[fbis251]

That's where the -u flag would come in handy, if you start the program with that flag the user specifically wants to check for updates. It would skip the click to open the "Update apps" dialog.

All of this functionality is already in your program, all the -u flag would do would be to open the update apps dialog for you and start the app downloads. Wouldn't that only use as much bandwidth as raccoon 3 used to?

[onyxbits]

This is getting kinda horrible. Please step back a moment and reconsider what you are suggesting: you want your problem solved at all cost and are currently lobbying for the mother of all dirty hacks with the worst usability imaginable (you even accidentally sacrificed your won goal in the process: headless raccoon). There is no way in hell it will ever be done that way.

As for bandwidth: Raccoon doesn't get push notifications from Play (you wouldn't want that anyway), so it needs to perform a search query for every app in storage, then compare versioncodes. In other words: updating becomes slower with bigger app collections.

[fbis251]

I didn't mean for this to become a big deal. Let's take it step by step.

At the moment I can do this

• java -jar raccoon-4.0.1.jar
• Click on Market
• Click on Update Apps
• Apps start updating/downloading

What the proposed -u flag would do

• java -jar raccoon-4.0.1.jar -u
• Apps start updating/downloading

The only thing that would be different is the two clicks to open the Market > Update Apps dialog would not be needed

[onyxbits]

That is definitely not how I want it to be (commandline switches to start in different UI modes). I don't object to having a CLI for scripting purposes. I just want it to be as far away from the novice user as possible (really, nothing good comes out of even suggesting to use to commandline to the average Mac/Windows user) and have a clean implementation (really, nothing good comes out of dirty hacks because someone needed a certain functionality).

[noctux]

Hey,

I've done some tentative code reading for this issue. Please note that some if not all of the below might be completely wrong as I made for a quick dive into the source code, but it might be a contribution to the technical side of the discussion (as I would be interested in this functionality as well...). I'm also not really well versed with Swing...

Of course this cannot do anything about the social component (Windows/Mac users and their averion wrt cli interfaces)...

In principle there seems to already be a nice separation by the means of model and view in terms of workers and gui.

CLI could use that infrastructure by mimicing Swings behaviour, i.e. report progress etc in mainthread and simply start workers which schedule callbacks for the mainthread. To this end, SwingUtilities.invokeLater calls in the workers could be replaced by a general dispatching mechanism that in CLI mode queues Runnables and then executes Thread.run on the main thread and invokes SwingUtilities.invokeLater() in GUI mode...

For an more or less complete featureset it might be enough to fix TransferWorker subclasses and the ImportWorker?

Subclass the Driver (maybe introduce a factory (overkill imho) or a factory method in the Transfermanager) into:

• A GUI variant, which basically does what Driver does now
• A CLI variant, which implements a rather limited progress accounting

That way, the TransferManager itself should be reuseable across the different versions?

In detail:

• Replace SwingUtilities.invokeLater(this) by a generic report progress. CLI mode might simply modify counters in a concurrent hashmap which the main thread emits or something here?
• Run would only do transfer really
• In the GUI case, the generic progress reporting would also do the JProgressbar-stuff This might require an separate Runnable instance for callback scheduling, but seems to be a fair overhead

For the relevant *Workers subclassing SwingWorker (This should be UpdateAppWorker, ImportWorker and maybe DetailsAppWorker), introduce a new RacoonWorker<X,Y> class, that is can optionally wrap itself up in either a SwingWorker or a Thread/Future combination for CLI mode.

In terms of code style/clean code: eliminate TransferWorker.getPeer() from the interface (or allow it to return null):

• Change might be okay because it is only used within the Driver and the TransferViewBuilder
• However it is not easy to cleanly handle this, as all nearly all workers overwrite this method to return their own controller instances -> Could be fixed in most (all?) cases by a registerChannel callback?
• This would internally cleanly signal that *Workers should not directly interface with the GUI

Still several rough spots:

• Mainly overrides to ActionListerner.actionPerformed, e.g. ImportAppWorker.actionPerformed and AppDownloadWorker.actionPerformed
• but also ImportAppWorker.onPrepare:
  • However, ImportAppWorker is a GUI class anyways, CLI could use `ImportWorker? directly (at the expense of a tiny bit of redundant code maybe?)
  • Maybe build a similar tandem around AppDownloadWorker, i.e. an GUI wrapper class that handles the ActionListener stuff?

Effective feature set:

• -i via ImportWorker
• -u via UpdateWorker
• ADB installation
• All done via TransferManager
• Maybe metadata dumping via DetailsAppWorker?

Please note that this approach is maybe a bit too heavy on the code reuse part and goes way to eliminate code duplication. It might be easier in some cases to simply inline the actual code (e.g. for the DetailsAppWorker from its doInBackground method) and be done with it. Finally, to reiterate: The above might be utter bullshit, I'm not sure that it adds up to a working solution. Furthermore, I don't know if the resulting implementation would really be clean. Hopefully some stuff would pose a sensible refactoring beyond the matter at hand.

Anyways, thanks for reading until that point anyways :D I hope I have not wasted your time.

P.S.: github really does not seem a good form to talk about code without a real pullrequest and implementation... I'm sorry.

[cwmke]

@onyxbits if the main goal is not to deal with users inexperienced with the cli, a wiki entry could be created and pointed to with instructions on how to use it. A note can be added as well that states no support will be offered for issues related to the command line portion of Raccoon.

In the end it is of course your work and decision to make but I've seen other developers use this solution and simply point to the policy when someone asks.

[fbis251]

@onyxbits Thanks for the 4.2.0 update which has the command line updater.

If anyone is going to use the feature a lot, make sure you buy your premium keys to support this project.