Enable use of CandyBar as a library #216
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.
moertel
changed the title
moertel
changed the title
|
@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 |
The Candybar default behaviour is to close the activity once a meaningful action has been done, e.g. the icon pack has been applied or the user tapped on a dialog option. This might not always be desirable, so we provide a DEFAULT_CALLBACK which preserves what Candybar is doing but also allows overrides.
Unfortunately, enums behave like singletons throughout the code. This is nice when they're truly immutable but we need to store the actual installed package (if there is one), so we can use applyDirectly() and applyManually() without issues.
|
This has been running in my app for 20 days now with zero complaints and zero exceptions. Ready for review! :) Two more notable changes here:
For MOTO, we might need an override of |
|
Thank you @moertel and all others who are working on CandyBar. I'm kind of busy this whole month. I will come back in September and merge all the changes. Please wait until then. |
|
Thanks for the heads-up, @sarsamurmu, and please no rush at all! |
2 participants
This PR is a big refactoring accomplishing two things:
supportsIconPackssupportsDirectApplysupportsManualApplyapplyDirectlyapplyManually((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 theMainActivitybut 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.getBroadcastif 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.