When I was a kid, my father had a word for the car speeding ahead of us. He called it a “sponsor.” It was a joke, but the logic was clear: that driver in front would be the one to get fined — even though we were speeding too. The police can only stop one car at a time. So the sponsor takes the hit, and everyone else carries on.

This analogy applies to many organizations.

When you penalize teams for taking on risky and challenging projects, most teams will simply stop trying. Not because they lack ambition, but because no one wants to be the sponsor.

In large companies, leadership has limited bandwidth. Executives can only closely evaluate a handful of projects at any given time. The result is predictable: the most visible work gets attention, scrutiny, and resources, while most teams operate below the radar. And yet those under-the-radar teams make up the majority of the organization’s capacity.

Instead of moving at full speed, they self-regulate. Teams learn that visibility brings risk — more oversight, shifting priorities, unrealistic expectations, or becoming the next restructuring target. Staying unnoticed feels safer than standing out.

Innovation doesn’t slow because people lack ideas or motivation. It slows because the system trains people to optimize for safety instead of progress. The result is an organization with enormous theoretical capacity running at a fraction of its speed.

Organizations that want sustained innovation need to create space where experimentation is rewarded without automatically increasing scrutiny. Teams need to move quickly without feeling that success itself is a liability. When people stop optimizing for survival and start optimizing for outcomes, the dormant capacity inside large organizations becomes one of their strongest competitive advantages.

A/B testing is not easy: designing an experiment and analyzing data properly is a massive task, and technical implementation adds even more complexity to the mix. In this article, I will show how to streamline that last part of the A/B testing process on Android to focus on what matters the most — your data.

A/B testing complexity

Let’s start with the complexity associated with A/B testing before I offer the solution. So, what are the problems?

• Async communications — the configuration of the experiment is often located at the server so the client needs to fetch it first, and this operation is asynchronous. That brings many questions: how do we show the UI? Do we need to wait? How do we check the latest configuration is loaded?
• Multi-layer changes — with most modern apps adopting one or another form of layered architecture an A/B test touches almost every layer in the app: it needs to be received from the network, stored somewhere in persisted storage, tracked on the domain-logic layer, and displayed through UI layer. That’s too many places to make a mistake (e.g see this article).
• Multi-experiment tracking — with more and more experiments added to the app it’s harder to track which experiments are present at all, which can be active at the time, and whether they interfere with each other.
• Sunsetting — after the experiment is over one needs to go and clean up the code from all the layers affected at the previous step. Things like configuration models and resources often get forgotten along the way and stay in the code base for months after they aren’t needed anymore.
• Boilerplate — UI changes may be as simple as a single button’s color change or as complex as a whole new layout, in both cases at least one if-else/switch-case is required. And all should be done in a way they won’t get lost during sunsetting.

Solution requirements

If we were given enough time to design a complete solution to the aforementioned problems how would it look like? Here is my proposed library requirements. (Scroll to the last paragraph to get straight to the code samples)

• Fully synchronous experiment configuration fetching — most of the tools that define the cohorts for A/B not making the decision in real-time, and not delivering it instantaneously either, there is no point in trying to get the current state of the server-side config: whatever state was actual at the moment of app launch should be the state of the A/B test deeper in the app flow (BTW recommended config fetching interval for Firebase is 12h). That doesn’t just reduce the bandwidth usage and increases responsiveness, it eliminates tricky bugs caused by fetching the updated config while one or more experiments have already been shown to a user.
• Ability to enable the experiment locally — A and B groups for an experiment should be defined in advance and stay intact (that’s the best way to keep them truly independently randomized) but the experiment itself may not be available yet to a user until a certain event happens. It’s then required to activate experimental UI A or B immediately after, ideally without network round-trip, or extra code that checks for experiment activation status.
• Single point of configuration — to keep track of all experiments we need to keep them registered in one place so it’s easy to see what’s active now. We’ll also need this point to set the configuration for integration and functional tests.
• Statically typed enum-like configuration—once the experiment is started the sub-parameter can not change otherwise we’ll get inconsistent data. That immutability, in turn, allows us to create a data-class with a complete set of required parameters for each experiment variant. The enum nature will prevent us from accidentally skipping one of the options within the switch or when statement. Once the experiment is over we can remove the class, and the code won’t compile until we properly remove all the places the experiment was affecting.
• Automatic resources resolving — many experiments are as simple as showing a new layout for the same data. It would be much more convenient to provide two layouts like cart_screen_variant_compact / cart_screen_variant_verbose for an experiment that has variants “Compact” and “Verbose” and let the framework inflate proper layout automatically. And during the sunset phase, we can then remove all the resources with either _verbose or _compact suffix and be sure nothing unused is left.
• Testability — we don’t want to see a random experiment’s variant during the testing phase, so there should be an easy way to launch any given variant, and it should be possible to mock the experimentation framework when needed.

