-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable use of CandyBar as a library #216
base: main
Are you sure you want to change the base?
Conversation
As it should be :)
If there is no DirectApply implementation, there's no way it can be supported, so let's simplify this.
There's no point in having every run definition perform the same steps. The only unique bit is the intent, with a slight difference in whether there's just the activity launch or also an additional broadcast.
@sarsamurmu is this something you can imagine to merge? It's still a work in progress and I'd be testing this in my own apps for 1-2 months before requesting a merge, but before I go that route and invest more time, I want to see whether this change would be welcome. |
@moertel Yeah, we can merge that. I always wanted to improve the overall code structure to make things more modular, but I guess I never got enough motivation. So, thanks for these improvements |
This PR is a big refactoring accomplishing two things:
supportsIconPacks
supportsDirectApply
supportsManualApply
applyDirectly
applyManually
((AppCompatActivity) context).finish()
and no more ambiguity whether Google Play is opened as a fallback. :) It's now easier than ever to spot if launchers are missing information. For example Blackberry where we used to open theMainActivity
but without any instructions whatsoever. Fixing this is out of scope of this PR but it's now a clearly visible flaw in the definition.If more freedom is necessary, launchers also offer
DirectApply.getActivity
(andDirectApply.getBroadcast
if necessary) andManualApply.getInstructionSteps
.Why?
After 3 years of using CandyBar, I now feel like I've outgrown the UI and Icon Request mechanics but I don't want to make a whole new fork of the library. Instead, I want to keep CandyBar as a dependency and leverage the sane defaults for the icon picker, etc., but build a new UI on top. :)
I believe the refactoring makes sense far beyond that, as it should invite more contributions: More manual descriptions as a fallback if the direct apply fails for whatever reason, links to settings in the respective launchers, you name it.