One of the many buzzwords thrown around the software devleopment community is Test Driven Development, or TDD. It is one of those phrases that sounds great when you say it - who wouldn’t want to have tests be their first priority when writing code?

However, it’s not always clear what TDD means. Does it mean you write code with testability in mind? Does it mean writing tests first? How can we write tests if we don’t have code to test? This post will answer all of those questions, and teach you how to implement TDD effectively on Android.

The Kotlin language used by Android developers all over the world is open source and available on GitHub. This means it’s open for contributions from anyone! It may, of course, feel very intimidating to contribute to a project of that size. Especially for those of us who are new to open source contributions.

The JetBrains team makes this process a lot less scary than it sounds. There are some beginner friendly ways to contribute to the language, and this post will walk you through every step.

As an Android developer, one of the questions I constantly see asked within the community is “what architecture pattern should I use?”

This discussion usually leads to a handful of buzzwordy acronyms:

• MVC
• MVP
• MVVM
• MVI
• MVU?? (We don’t talk about this but apparently it’s the new kid on the block)

This can be really intimidating to new Android devs, as well as seasoned veterans who are constantly questioning if they’re using the right one. Whether you’re trying to decide which one to learn, or wondering if the one you already use is best for you, this post will help lead you to the right decision.

How to properly architect your application is a concern we as developers constantly face. There’s unfortunately no one size fits all answer to it, and sometimes we don’t even know where to begin. I’ve learned along my Android journey that the answer can also vary depending on what portion of your app you’re trying to organize. Of course, you might say, it depends.

When it comes to your data layer, though, there are some really good tips on how to write clean, maintainable code. One of them is the Repository Pattern, and I’d like to provide a quick walk through of what it is and why it’s important.

Putting aside the long lasting debate right now about whether you should use RxJava or coroutines for your asynchronous code on Android, both camps often hit the same problem. How do I write unit tests for this?

Unit testing asynchronous code is tricky, because we may need to know how to properly test callback APIs, or perhaps we just want things to run instantly and not worry about thread changes. We may also be wondering how to handle not having a “main” thread in a junit test, unlike a connected test. This post will be focusing on handling that last one.