Advanced Android - Architecture with Dagger 2 and more

We'll start with a fresh project and add some initial dependencies that we'll use in the following lesson.

Here we will add logic to handle clearing our @ScreenScope components at the appropriate time.

A quick walkthrough of how Dagger's generated files accomplish the injection logic in our Application, Activity, and Screen scopes (up to this point).

As we go along in the project, we will do more walkthroughs so you can get comfortable with how Dagger works.

We will create an object that can be injected and will allow us to handle navigation to/from screens outside the View layer. Having this separated from the View layer will allow for better separation of concerns which also allows for more comprehensive testing.

We'll define the models and type adapters that will be required to set up our networking objects.

Here we'll examine the classes that AutoValue and our AutoValue extension generates for us more closely. You can skip this is you are comfortable with how AutoValue works.

In this video we create our Networking modules that will provide our Retrofit instance to the rest of the application. This will also set us up for having separate network configurations in different build types (debug/release).

High level overview how RxJava works.

A quick look at some of the more common operators in RxJava.

How to read marble diagrams.

A quick overview of RxJava Types (Observable, Single, Maybe)

We'll create our first Presenter and View Model classes for our Trending Repos Screen.

Now that we have some more injected classes, this is another informational video to go through what Dagger is doing under the hood to satisfy dependencies, including looking at how scoped dependencies differ in the Dagger generated code.

If you're comfortable with Dagger and how it works, you can skip this video.

Quick video to get our Mockito dependency ready

Here we'll set up a way to load mock responses and add unit tests for the TrendingReposViewModel

We'll finish out this round of unit tests by adding some for the TrendingReposPresenter

In this video we are going to set up our UI Test Framework which will allow us to use Dagger to provide test doubles of our dependencies.

We'll have to create several new classes, and this video will move pretty quick so we can get down to writing some UI tests.

A quick statement on what it takes to add a screen.

We'll create the first classes for our Repo Details screen. This will involved using the `@BindsInstance` annotation to allow us to make arguments from a Bundle passed to the new Controller injectable.

We already have repos loaded in order to display our list data. When we select a repo, we don't want to reload that data from the API if we don't have to. Using a Repository, we can use cached data if it's available, but fall back to the API if we need to load it (this could happen after process death, for example).

This video will concentrate on creating a Repository for our repo data.

Let's get in the habit of writing our unit tests right after we finish creating an object that can be tested.

We'll create some unit tests for our new RepoRepository in this video.

Now that we have a repository, we can start creating our Repo details classes. We'll start with the view model.

Keeping up with our new trend, we'll add unit tests for the view model we just created.

Here we'll see how we can chain RxJava types together into one stream.

We need to fetch a Repo, followed by its Contributors--we can do that in one RxJava stream!

Quick video here for adding tests to our presenter.

After moving our `subscribeOn` scheduler to the repository, our tests started acting up. In this video I'll explain why that is and how we can fix it.

Quick video here to add a method to our ScreenNavigator to allow us to navigate to the details screen.

We need another adapter for our Contributors list. This is going to look very similar to our RepoAdapter.

In a future lesson, we are going to make creating RecyclerViews much faster and leverage Dagger to do so. For now, bear with me as we knock out some boilerplate.

In this video we'll finish our details Controller using the data provided by the view model.

To be able to verify loading state, we need a way to make our service "wait" before emitting items.

We can use int flags to be able to set error states and hold states for all of our different endpoints.

We can move some of the Espresso logic to a "robot" class so our test assertions become more fluent and easy to read.

Now that we have an improved framework and a "robot" helper class, let's create the UI tests for our details screen.

We'll create a Gradle task that copies mock responses from a root directory in our project to the resources directory in our test, debug, and androidTest packages. This will allow us to have our mock responses defined in one spot and have them be accessible in each different environment.

We'll create a drawer that we can pull out from the right side of the screen when in a debug build. We can then add things there that we can manipulate while using the app which makes testing much faster.

Here we create a MockInterceptor that will allow us to use mock responses while running the debug build of our app.