Solution

With all these requirements in mind, I’ve created a library let’s see how that works (links to the library repo and maven below)!

Here is an example of the minimal A/B test configuration, for a simple test.

(I’ll cover more use-cases in a separate article, but the repo already contains the sample project, and the documentation describes the solutions for the most common cases)

A simple experiment with automatic resources resolution

All we need to do is

• define an enum that extends theVariant interface

enum class AutoResourceExperiment : Variant {STRANGE, CHARM}

• and register it like that

CadabraAndroid.initialize(this)
CadabraAndroid.config
        .startExperiment(
           AutoResourceExperiment::class,
           RandomResolver(AutoResourceExperiment::class))

With auto-resources resolving layouts and strings that have suffixes _strange or _charm (according to the declared variants) will be automatically resolved by the special context wrapper, with the additional safety layer of defaulting to the explicitly provided resource if the desired one is not found.

val ct = cadabra.getExperimentContext(AutoResourceExperiment::class)

// use `_strange` by default and `_charm` if Variant CHARM is active
showAlertDialog(
    ct.getStringId(R.string.dialog_title_strange),
    ct.getLayoutId(R.layout.dialog_layout_strange))

The experiment context is bound to a single experiment so it won’t accidentally pick up the wrong resource if variant “Strange” is active for another experiment, but it’s a good practice to give variant longer more specific names.

An experiment with custom data

Should the experiment require more complex parameters than resources, they can be provided as Variant fields

enum class FancyExperiment(
    val screenLayout: Layout,
    val screenContent: Content,
    val itemsLimitPerPage: Int
) : Variant {
    CHARM(Layout.WIDE, Content.COMPLETE, 10),
    STRANGE(Layout.COMPACT, Content.FAVORITES, 20),
}

And later retrieved via Cadabra singleton

val aVariant = cadabra.getExperimentVariant(FancyExperiment::class)

when (aVariant.screenLayout) {
    WIDE -> setContentView(R.layout.activity_wide)
    COMPACT -> setContentView(R.layout.activity_compact)
}
loadContent(
    favoritesOnly = aVariant.screenContent == Content.FAVORITES,
    numberOfItems = aVariant.itemsLimitPerPage
)

Experiments activation

For the real-life scenario, we’d need some service to control the experiments, like Firebase, which is supported out of the box

CadabraAndroid.config
    // register experiments without starting
    .registerExperiment(FancyExperiment::class)
    // load experiments config from Firebase
    .startExperimentsAsync(FirebaseConfigProvider())

FirebaseConfigProvider is part of the library, and any other services including custom in-house endpoints can be added via extensible providers API.

Note the explicit registration step, which prevents accidental starting of the experiment that’s not ready yet or has been disabled already.

Design

The key design aspects of the library

• It’s Kotlin-first but fully supports Java: all companion’s methods exported as statics, there are no coroutines or flows, and both Class and KClass parameters are supported.
• It’s lightweight and modularized: can be imported as core-only for pure Java/Kotlin modules or as an Android library to enable automatic resource resolving.
• It’s extensible: the most basic ways of resolving the active experiment’s variant are supported out of the box, including Firebase Remote Config, but custom resolvers are allowed.
• It’s testable: the entry point is designed as a minimalistic interface, not a class, so if you need to provide fake/mock implementation for tests, that can be done in a couple of lines of code. If you ever tried to mock Firebase SDK you know what I’m talking about.

