You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/android/best_practices.md
+86Lines changed: 86 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -117,3 +117,89 @@ For more details, see [submit](/docs/android/submit).
117
117
118
118
-**Testing**: Write [unit tests](/docs/android/testing/unit_testing) for critical functionality to ensure reliability.
119
119
-**Code reviews**: Always review code for adherence to these best practices.
120
+
121
+
## Fail fast
122
+
123
+
The further you progress in development, the more difficult it becomes to debug issues. Do not ignore errors, even those you think are unlikely to occur. Always aim to catch errors at build time rather than at runtime. Use Kotlin compiler features whenever possible, and consider adding a [lint rule](/docs/android/linter) if you cannot enforce a check at compile time.
124
+
125
+
### Leverage Kotlin compiler
126
+
127
+
The Kotlin compiler can help you catch issues early. For example, using the `when` operator with sealed classes/interfaces ensures that all cases are handled.
128
+
129
+
**Example:**
130
+
131
+
```kotlin
132
+
sealedinterfaceShape {
133
+
classRectangle: Shape
134
+
classOval: Shape
135
+
}
136
+
137
+
funfoo(shape:Shape) {
138
+
when(shape) {
139
+
isShape.Oval->TODO()
140
+
isShape.Rectangle->TODO()
141
+
}
142
+
}
143
+
```
144
+
145
+
If you add a new class that implements `Shape`, the compiler will fail to build until you handle the new case. This is especially useful when the interface is used throughout the codebase. Note that this only works if you do not add an `else` branch.
146
+
147
+
### Don't silently ignore exceptions
148
+
149
+
While it is important to catch exceptions to prevent crashes, silently ignoring them can hide deeper issues and make debugging more difficult. For example, consider a third-party library that requires initialization with an API key. If initialization fails and the exception is caught without proper logging, it can be challenging to identify the root cause if something stops working in production.
150
+
151
+
**Example:**
152
+
153
+
```kotlin
154
+
funfoo() {
155
+
156
+
// Always catch the error and proceed with fallback value
157
+
val value =try {
158
+
ExternalThirdPartyJavaAPI.value()
159
+
} catch (e:Exception) {
160
+
// Fortunately we log the error to help with troubleshooting
161
+
Timber.w(e,"External third party throw an error. Current state = ${ExternalThirdPartyJavaAPI.state()}")
162
+
"fallback"
163
+
}
164
+
}
165
+
```
166
+
167
+
Proper logging ensures that users and developers can spot errors in the logs and report issues effectively.
168
+
169
+
To further improve error handling during development, use the `FailFast` API. This API applies offensive programming principles by crashing the app in the `debug` flavor when an error occurs, making issues more visible early in the development process.
// In development, this will crash the app with a message and stack trace instead of silently falling back. In production it will only print and use the fallback.
179
+
val value =FailFast.failOnCatch({ "External third party throw an error. Current state = ${ExternalThirdPartyJavaAPI.state()}" }, "fallback") {
180
+
ExternalThirdPartyJavaAPI.value()
181
+
}
182
+
}
183
+
```
184
+
185
+
By failing fast and logging errors clearly, you make it easier to identify,
186
+
debug, and fix issues before they reach production.
187
+
188
+
When the FailFast API is triggered, it produces a clear and visible log entry, making it easy to spot and investigate:
189
+
190
+
```log
191
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E ██████████████████████
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E ██████████████████████
194
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E
195
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E An unrecoverable error has occurred, and the FailFast mechanism
196
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E has been triggered. The application cannot continue and will now exit.
197
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E
198
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E ACTION REQUIRED: This error must be investigated and resolved.
199
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E Review the accompanying stack trace for details.
200
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E ----------------------------------------------------------------
201
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E
202
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E
203
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E io.homeassistant.companion.android.common.util.FailFastException: This should stop the process.
204
+
2025-06-12 10:53:20.841 29743-29743 CrashFailFastHandler io....stant.companion.android.debug E at io.homeassistant.companion.android.developer.DevPlaygroundActivityKt.DevPlayGroundScreen$lambda$14$lambda$13$lambda$12(DevPlaygroundActivity.kt:80)
Copy file name to clipboardExpand all lines: docs/android/linter.md
+7-1Lines changed: 7 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -139,7 +139,13 @@ After updating, review the ignored errors to determine if they should be address
139
139
140
140
## Extending lint rules
141
141
142
-
We encourage you to propose new linter rules specific to our project. These rules can help identify misuse of APIs or enforce design patterns.
142
+
We encourage you to propose new linter rules specific to our project. These rules can help identify misuse of APIs or enforce design patterns that we want to be enforced in the project.
143
+
144
+
### Custom lint rules in the project
145
+
146
+
A dedicated Gradle module `:lint` contains all our custom lint rules.
147
+
148
+
-**MissingSerializableAnnotationIssue**: Detects missing `@Serializable` annotations when working with [Kotlinx.serialization](https://github.com/Kotlin/kotlinx.serialization).
0 commit comments