Use Dagger 2 Map Multibinding to Inject Binders in Example Project

[ericleong]

For Graywater to display an item, it needs to know how to map an item to ViewHolderCreators (for inflating the view) and Binders (for binding the item to the view). In the middle are ItemBinders, which are simply lists of Binders that are needed for each item.

 Binders             ItemBinders                Items             Screen  
+--------+          +------------+          +-----------+       +--------+
| Photo  | -------- |            |       /- | TextPost  |       | Header |
+--------+    /---- | Photo Post | -\   /   +-----------+       +--------+
| Footer | --x /--- |            |   \----- | PhotoPost |       |        |
+--------+    x     +------------+    /     +-----------+       |        |
| Header | --x \--- |            | --/   /- | TextPost  |       | Text   |
+--------+    \---- | Text Post  |      /   +-----------+       |        |
| Text   | -------- |            | ----/                        |        |
+--------+          +------------+                              +--------+

Constructing the relationship between ItemBinders and Binders is necessary during initialization, because the complement of supported ItemBinders must be registered before items are added to the adapter. This can incur a large overhead if there are many types involved.

This pull request specifies the dependencies using Dagger 2 modules and leaves it up to Dagger to resolve the dependency graph using multibindings.

There are 3 multibinding maps:

• Map<Class<?>, ItemBinder>
• Map<CreatorKey, ViewHolderCreator>
• Map<Class<?>, ActionListener>

One may wonder why Map<Class<?>, Binder> is missing. It is unnecessary because the dependencies of every ItemBinder is known at compile time, but it is unknown which ItemBinders will be used in a list, since the list is not built until runtime. More importantly, it is easier to inject a Map than to inject each individual binder into the adapter.

To further improve initialization performance, we only construct the binders that are visible on screen.

 Binders             ItemBinders                Items             Screen  
+--------+          +------------+          +-----------+       +--------+
| Photo  |          |            |      /-- | TextPost  | -x--- | Header |
+--------+          | Photo Post |     /    +-----------+   \   +--------+
| Footer |          |            |    /     | PhotoPost |    \- |        |
+--------+          +------------+   /      +-----------+       |        |
| Header | ---\     |            | -/       | TextPost  |       | Text   |
+--------+     \--- | Text Post  |          +-----------+       |        |
| Text   | -------- |            |                              |        |
+--------+          +------------+                              +--------+

This works by changing List<Binder> to return List<Provider<Binder>>. Dagger 2 automatically supports Provider<Binder>, which allows us to defer the cost of binder initialization until the user scrolls. With the proper usage of scopes, extra initializations can be avoided.