Dagger に馴染めない人のためのいくつかの原則

Keeping the Daggers Sharp ⚔️ – Square Corner Blog – Medium

Dagger2 は 素晴らしい Dependency Injection ライブラリですが, なかなか上手に使いこなせません.

分かりやすくするための考え方や実装方法をいくつか見てみましょう.

フィールドよりコンストラクタのインジェクションを使う

フィールドインジェクションは, finalでなく, privateでないフィールドに使います.


// BAD
class CardConverter {

  @Inject PublicKeyManager publicKeyManager;

  @Inject public CardConverter() {}

}

フィールドに @Inject を忘れると NullPointerException の原因となります.


// BAD
class CardConverter {

  @Inject PublicKeyManager publicKeyManager;
  Analytics analytics; // Oops, forgot to @Inject

  @Inject public CardConverter() {}

}

コンストラクタインジェクションはイミュータブルですので, 局所的な状態を持ちませんのでスレッドセーフにつながります.


// GOOD
class CardConverter {

  private final PublicKeyManager publicKeyManager;

  @Inject public CardConverter(PublicKeyManager publicKeyManager) {
    this.publicKeyManager = publicKeyManager;
  }

}

Kotlinでは, さらに簡素化してくれます.


class CardConverter

@Inject constructor(
  private val publicKeyManager: PublicKeyManager)

それでも, フィールドインジェクションを使いたい場合は以下のようになります.


public class MainActivity extends Activity {

  public interface Component {
    void inject(MainActivity activity);
  }

  @Inject ToastFactory toastFactory;

  @Override protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Component component = SquareApplication.component(this);
    component.inject(this);
  }

}

Singleton はあまり使う必要はない

ミュータブルな状態に対して多くのアクセスが必要な場合は Singleton は便利です.


// GOOD
@Singleton
public class BadgeCounter {

  public final Observable<Integer> badgeCount;

  @Inject public BadgeCounter(...) {
     badgeCount = ...
  }

}

しかし, 変化しない状態に対しては Singleton にする必要はありません.


// BAD, should not be a singleton!
@Singleton
class RealToastFactory implements ToastFactory {

  private final Application context;

  @Inject public RealToastFactory(Application context) {
    this.context = context;
  }

  @Override public Toast makeText(int resId, int duration) {
    return Toast.makeText(context, resId, duration);
  }

}

まれに, 作成のコストがかかるキャッシュインスタンスの走査に使うことがあります. そうすることで, 繰り返し作成して破棄することを避けることができます.

@Provides でなく @Inject を使う

@Provides はコンストラクタを複製すべきではありません.
関係する部分を一つにするとコードがわかりやすくなります.


@Module
class ToastModule {

  // BAD, remove this binding and add @Inject to RealToastFactory
  @Provides RealToastFactory realToastFactory(Application context) {
    return new RealToastFactory(context);
  }

}

このことは, 特に singleton においては重要です. そのクラスを読むときの重要な実装の内容一覧となります. 一部分をみればすべての内容が把握できます.


// GOOD, I have all the details I need in one place.
@Singleton
public class BadgeCounter {

  @Inject public BadgeCounter(...) {}

}

static @Provides を使う

@Provides は static にすることができます.


@Module
class ToastModule {

  @Provides
  static ToastFactory toastFactory(RealToastFactory factory) {
    return factory;
  }

}

モジュールインスタンスを作成する代わりに, 直接メソッドを実行することができます. このときそのメソッドの呼び出しはコンパイラによってインライン化されています.


@Generated
public final class DaggerAppComponent extends AppComponent {

  // ...
  @Override public ToastFactory toastFactory() {
    return ToastModule.toastFactory(realToastFactoryProvider.get())
  }

}

一つだけのメソッドを static にしてもあまり変化はないですが, すべてを static にすると, かなりのパフォーマンスが向上します.

また, モジュールを abstract にすると, static でない @provides メソッドが ひとつでもあるとコンパイルに失敗します.

@Provides よりも @Binds を使う

あるタイプを他にマッピングするときは @Provides でなく @Binds を使う.


@Module
abstract class ToastModule {

  @Binds
  abstract ToastFactory toastFactory(RealToastFactory factory);

}