That’s pretty much it. Check the repository for more examples and the documentation, and please reach out if you feel that you have a use-case that Cadabra doesn’t cover well.

• fo2rist/cadabra
• Maven Repository: com.fo2rist.cadabra

Android A/B testing Made Simple With Cadabra Library was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

(The article is based on my 25 min Droidcon Online presentation, but provides more examples and details. Scroll down for the best practices list.)

0. Scope functions overview

First, let's do a recap.

Scope function is the function executes arbitrary code (lambda that you pass) in the scope of the context-object.

Extension function is the function that takes a receiver, which becomes this inside the function and serves as the context.

1. Problem definition

So what the problem with them, and how can they harm the code?

• Each extension function switches the context of execution and the context of the reader

• Each scope function adds context to the one that already exists (context of our class or outer function). The more we need to memorize, the harder it’s to read the code. We also need to remember which scope functions return the result and which return the scope-object itself.

That may seem easy but try to recall which two functions on this image take lambda with a receiver (T.() -> R) and which two return the result of the lambda?

In some extreme cases, accidental use of the wrong scope or extension function can even lead to error, during compilation or in runtime.

Enough theory, let’s check some production code!

3. Examples from real life

a) That one I found in the medium article about the “best” practices, which suggests several improvements, like the following

as you can see the “improved” approach indeed is much shorter, but it’s not clear at all whether it returns the file, or the path, or nothing at all. What’s not obvious either is that path.let part is not needed at all, the function can be reduced to fun makeDir(path: String) = File(path).also{ it.mkdirs() }

b) and here is the one from the app I’m working on

it’s kinda OK, but only because of IDE hint, during code-review, it looks like that (now it’s hard to tell what’s first and second)

that can be slightly improved if we use lambda with parameter instead of a lambda with receiver

and even further with explicit name and restructuring of a pair

but let’s compare it to the version without any scope functions. It’s actually shorter and reads equally well.

c) that’s not to say no one should use clever tricks with scope or extension function. Here is the parameterized JUnit4 test, that doesn’t look great

but with customand and shouldReturn functions it’s now 100% clear how to read test data.

4. Recommendations

Kotlin’s own documentation offers the guide for scope functions, but it’s quite vague and examples demonstrate mostly the capabilities rather than the good style, and there is no guide for extension functions whatsoever. So here is my proposed guide, which consists of mnemonics (for each function) and rules (for general cases).

Scope functions unofficial guide

Mnemonics

• [If I need to] Let it work with a nullable value → let.
  The key is that it lets us use the object that may not be available sometimes. nullable?.let { log(it) }
• [If I need to] Apply configuration → apply.
  The key is that we change some properties we can’t set via the constructor. ServerConfig(host).apply { port = 8888 }
• [If I need to]Return an object, and also do something → also.
  The key is that we do all the main job in the function and ready to return an object, but also need to do something auxiliary, like logging.
  return Something(withParameters).also { log("Created $it") }
• [If I need to]Do multiple similar things with an object → with.
  The key is that we are working with one and only one object doing multiple related operations with it.
  with(service) { connect(); sendData(data); disconnect() }
• Don’t use run! Run away from it!
  Really, there is no reason to, other functions cover everything.

Rules

• If it returns the result — keep it one line.
  That rule helps a lot with the readability of long lambdas where the last statement happens to be a return value, when it’s one line it’s much easier to see that something is returned without explicit “return”.
• If it works with an object — use a single object.
  Multiple receivers are hard to track, and two separate this in one scope is enough.
• Establish patterns.
  Even if some clever trick may not be obvious, it becomes clear and mundane when used often enough. So find use-cases and use the same functions for them every time: e.g. let for nullable variables, apply for builders, also for logging, etc.
• Don’t try to make the code shorter.
  That’s never the goal, even Kotlin’s developer and advocate Roman Elizarov in his review of functions with receiver emphasizes that the brevity should not come at the expense of clarity.

Extension function unofficial guide

