Why Im Skeptical about Kotlin Coroutines for Android Development

A few weeks ago, the folks working on Kotlin announced the 1.1 release. Kotlin’s 1.1 release has experiment support for coroutines. Here’s the elevator pitch for coroutines from their blog post announcing the release: Asynchronous programming is taking over the world, and the only thing that is holding us back is that non-blocking code adds considerable complexity to our systems. Kotlin now offers means to tame this complexity by making coroutines first-class citizens in the language through the single primitive: suspending functions. »

What Unit Tests are Trying to Tell us About Activities Pt 2

Activitys and Fragments, perhaps by some strange historical accidents, have been seen as the optimal building blocks upon which we can build our Android applications for much of the time that Android has been around. Let’s call this idea – the idea that Activitys and Fragments are the best building blocks for our apps – “android-centric” architecture. This series of posts is about the connection between the testability of android-centric architecture and the other problems that are now leading Android developers to reject it; it’s about how our unit tests are trying to tell us that Activitys and Fragments don’t make the best building blocks for our apps because they force us to write code with tight coupling and low cohesion. »

Some Resources for Learning how to Test Android Apps

Someone recently asked me how I “know so much” about testing android apps. After disabusing them of the notion that I know a lot about testing, I said that I’d write up a blog post of some helpful resources I’ve found and send it to them. This is that blog post. The resources are divided into books, articles, talks, and podcasts. I’ve marked resources that I think are essential with a “*”. »

What Unit Tests are Trying to Tell us about Activities: Pt. 1

Activitys and Fragments, perhaps by some strange historical accidents, have been seen as the optimal building blocks upon which we can build our Android applications for much of the time that Android has been around. Let’s call this idea – the idea that Activitys and Fragments are the best building blocks for our apps – “android-centric” architecture. This series of posts is about the connection between the testability of android-centric architecture and the other problems that are now leading Android developers to reject it; it’s about how our unit tests are trying to tell us that Activitys and Fragments don’t make the best building blocks for our apps because they force us to write code with tight coupling and low cohesion. »

Towards Godless Android Development: How and Why I Kill God Objects

Korean Translation by Jihyok KIM God is dead…and also Context is dead. –Friedrich Nietszche (probably) Godlessness in the context of OO-programming – unlike godlessness in a broader context – is uncontroversially a good thing. Some may want gods in school or gods in government, but – all other things being equal – no one really wants gods in their programs. In android development specifically, we have a god that we all know and love to hate: Context. »

Why Android Testing is so Hard: Historical Edition

As a profession, we also tend to be abysmally ignorant of our own history. David West, Object Thinking Almost two years ago, I wrote a couple articles that attempted to answer the question, “Why is testing Android apps so hard?” In those posts, I suggested that the standard architecture of Android applications is what makes testing difficult. This explanation of the difficulty of testing android apps raises a deeper, more historical question: why did an architecture that makes testing difficult became the default way of building Android apps in the first place? »

Why I Avoid Singletons for Android Data Loading

Imagine for a moment that there’s an annoying fly buzzing around your guests at a BBQ you’re hosting. You and your guests swat at it a few times, but no one manages to nail the sucker. You run into the house to grab a fly swatter, but you find that even if you wait for the fly to settle down somewhere, you can’t quite smash it. Frustrated and desperate, you decide to evacuate the party (and the state), get your hands on a nuke, and nuke the fly along with your backyard and neighborhood. »

Espresso Test Addiction: An Anti-pattern

More than 1000 apps…they have espresso tests for the first time using the test recorder…espresso adoption has also grown since the introduction of [the espresso test recorder]. Android Developers Backstage, Episode 37 Espresso Test Recorder, 31:10 Record-playback tools are almost always a bad idea for any kind of automation, since they resist changeability and obstruct useful abstractions. They are only worth having as a tool to generate fragments of scripts which you can then edit as a proper programming language… »

Exploiting Android-Specific Seams for Testing and Flexibility

As I pointed out throughout my series of posts on writing testable Android applications, the key to writing testable Android apps, is creating and exploiting seams. During these posts, I pointed out two types of seams that are available in any OO programming language and any programming environment. In this post, I want to highlight some Android-specific seams that we can leverage to make our applications more testable and flexible. »

Why I Don't use Robolectric

The more that I learn about testing, the more suspicious of Robolectric I get. I’m honestly starting to think that many of the heros of unit testing (e.g., Kent Beck, Michael Feathers, Steve Freeman, and Nat Pryce) would be pretty suspicious of Robolectric. Here are my concerns: Robolectric is largely1 a set of mocks for a set of types we don’t own. Mocking types we don’t own is not recommended by the folks who invented mocks. »