このメソッドは abstract でなければなりません. @Generated コードは実装内容をそのまま使おうとします.


@Generated
public final class DaggerAppComponent extends AppComponent {

  // ...
  private DaggerAppComponent() {
    // ...
    this.toastFactoryProvider = (Provider) realToastFactoryProvider;
  }

  @Override public ToastFactory toastFactory() {
    return toastFactoryProvider.get();
  }

}

@Singleton の interface binding は避ける

Statefulness is an implementation detail

集中するアクセスがミュータブルな状態にアクセスする必要があるかは実装のみが知っていますので, 実装をインターフェースにバインドさせるとき, アノテーションをつけるべきではありません.


@Module
abstract class ToastModule {

  // BAD, remove @Singleton
  @Binds @Singleton

  abstract ToastFactory toastFactory(RealToastFactory factory);

}

error-prone を使おう

一般的な Dagger のエラーはこれを使うことで分かりやすく検出できます.

👉 MVVM で Hilt のパターン化 💉  hatena-bookmark


Android Studio エミュレータのネットワーク設定

最近は使えるのかな,とひさびさにエミュレータ...

はい,DNSエラー.

エミュレータ内にて.


generic_x86:/ $ ifconfig
lo        Link encap:UNSPEC
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope: Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:310 TX bytes:310

eth0      Link encap:UNSPEC    Driver virtio_net
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe12:3456/64 Scope: Link
          inet6 addr: fec0::5054:ff:fe12:3456/64 Scope: Site
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3506 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3523 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:270699 TX bytes:274244


generic_x86:/ $ getprop
...
[net.bt.name]: [Android]
[net.eth0.dns1]: [10.0.2.3]
[net.eth0.gw]: [10.0.2.2]
[net.gprs.local-ip]: [10.0.2.15]
[net.qtaguid_enabled]: [1]
[net.tcp.default_init_rwnd]: [60]
...

仮想ネットワークは正しく構築できているようですが.

Set Up Android Emulator Networking | Android Studio

結局これ,パソコン上のDNSに Google Public DNS アドレスを追記で繋がるようになります.

Firewall などはONのままでよいです.

DNSとして設定されたルータのローカルアドレスをうまくエミュレータ側で認識/変換できないのだろうと思われます.

ちなみに,接続成功時のパソコン内にて以下.

~$ cat /var/run/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
search flets-east.jp iptvf.jp
nameserver 192.168.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4

~ $ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
search flets-east.jp iptvf.jp
nameserver 192.168.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4

Run Apps on the Android Emulator | Android Studio

エミュレータ内にて setprop -> restart network で接続できたとしても毎回いちいち面倒です.

戻ろう、Genymotion に。
→ Genymotion 無料版 を入れる 2018


Kotlin で static なメンバーをどう書くべきなのか?

092: Learning Kotlin – dealing with static-ness and (companion) objects costs – Fragmented

「companion object」だな. と思いながらとりあえず書く.


class Foo {
    companion object {
        val myVar = "testing"
    }
}

これを Kotlin から呼ぶ場合は,


Foo.myVar

ですが, Java から呼ぶ場合は,


Foo.Companion.getMyVar();

となり クソですね.

では, Jvm アノテーション を使います.


class Foo {
    companion object {
        @JvmField val myVar = "testing"
    }
}

この場合は Kotlin/Java それぞれ同じように呼べます.


// calling from Kotlin
Foo.myVar

// calling from Java
Foo.myVar;

なるべく入れたくないですよね Jvm なアノテーション.

const キーワード を使う


class Foo {
    companion object {
        const val myVar = "testing"
    }
}

以下, 共に問題ありません.


// calling from Kotlin
Foo.myVar

// calling from Java
Foo.myVar;

同様に, パッケージレベルでは,


class BottomSheetView {
    companion object {
        const val BOTTOM_SHEET_ANIMATION_TIMING = 500L
    }

    // ...
}


animation.setTiming(BottomSheetView.BOTTOM_SHEET_ANIMATION_TIMING)

Companion object is initialized from the static constructor of the containing class and plain object is initialized lazily on the first access to that object.

こんなかんじでしっくりくる記述って見つけにくい気がしません? Kotlin て.

“Static constants” in Kotlin | Kotlin Blog