Stumbling around some old source code; I found a snippet that used StrictMode in the Application#onCreate
. It's not anything revolutionary; but it helps in larger and more complex apps to catch simple mistakes.
StrictMode
never helped much at that time. We had a pretty good handle on transitioning off of the Main UI thread via the available tools. If nothing else; we hammered on it in code reviews.
There were the occasional times StrictMode
pointed something out during developing a feature. Early in a feature; I understand the annoyance; my experience with TDD and that it extends time before running on a device; StrictMode
becomes far less of an annoyance and the detectAll
and penaltyDeath
are far more acceptable options to have in.
I value having something like this in (now that I've rediscovered it) because it forces the consideration of threading in EARLY. It doesn't allow the developer to "take care of it later". Forcing these types of concerns to be dealt with early raises awareness of the potential issues. This raised awareness, hopefully, causes greater thought to be put into the code.
The snippet I use for this checks everything and blows up.
public class MyCustomApp extends Application {
@Override
public void onCreate() {
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(
new StrictMode.ThreadPolicy.Builder()
.detectAll()
.penaltyDeath()
.penaltyLog()
.build());
StrictMode.setVmPolicy(
new StrictMode.VmPolicy.Builder()
.detectAll()
.penaltyDeath()
.penaltyLog()
.build());
}
super.onCreate();
}
}
I will be getting this into the HackerNews Reader app; but since it's such a small snippet; I think it's a nice thing for a short post.