Add commit attribute to AndroidSettings.Factory
See original GitHub issueAndroidSettings
constructor allows to set a commit
flag.
I am missing the same configuration option when using AndroidSettings.Factory
.
As the fun create(String?)
is defined in the parent Settings.Factory
interface, the commit
option would need to be set in AndroidSettings.Factory
constructor.
If we can agree on this I can to the PR.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Migrate constructors to builder lambdas for future-proof ...
Add commit attribute to AndroidSettings.Factory #74. Closed. Sign up for free to join this conversation on GitHub. Already have an account?
Read more >git - How to attribute a single commit to multiple developers?
Commit title Commit body Co-authored-by: name <additional-dev-1@example.com> Co-authored-by: name <additional-dev-2@example.com>.
Read more >git-commit Documentation - Git
The content to be committed can be specified in several ways: by using git-add[1] to incrementally "add" changes to the index before using...
Read more >Settings - Android Developers
Inflate the hierarchy. To inflate a hierarchy from an XML attribute, create a PreferenceFragmentCompat , override onCreatePreferences() , and ...
Read more >Commits API - GitLab Docs
Get a list of repository commits in a project. GET /projects/:id/repository/commits. Attribute, Type ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Platform-specific settings should be configured in platform code, not common code. Otherwise you end up with a bunch of extra flags in common code that don’t do anything most of the time, and that makes for a confusing API.
The purpose of no-arg is to provide a reasonable default configuration where you don’t need to do anything extra. If those default settings don’t fit your needs, then you shouldn’t be using no-arg.
There’s a bit of a combinatorial explosion when trying to support every option for both constructors and factories. I haven’t been very focused on the
Factory
implementations since you can fairly easily create your own if you need different options. I’ve also become less and less convinced over time that having aFactory
interface is really that useful compared to just supplying your own() -> Settings
or(String) -> Settings
lambda as needed.At some point I want to do some deeper rethinking of how initialization works, and have been thinking about doing a DSL builder style like Ktor and kotlinx.serialization use. See #65.