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.

A number of developers preach a single activity architecture on Android, which is something I’ve been trying to move forward to as well. In the process, though, I ran into one tricky problem. I don’t have something like startActivityResult for fragments. If you’re unfamiliar, startActivityForResult is a method that allows you to launch an activity with a specific request code, and when that activity finishes, your first activity will get a callback in onActivityResult and can do stuff with it.

This post is going to walk through how we can achieve that same affect using fragments.