• apply action to the receiver.
  Non-infix extension function should not treat left (receiver) and right (arguments) sides equally, it applies an action to the left with parameters from the right. In the example below the second function has the signature fun String.connect(vararg params: String) that doesn’t make much sense.

• nest under an object or an extra package.
  Extension almost always requires an extra nesting level that matches the file name they’re defined at so that the imports make sense for the reader. In the example below function names are very generic (and, or) but the extra package testutils clarifies the first case.

• avoid using existing names (e.g. toString, to, run).
  Failing on that can cause severe real-time issues. Build-in extensions do not require any imports, so if the code contains any custom function with a name like run, plus, let it will work till the moment it’s copied somewhere or IDE reorganizes the imports, at which point it would likely still remain compilable, but will produce an unexpected result.

5. Summary

It’s easy to prevent Kotlin features abuse with little discipline a couple of rules. Focus on the business task and readability rather than on cleverness and brevity, and the can solve that problem entirely!

Safe coding!

Here is the original #droidcon presentation, and full code from this video can be found here.

Kotlin scope and extension functions. How to not harm your code. was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

So what’s the problem with NullPointerException in Kotlin? Both Google and JetBrains promote Kotlin as safe & interoperable language, not necessarily emphasizing enough that it’s not intrinsically free from NPEs, in fact, if misused Kotlin code will throw as many KNPEs and similar exceptions. How do we convert old Java code into Kotlin safely then?

1. Know the exact sources of the problems

• Kotlin is not that safe on the boundaries: Nullable/NonNull annotations in Java code by default produce warnings in Java and compiler errors Kotlin and passing null to the NonNull parameter does nothing in Java, until you dereference this null, but it throws a runtime error immediately in Kotlin. That leads to two problems: 1) all ignored warnings or missed annotation can “leak” nulls into Kotlins “null-safe” variables 2) the Java code that was avoiding NPEs can start crashing after 1:1 conversion into Kotlin.
• Kotlin is not safe on deserialization: serialization is not safe and quite tricky even in Java but Kotlin adds a couple more potential issues to that: default values, sealed classes and nullability itself. Since deserialization may create an instance without calling a user-defined constructor where all values are checked for null and set to defaults the resulting object can have nulls in non-nullable fields. And for the sealed classes it may produce a second instance of Kotlin’s singleton object and make all following when expressions with this object incorrect.
• Kotlin is not safe on lateinit properties: lateinit properties effectively work exactly the same way as nullable fields in Java, they may or may not reference an object if they don’t — the code will fail in runtime, and the only way to prevent it is to check if the property is initialized.

Now, when the caveats are clear, comes the solution.

2. Follow a formal migration plan

The plan covers the migration of an existing Java class into Kotlin, writing a new Kotlin file would follow a subset of these rules.

1. Annotate all fields, parameters and return values with Nullable/NonNull annotations. Annotation for return values is based on the actual result, and for the public fields and method parameters, the NonNull can be used only if it’s possible to prove that no external code can pass null there. Use Nullable otherwise, or when in doubt. Note that it’s impossible to add annotations to the Java arrays so mark them with a plain comment for future.

2. Fix all null-related warnings that may appear after annotations were added (there isn’t any in the example).

3. Convert the file into Kotlin using IDE or manually. If using the IDE don’t let it “correct” external code, it may produce too many unnecessary changes

4. Add JvmName/JvmStatic annotations to fix the code that’s still used from Java to not produce unnecessary changes in the codebase.

5. Fix all “!!” in the resulting Kotlin file. Note that most of the “!!”s in the auto-generated code are caused by not fixed nullability warnings.

6. Clean up the code.

Here is the complete sequence on Gist.

That’s it! Stay safe!

No more NPE. Converting Java file to Kotlin safely. was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

I decided to learn how to surf several months ago, I watched YouTube tutorials and have practiced weekly since then. Yet, I’m still pretty bad at that. So bad that this weekend I finally took the first professional lesson and that lesson taught me not just how to surf but also how to answer the question “Why do we need to learn all these basics like algorithms and data-structures?”

