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.

This is the second post in what will be an ongoing series to demonstrate a few different architecture patterns that are used for Android development. You can find the code for each of them, often appearing before the blog posts, by following this repo. Give it a star!

In our previous post we discussed the MVP architecture for building an app. This time, we’re going to check out MVVM.

This is the first post in what will be an ongoing series to demonstrate a few different architecture patterns that are used for Android development. You can find the code for each of them, often appearing before the blog posts, by following this repo. Give it a star!

The first architecture pattern we’re going to walk through is MVP.

So far we’ve covered four big buzzwords used in our application:

1. Model-View-ViewModel
2. Room
3. RxJava
4. Repository Pattern

Now, we should circle back to the beginning. Following our diagram outlined in the previous parts, the next component we can begin to work on is our AccountViewModel:

Naturally, this may bring up some confusion. We already discussed ViewModels in part 1. Well, depending on context, we may not be referring to the same thing.

In part 1 we discussed how we were going to architect the various components of our application. Now it’s time to build them. To understand what we should build first, we should revisit the diagram:

I would start with three spots:

1. The account
2. The database
3. The repository

A good rule of thumb to remember this, is that these nodes don’t depend on anything else just yet (well, the repository depends on the database, but that was included). I can’t build my ViewModel until I have my repository, and so on.

Let’s start with persistence.