ログ出力をクリッカブルにして該当行に素早く移動

Android Studio でのログ出力.

任意の文字列を出力する場合は,


Log.d("TEST", "テスト")

と書いておくと,

となります.

Kotlin では,


println("TEST テスト")

と書いてあげると,

となります.

以下のような文字列にすると,


println("TEST https://google.com/")

println("TEST (MainActivity.kt:100)")

と表示されて,

それぞれブラウザの該当ページや,

該当ファイルの該当行に直接クリックで遷移できるようになります.

ここで,

Exception().stackTrace[1]

を使うと, 記述した位置の該当ファイル名と行数が取得できるので,

インラインなユーテリティにします.


class LogUtils {

  companion object {

    private const val TAG : String = "TEST"

    @JvmStatic fun d(message: String) = Log.d(TAG, appendFileLine(message))
    @JvmStatic fun d(message: String, t: Throwable) = Log.d(TAG, appendFileLine(message), t)

    @Suppress("NOTHING_TO_INLINE") // ?
    private inline fun appendFileLine(message: String): String {
      val frame = Exception().stackTrace[1]
      return "$message (${frame.fileName}:${frame.lineNumber})"
    }

  }

}

あとは, 表示したいメッセージとともにお好みの場所で


LogUtils.d("テスト")

と書いておけば,

となって便利にデバッグに使えたり.


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


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