With my surfing activity, I was trying to overcompensate the lack of stability and speed with different timing and more intense paddling, effectively wasting a lot of time and energy doing so. Turns out the root cause was completely different and I simply didn’t place my feet the right way…

The same idea applies to the basic ideas of computer science: the hardware architecture defines which data structures and algorithms are more efficient, and the limitations and advantages of particular algorithms shape high-level design approaches (think about pointers, lists, hashmaps, mutexes, immutability, functional programming, reactive programming, map-reduce, etc.)

I wasn’t able to improve my ride by solving symptoms like low speed and poor balance with wrong and time-consuming measures like harder paddling, similarly, someone not familiar with the basic limitations of an algorithm or a library can waste months in attempts to improve the app performance tweaking inputs of this library based on suggestions from Stack Overflow and YouTube.

That doesn’t mean everyone should be able to write a sorting algorithm on a whiteboard (unless we a talking about passing an interview in Silicon Valley) but it definitely helps to know the typical efficiency and potential bottlenecks.

Data structures and sorting algorithms are low-level details, the higher-level design is vaguer and there is rarely a single indisputable best solution, but I’d say that the rule of basics still works. Say it’s unclear whether to apply relatively simple and well-known principles such as SOLID to an OOP system. One can argue that printing and formatting a string are two different responsibilities while someone else can say that formatting is essential for printing. To resolve such contradiction we can again turn to basics and ask a simple question: “What is the fundamental problem the solution I’m applying was designed to solve?” The answer may be a bit more verbose than a distilled form of SRP but it will be more precise as well. Bob Martin coined the term SRP to address the problem of the requirements that change for different reasons and cause the code changes which in turn often leads to regressions. In fact, the original definition of SRP is not complex

“Software module should have one and only one reason to change”

what we have here is the definition of a broader basic problem that can answer not only the questions which libraries, classes, function to split but also which ones to join. So a better understanding of the underlying principle can lead to a better design.

Like almost anything in this world, education isn’t free and learning basic stuff is a long, tedious process that never pays off immediately, but the fast “give me the single answer” approach may not pay off at all. A surf coach told me that I need to repeat feet positioning exercise twice a day, every day, at home, on the floor. I don’t need a beautiful blue ocean and golden beach for that, it’s not much fun, just a solid tangible result.

My team works on one application, it has decent (80-90%) code coverage and yet every month we have regressions detected during manual QA process, which slip through automated tests. Why is that?

Well, because code coverage doesn’t warrant good tests. Test coverage information only helps with unit-tests and almost useless for everything else. Moreover, the mere presence of the coverage number can be harmful!

What was wrong with our code coverage?

Our SDET team measured code coverage for end-to-end UI tests (those that would click on buttons in the app on users’ behalf). Some time ago management asked SDETs to measure the coverage and to achieve a certain number in it. So they did. In fact, to maintain a high number they have to update the tests every time the UI changes (and it changes with every release for a mobile app) so they spent more time (and money) fixing tests and reacting on false-positives than on increasing the actual test coverage (management even went that far to recommend measuring coverage for manual tests, which fortunately never happened, and we have different guidelines now so I can safely tell this story).

Why exactly high-coverage-test doesn’t detect regressions?

Let’s take a small library I’m working on as an example. Without the test for the root-class CadabraImpl the coverage looks like that

Something is definitely not covered in VariantKt class, but let’s add the integration test for root-class CadabraImpl back and see…

VariantKt is a simple class that happens to be used in the larger one for which an integration test is required.

Integration tests always invoke constructors of different classes, call some methods, etc. to prove that classes work well together, but do nothing to prove their correctness, yet these calls will be detected by code-coverage reporting tool. The same happens with UI tests: even that application startup alone can produce significant coverage numbers, all the sub-modules initialized at startup will look like they’re covered. So integration and UI tests essentially become assertion-free tests in disguise if the code coverage interpreted as a measure of completeness because such tests never (as they should) have assertions to assess the behavior of all inner classes.

What the coverage is all about then?

It’s been a lot written on the topic (e.g). In short, similarly to Dijkstra’s famous phrase “Testing shows the presence, not the absence of bugs” we can say that code coverage shows the absence, not the presence of tests, and it definitely says nothing about their quality.

