diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e641e82b10e4e312718d233deeca8e1ebd1c5503..0e08d2a57c52fb78ee24ff49d82974e33914902a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -165,3 +165,71 @@ general guidelines for the community as a whole: respond to an email you are potentially sending to a large number of people. Please consider this before you update. Also remember that nobody likes spam. + +## FAQ + +**Is it fine to go with Kotlin for my contribution?** + +We don't use Kotlin. This is due to the fact, that our server components +are written in pure Java. Even tough the Android community is adapting +Kotlin well, most guys from the Java community are not used to writing +Kotlin code. + +**Is there an architectural design for the presentation layer?** + +There is no MVVM/MVP or MVC in place, because the app is not too complex +and it would not really benefit from something like that right now. + +**Is there an architectural design for the data layer?** + +The data layer is separated to it's own package. + +**Where does the Sitemap rendering happen?** + +WidgetListFragment + (especially) WidgetAdapter + +**How is navigation managed?** + +ContentController manages how fragments are displayed, and MainActivity +commands it what fragments to display. Navigation is too dynamic in our +app (determined by Sitemap) for the navigation architecture component to +be useful. + +**Do we use fragments in our activities? If yes, are they necessary?** + +The answer to the first question is 'it depends'. They should be used +whenever it makes sense to use them. E.g. for very simple activities +like the LogActivity, we don't use fragments, otherwise we do. + +**Should my code be tested? If yes to which degree?** + +Ideally yes, to whatever extent is doable and meaningful. It's not a requirement though. + +**Is there a way I can test all the features against a test server or something similar?** + +Either test against the [demo server](https://demo.openhab.org), or +setup an own server. For the latter case, it's probably useful to do a +checkout of the server side code an run that, following the procedure in +https://www.openhab.org/docs/developer/development/ide.html + +**Do we have guidelines for code style?** + +Yes, Google Java Style Guide: +https://google.github.io/styleguide/javaguide.html + +In addition: Please omit "openHAB" or "My" from class names. + +**How does the CI/CD pipeline work?** + +Service | Shown as | Task | Desired result | How to fix +:----|:----|:----|:----|:---- +Travis CI | continuous-integration/travis-ci/(pr,push) | Runs full build and test suite | Must pass | Look at the build output and try to run the test locally. If the tests are failing even if you haven't changed the particular code, please poke @openhab/android-maintainers and ask them to rerun the job. +Stickler CI | stickler-ci | Runs checkstyle to ensure the Google Java Style Guide is followed | Should pass, but sometimes it reports false-positives | Look at the comments https://github.com/openhab/openhab-android/pull/{pr-number}/files +Cirrus CI | Validate strings | Checks for common mistakes in strings.xml, e.g. wrong spelling of "openHAB" | Must pass | Look at the checks output and fix the issues. +Developer Certificate of Origin | DCO | Checks if commits are signed-of-by | Must pass | `git commit -s --amed` and `git push -f` +WIP | WIP | Checks if the PR name contains "WIP" (Work in progress) | Must pass | Remove "WIP" from the PR title when you're done. + +**Do I have to include Java Doc?** + +It's always nice to see documentation, but as long as your code is +clean, it is not all that important.