My Notes: Strict Mode

I finally decided to enable strict mode in my app.  Strict mode is a great tool to catch performance problems early in development.   It very configurable so when it detects an issue, it can either crash the app, add log entry or show a dialog on the screen.

I highly recommend it for development to prevent catching potential issues late in the game, but it is development feature that will negatively affect that user experience if it accidentally escapes into the wild.   That is can be touchy subject for some developers.  

If you do use strict mode, I highly recommend that you turn it off in the release build.  The code will still exist in the code base, but it shouldn’t affect the user.   It will only appear in the debug builds.

I always add my strict mode block to a custom Application class.  In this case it goes into MyNotesApplication.  I created a new method, startStrictModeForDebuging, that contains all of the logic for initializing strict mode and only turning it on in the debug build,  I call this method in the applications onCreate method.

@Override
    public void onCreate() {
        super.onCreate();
        sApplicationContext = getApplicationContext();
        startStrictModeForDebugging();
        prepareDatabase(this);
    }


    /**
     * Start strict mode only when the app is built in debug mode.
     */
    private void startStrictModeForDebugging() {
            String packageName = Strings.nullToEmpty(sApplicationContext.getPackageName());
            if (packageName.endsWith(".debug")) {
                StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                        .detectAll()
                        .penaltyLog()
                        .penaltyDialog()
                        .build());

                StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll()
                        .penaltyLog()
                        .build());
            }
    }

I set up my strict mode to report violations to the log. Using the log instead of a dialog or crash requires more diligence on my part since I have to scan the log for problems instead of appearing as a slap-in-the-face notification.

I prefer this approach because it is less intrusive. I will break the rules when I am experimenting with features and I don’t want nuisance issues to get in the way. Reconfiguring strict mode for those times isn’t a big deal, but I also have to remember to undo the changes, which I tend to forget to do.

The other part of this code is the check for the debug build. I quick check on StackOverflow will give you several ways to achieve this, but I prefer to change the package name in debug mode. I can then check the package name to determine if the running build is the debug build or the release build.

This also has the added benefit that I can have the released version of my app installed side-by-side with the development version. That can make testing a lot nicer.

To do this requires a change in the gradle build file.

buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }

        release {
            ...
        }
    }

The one line addition of the applicationIdSuffix takes care of the package name change between the modes.  All it does is append “.debug” to default package name.  I can then look for that suffix in the code to programmatically detect the build type.