In the example above TDD style or bottom-up approach would do a better job: during the smaller class construction phase we can test it properly, make sure it works and only after that write some integration tests, the final coverage number would be same but our confidence in tests would be much higher.

Focusing on unit tests and covering small pieces at a time helps ensure every single part is working well, and there is no unused code (if it’s not covered maybe we should delete the code instead of adding a test). And not measuring coverage for integration and UI tests allows us to focus more on the actual purpose of such tests — integration aspects and observed behavior.

Can we still have coverage?

There may still be a reason or two to measure code coverage for non-unit tests or even strive for a high coverage number and modern tools can alleviate the problem by showing not only the number and covered lines/branched but also the “source” of coverage (e.g) but measuring a single number without understanding and properly communicating the meaning of it most likely will produce yet another “dashboard promoting ignorance”.

Stay covered!

Code Coverage. You Don’t Need It! was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

RxJava in the unit-tests can swallow the exception which would crash the real Android app. Here is how to fix the tests.

Suppose we’re using RxJava in our Android app, and we cover it with unit-tests. Does it mean the same code that passes the test won’t crash the app in production on the same input data? No! But why?

Let’s check the simplified example. The waitAndFail function emulates some background work and then it throws an exception. In theory, this test should fail, in practice, it prints an error message to the console and finished successfully. The same function used in the Android app will crash it.

But we’ll see something like that in the console

io.reactivex.exceptions.OnErrorNotImplementedException: The exception was not handled due to missing onError handler in the subscribe() method call. Further reading: https://github.com/ReactiveX/RxJava/wiki/Error-Handling | java.lang.IllegalStateException
 at io.reactivex.internal.functions.Functions$OnErrorMissingConsumer.accept(Functions.java:704)
...

The reason is that ART (and Dalvik) virtual machine, that runs the app, and local JVM, that runs the tests, have different uncaught error handlers. In Java, each thread has one, and when the exception happens in the thread, JVM calls this thread’s handler. The default behavior for Android is to log the exception and terminate the process, while the default desktop JVM’s error handler prints the exception and ignores it. But if we get the exception in the test function it should fail, shouldn’t it? Yes, but RxJava doesn’t rethrow exceptions it captures and calls the tread’s handler directly, instead.

So how to fix that? How to make code under unit-tests crash when (and only when) the application would crash give correct feedback as early as possible?

JUnit allows us to add rules to the test to execute arbitrary code before and after each test, we can use that to install a scheduler that actually crashes to the main thread and to ensure the is executed in the same thread we can install RxJava’s handy trampoline scheduler. Now all our asynchronous code becomes synchronous, so the test will not finish before it actually gets to the exception and it will not ignore the exception anymore.

Then this rule can be used in any test (and in combination with different rules) as

@get:Rule
val rxRule = RxSchedulersTrampolineTestRule()

The problem may sound a bit artificial, but in real life developers often forget onError function in subscribe or throw the exception from the wrong place, and if the test is not designed for such case the exception will slip through. So a strict rule serves as an extra guard rail, that can highlight the problem with the code or with the test itself.

Kotlin Data Classes are great; they’re concise, they’re null-safe. Gson is great as well; it’s a de-facto standard for JSON parsing on Android for a good reason. But! Data classes parsed via Gson guarantee neither null-safety nor even default values. Or do they?

The Problem

There is an excellent article describing an issue. TL;DR if you have a data class like that

the default values will be ignored, so JSON like {"intValue":2} will produce object {intValue=2,srtValue=null} instead of expected {intValue=2,srtValue="default"}

Good news, there is a way to fix that!

The Solution

Let’s change our data class a little bit.

Notice the subtle difference? This class defines default values for all fields. That’s it! As soon as all the fields have the default values, Gson will respect them when the corresponding fields are missing in JSON (if you don’t need the default values, use nulls).

Why does it work?

The Reason

It really boils down to two features.

1. Kotlin’s Java Overloads.

Compare two classes

the byte-code for them will result with the following Java

as soon as all fields have the default values, Kotlin compiler will generate default parameterless constructor in addition to the other overloaded versions it produces.

