Comments (12)
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.
from raccoon4.
That's unfortunate. My Raccoon lives in a Docker container, together with an FDroid server.
from raccoon4.
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.
from raccoon4.
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
from raccoon4.
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).
from raccoon4.
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?
from raccoon4.
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.
from raccoon4.
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
from raccoon4.
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).
from raccoon4.
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 theTransferViewBuilder
- 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 aregisterChannel
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
andAppDownloadWorker.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 theActionListener
stuff?
- However,
Effective feature set:
-i
viaImportWorker
-u
viaUpdateWorker
- 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.
from raccoon4.
@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.
from raccoon4.
@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.
from raccoon4.
Related Issues (20)
- Can't start raccoon on Debian Sid HOT 4
- JuiceSSH SSH Client (com.sonelli.juicessh) not found / downable HOT 7
- Proxy doesn't seem to work HOT 3
- There's a typo on the Raccoon product page. HOT 1
- Needbrowser HOT 5
- NeedsBrowser HOT 4
- Refreshing token with gp-auth fails HOT 1
- Can't search by package id HOT 1
- appCategory value not coming HOT 1
- Where is downgrade functions?
- can't compile on Linux HOT 6
- No such thing as oauth_token HOT 2
- Older versions of app HOT 2
- Can Raccoon be used via command line? HOT 1
- Error Downloading from command line HOT 4
- Possible incompatibility with OpenJDK > 11.x on View -> My Apps
- app serach issue
- Samsung Notes APK broken by Racoon? HOT 8
- Raccoon 5.0.0 HOT 5
- Session Expired HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from raccoon4.