Looking to report a Bug or make a feature request? Take a look here.
Translations are currently only possible by directly editing the strings.xml file and creating a PR.
Pull requests are welcome! Please read follow the Code Style Guidelines below.
If you're interested in taking on an open issue, please comment on it so others are aware.
Forks are allowed so long they abide by Yodel's LICENSE
When creating a fork, remember to:
- Avoid confusion with the main app by:
- Changing the app name (strings/app_name)
- Changing the app icon
- Avoid installation conflicts by:
- Change the 'applicationId' in build.gradle
if you want to use Yodels automatic build system, have a look at the build guide
Use the following prefixes for branches:
Prefix | Function |
---|---|
feature/ | new features and improvements to existing features |
fix/ | bugfixes* |
locale/ | for locale additions and updates |
* sometimes, a bugfix is implemented alongside a new feature. this is ok. you do not have to create an additional branch just to fix a bug. instead, just include it with your feature.
These are the guidelines you should follow when contributing code to Yodel.
These Guidelines outline what I think are useful rules to create readable and manageable code, tho they are always open for discussion(i'm not a professional developer after all, so what do i know :P)
- Yodel uses the Model View ViewModel pattern
- Use Kotlin as the main development language
- I'm new to kotlin, so if i'm doing something stupid (or could do it better), please let me know
- if you use a language concept that is not obvious, please leave a comment
- Do not hardcode stuff (intent extras/actions, urls, ...), but use constants in the appropriate classes instead
- Enums in PascalCase (convention seems to be ALL_UPPERCASE, but that looks ridiculous)
- include kdoc comments for:
- all classes, interfaces and enums
- all public fields, methods and constants
- optionally private fields, methods and constants
- comments should describe the class/field/method, but don't have to be too long
- do not ignore lint warnings
- Try to include tests for your contribution (where applicable)
- See Testing for details
- Try to include test cases where possible
- test- only contributions are welcome too
- Yodel uses Kotest for assertion statements
- Unit tests and Robolectric tests go into /src/test
- Name normal unit test classes
(MyClass)Test.kt
- Robolectric test classes shall be named
(MyClass)RoboTest.kt
and extendRoboTest
- Robolectric tests run across multiple SKD versions. If you only need robolectric for some test cases, please split your class
- Name normal unit test classes
- Instrumentation tests go into /src/androidTest
- Name instrumentation tests classes
(MyClass)AndroidTest.kt
- Name instrumentation tests classes
- If possible, use Robolectric instead of instrumentation tests
- instrumentation tests are supported, but require adjustments to the full_ci and short_ci workflows