2. Java’s Unsafe Invocations in Gson

The presence of default constructor is important for Gson. The way it works is roughly the following (see ConstructorConstructor’s code for more details):

• try to create an object via provided InstanceCreator implementation based on type-token
• try to invoke the default constructor
• try to invoke known constructor for maps, sets, queues, etc.
• use unsafe allocation if nothing helps (more details about unsafe allocation)

That means, if you don’t provide the instance creator and your class doesn’t have the default constructor, the object will be created without the constructor call. Kotlin puts all the null checks and default values assignments to the constructor, so all of them will be skipped.

So if you’re good with Gson and not ready yet to move to a new library that supports Kotlin defaults like Moshi, define all default values in data classes and let Gson do the rest.

Is that it? Well…

The caveat

The solution above works well for JSON with missed fields, but there is one more problem. The nullability defined in Kotlin code may not be respected in JSON, and Gson will not complain about JSON like {"intValue":2,"strValue":null} that contains explicit null. If that kind of situation possible, define all non-primitive fields as nullable to avoid unexpected crashes in production.

Now that’s it. Happy parsing!

Safe Parsing Kotlin Data-classes with Gson was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

The simple strategy for dealing with exceptions.

Exception handling is still a debatable topic nearly 60 years after the invention. Thirty years later Java pioneered the checked exceptions, another clever but often misused concept which drew a lot of criticism and was abandoned by followers like Scala and Kotlin. Anyway, the exceptions are still there for most of the application-level languages, and handling is on us.

So how should we work with exceptions? I want to advocate for the simple strategy I follow for the last several years.

Pre-conditions

Before starting with the strategy itself, let’s cover the typical edge cases and the assumptions it relies on.

Not an exception — don’t throw

To handle the exceptions properly, we should only throw the proper exceptions first. Start with Java official documentation (same for C#), consider best practices, and never throw unneeded exceptions anymore. Exceptions meant to be exceptional. Negative and empty results are not exceptions!

Can’t control — accept

In some cases, we can’t control how an exception should be handled (e.g., checked exception in Java) so there is no need to think about it: we should follow the platform recommendations. When file-reading function always throws EOF exception we have no option but to handle it.

Don’t care — ignore

Finally, if we don’t care about some exception, we can catch and ignore it. There is a bunch of libraries that don’t follow the best practices and throw random exceptions here and there. If the exception doesn’t provide the information and doesn’t mean any unrecoverable state or observable error, there is no need to waste time on it. Don’t forget to document the reason for ignoring the exception, though!

The strategy

Now, when everything else is covered in pre-conditions, we can focus on the actual exceptional cases such as NPEs, various I/O problems, etc. These are the real issues that may happen during the app execution and cause the unwanted and observable result to the end-user. The strategy is just three simple questions, ask them in the same order to find a way of handling the particular exception.

That gives us four possible actions; let’s see how they work.

Avoid

The best exception is the exception that was never thrown. If the library throws when not initialized — initialize it. If the method can not work with nulls — make sure it impossible to pass the null. The code with lots of try/catch blocks is even harder to read than the code lots of if/else. Compare two approaches:

the difference is even more apparent when we only care about the positive scenario

Recover

Now we have a possible exception, say we need to dereference nullable object or perform an operation that may fail. Can this piece of code recover from that exception? I mean actually recover. For example, a networking layer can retry the call if it allowed doing so, but it can barely deal with the unparsable result, or the WiFi turned off. So it should not! No need to construct a fake result: yes, a banking app can display the account balance of $0.00 if it can not find the account but should it? An attempt to add the proper recovery code most likely will end up with the violation of SRP and an extreme number of injected dependencies.

Pass

Now we know that the piece of the code deals with an exception it unable to handle, but is that possible during normal execution? If yes and we already know, that we can neither avoid, nor recover, then the only action we can take is to wrap the exception to make it more specific and informative and re-throw. The upper layer, in turns, could be able to recover from that situation; in the example above it can refresh the list of accounts, or ask to reconnect WiFi.

Crash

Finally, if the answer to the last question was no. What does it mean that exception is impossible during normal execution? That means we violate some invariants that must be maintained by our system. An example would be the dereference of a nullable/late-init field that supposed to be injected in a class that’s always instantiated via DI framework. In other words, we own and fully control the code, and it depends not on the environment (user, network, disk), but on usage. We may get such an exception only if we add incorrect instructions inside the system. And if that happens, we’d better know about it as soon as possible. Crashing may be unpopular advice but let’s consider the alternatives:

• Catch it and try to handle: that will result with the bloated code pretty much immediately. Can we put initialization checking logic into every single internal method? Shall we wrap every dereference of the variable that’s never null? Moreover, if the handling is complicated, it can cause even more bugs and will make the unit-testing harder for sure.
• Swallow and ignore: that will lead to unpredicted behavior. Even if the app doesn’t crash is that better for a user when the buttons don’t do what they supposed to do, and the information on the screen is misleading? If some internal application invariant is broken, that means the logic is broken as well and the app is not useful anyway.
• Log and re-throw: developers often add extensive logs but is it a good practice? If the upper layer can handle the exception, that means the logging was unnecessary, and if cannot and takes the same logging approach, it will bloat the logs making the issue harder to analyze. Logging — is the form of exception handling, do it only if it’s appropriate.

Crashing, on the other hand, will let us know about the issue immediately on the testing phase, even before the QA team tries the latest version of the app. And what if the impossible possible and the app start crashing in the users’ hands? We still want to know about it ASAP. All other approached would delay the feedback loop: how long would it take for an average team to figure out that there is a spike of suspicious activity in the logs? How many users would get incorrect bank statements or even worse by that time?

Track

As you can see, the previous rule only makes sense if we have a feedback loop! Good news that there is a bunch of alerting solutions for mobile and web applications. With proper alerts monitoring in place, we can react to the critical issues in days if not hours, preventing more harm to our users and ourselves.

So the whole strategy is just four rules of thumb:

• Avoid if possible
• Recover if not avoidable
• Pass if possible
• Crash & Track otherwise

Let your code be exceptionally stable by letting it crash early!

Handling Exceptions. The Easy Way. was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot was written about the TDD approach, in essence, it relies on one assumption — your tests are fast. If the tests are slow Red—Green—Refactor cycle is permanently stuck on the tests execution phase rather than on coding. That also assumes that you do know how to write tests. Many people try and give up because they’re not feeling productive, and it’s hard to keep doing something that slows and sacrifice the performance for some imaginary future stability or maintainability gain.

But what if there is a way to try TDD, even with slow UI tests, and still increase the productivity and the code coverage at the same time?

The approach I adopted recently for Android Espresso tests helped me both keep practicing in tests writing, hence developing the skill, and ship faster with simple steps.

1. Launch it

Every time I need to make a new screen in the app I start with an extremely minimalistic test that contains activity rule only. So once I launch any test the activity starts, and that’s when I write the setup code of the activity. That saves me the time I’d otherwise spend navigating to the new activity through the app.

2. Design it

Once the activity is running I need a way to keep it on the screen to design the layout. And here goes the infinite loop*. The test itself is not executed in the application’s main thread, so it’s safe to sleep there and the application will keep working. After every significant layout change, I relaunch the test. (Yes, there is Instant Run but it’s not stable and the new version of the same feature is not available yet)

3. Test it

Now when the layout is pretty and looks exactly as designed, I can wire the logic (which is ideally already covered with the proper unit-tests) and at the same time some minimalistic integration test that will serve as the guard rail in the future and validate some basic things like “Is the header visible?”, “Can user scroll?”, “Is submit button actually disabled by default?” which can not be validated by the unit tests.

That’s it! The whole boilerplate is a mere 3 lines of code. And the real tests are even less verbose with Kakao library and all view-access details isolated via the Page Object pattern.

Happy testing!

[*] in fact I even have the template in Android Studio that replaces word forever with `if (true) while(true) Thread.sleep(100);` that works equally well with Kotlin and Java files without modifications.

A non-traditional approach to TDD with Espresso was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.