2025年6月11日水曜日

移行予定

どうも。どっことです。

タイトルの通りですが、諸事情により GitHubPage に移行予定です。

https://mkt120.github.io/

この備忘録に記載の内容を転記しつつ、今後はこちらのページを更新していく予定です。


2025年5月5日月曜日

Android gradle.properties に定数を入れる

どうも。どっことです。今回はgradle.propertiesを使った設定値の管理方法について紹介します。

gradle.propertiesで設定値を管理する

gradle.propertiesを用意し定数値感覚で設定すれば、アプリのバージョンやtargetVersion/minSDKVersionなどの値を一つのファイルで管理させることができます。

設定方法

例えば以下のbuild.gradleにあるマジックナンバーを定数化しgradle.propertiesに移して参照しましょう。

android {
    namespace = "com.mkt120.sampleapplication"
    compileSdk = 35
    defaultConfig {
        applicationId = "com.mkt120.sampleapplication"
        minSdk = 26
        targetSdk = 35
        versionCode = 100
        versionName = "1.0.0"
        ... 
    }
    ... 

gradle.propertiesに外出しする定数を記述します。

ANDROID_SDK_VERSION=35
ANDROID_MIN_SDK_VERSION=26
ANDROID_VERSION_NAME="1.0.0"
ANDROID_VERSION_CODE=100

上で配置した定数をbuild.gradleで参照します。

android {
    namespace = "com.mkt120.sampleapplication"
    compileSdk = Integer.parseInt(project.ANDROID_BUILD_SDK_VERSION)

    defaultConfig {
        applicationId = "com.mkt120.sampleapplication"
        minSdk = Integer.parseInt(project.ANDROID_MIN_SDK_VERSION)
        targetSdk = Integer.parseInt(project.ANDROID_BUILD_SDK_VERSION)
        versionCode = Integer.parseInt(project.ANDROID_VERSION_CODE)
        versionName = project.ANDROID_VERSION_NAME
        ...        
    }
    ...

gradle.propertiesに記述した定数はproject.XXXXXの形式で参照することができます。

まとめ

今回はgradle.propertiesを使った設定値の管理方法について紹介しました。

参考

2025年4月19日土曜日

Android そういえば Kotlin Coroutine ってどう使うのが良いの?

どうも。どっことです。今回はKotlinCoroutineのテーマです。

Kotlin Coroutine

Kotlin Coroutineは非同期処理などのコールバック地獄を解消してくれたり、可読性の高いコードを実装できるようになる便利な機能ですが、「実際のところ、どう使うのが良いの?」と考えました。今回はそんな使うと便利だけど実際どう使うかイマイチ分からない人向けに、ベストプラクティスのページの内容を簡単に紹介したいと思います。

TL;DR(結論)

ViewModelを実装してviewModelScope.launch/View側ではlifecycleScope.launchを使うのがよさそうです。

Google開発者サイトでコルーチンに関するベストプラクティスが紹介されています。コルーチンにフォーカスしたものだと、以下が挙げられています。

  1. Dispatcherを外から注入できるようにする
  2. ViewModelでコルーチンを作成する
  3. GlobalScopeは使わない
  4. コルーチンをキャンセルできるようにする

Dispatcherを外から注入できるようにする

withContextなどで引数に設定するDispatcher(どのスレッドで処理するかの指定)は、ハードコードせず外から注入できる形にした方が良いです。テストコードを実装するときにテストが容易にできるようになります。

// OK:処理するDispatcherを外から指定する
class SampleRepository(private val ioDispatcher: CoroutineDispatcher =  Dispatchers.IO) {
    suspend fun veryHeavyTask() = withContext(ioDispatcher) {
        // very heavy task
    }
}
class SampleRepository() {
    // NG: Dispatcherをハードコード(直接指定)しない
    suspend fun veryHeavyTask() = withContext(Dispatchers.IO) {
        // very heavy task
    }
}

ViewModelでコルーチンを作成する

ViewModelを作成し、そこでコルーチンを作成→非同期処理を実装するのがよいとのことです。

そして画面側に非同期処理が必要なことを意識させることがないよう、suspend関数として公開しないよう実装するのが良いとのことです。

class SampleViewModel(): ViewModel() {
    private val repository = SomeRepository()

    // NG:UI側にsuspend関数(=非同期処理)として公開しない
    suspend fun badSample() = repository.veryHeavyTask()

    // OK:ViewModel内でコルーチンを生成し非同期処理を実行する
    fun sample() {
        viewModelScope.launch {
            repository.veryHeavyTask()
        }
    }
}

GlobalScopeを使わない

テストコードの実装しにくさ、GlobalScopeをハードコードしていることによりDispatcherもハードコードされやすくなる点などから、GlobalScopeを利用しないことを推奨しています。

class SampleRepository() {
    fun veryHeavyTask() {
        // NG:GlobalScopeをハードコードしない
        GlobalScope.launch {
            // very heavy task
        }
    }
}

GlobalScopeの利用が正当であるケースはかなり稀で、アプリが生存期間中にアクティブな状態を維持しなければいけない状態とのことです。また、現在のスコープより長い生存期間が必要な処理であれば、CoroutineScopeを外部から指定するような構成とすることを検討すべきとのことです。

コルーチンをキャンセル可能にする

コルーチンはキャンセル可能ですが、実際コルーチン内でキャンセルされたか確認したり、停止したりするまではコルーチンはキャンセルされないとのことです。ensureActiveを使用することでキャンセルの確認ができます。

class SampleViewModel(): ViewModel() {
    private val repository = SampleRepository()

    fun sample(value: Int) {
        viewModelScope.launch { 
            val result = repository.validateValue(value)
            // キャンセルできるタイミングでアクティブか確認
            ensureActive()
            if (result) {
                repository.submit(value)
            }
        }
    }
}

まとめ

今回はKotlinCoroutineのベストプラクティスについて紹介しました。より詳しい内容は参考に記載したGoogleのベストプラクティスの記事からさまざまなページにアクセスできるので、ぜひ参考にしてください。

参考

2025年3月30日日曜日

Android Studio VCS Operations Popupをカスタマイズする方法を解説

どうも。どっことです。今回はAndroid StudioにあるVCS Operations Popupにカスタマイズ方法ついて解説します。

VCS Operations Popopとは

VCS Operations PopupはAndroid Studioでバージョン管理ツールの操作するときのポップアップです。control+vのショートカットで表示することができます。メニューから操作する手間が省けるので、多用している人もいるかと思いますが、今回はこのポップアップをカスタマイズする方法を解説します。

VCS Operations Popopのカスタマイズ

カスタマイズですが、実はAndroid Studioがカスタマイズするための設定項目を用意してくれています。なので謎の設定ファイルの書き換えや、ターミナルなどでの謎のコマンド操作は不要です。(地味に嬉しい)

Android StudioのSettings | Appearance & Behavior | Menus and Toolbarsにアクセスしてください。プロジェクトにGitを利用している場合は以下のようなポップアップが表示されると思います。

この画面で項目をカスタマイズすることができます。一覧の中にあるVCS Operations PopupからVCS.Operations.Popup.VcsAwareを選択している状態で+ボタンをクリックしましょう。

ここから項目を追加することができます。たとえば、Update projectをリストに追加してみましょう。一覧からUpdate projectを探してOKをクリックしてください。それで完了です。

それではVCS Operations Popupを表示してみましょう。control+vを入力すると...


追加したUpdate projectがポップアップに追加されていることを確認できました!これでいちいちVCSメニューまでマウス移動させる手間が省けますね!

まとめ

今回はAndroid StudioにあるVCS Operations Popupのカスタマイズ方法について解説しました。Android Studioや、そのベースとなっているIntellij IDEAでは、このポップアップに限らず、さまざまな項目をカスタマイズする設定画面を提供しているので、作業効率がより良くなるようどんどんカスタマイズしていきたいですね。

参考

2025年3月29日土曜日

GitHub ライブラリをGithubに公開する方法を解説(GitHub Packages)

どうも。どっことです。今回はGitHub Packagesを使って自作ライブラリを簡単に公開する方法を解説したいと思います。

プライベートで資格試験などに向けた問題集アプリを不定期に作るのですが、毎回データクラスや画面を一から作っているので「そろそろ標準化しよう。。。」と思いました。ただ標準化したはいいものの、いい感じに使い回すためにはどうしたらいいか、というところで調べた結果、GitHub Packagesのサービスに行き着いたので今回はこちらを紹介し、実際に公開する方法を解説したいと思います。

GitHubPackagesとは

GitHubPackagesはGitHubのサービスの一つで、まさに今回のようなライブラリや、パッケージなどを共有するためのものだそうです。mavenやnpm、NuGetなどの形式で公開することができます。しかも嬉しいことに公開範囲も指定できるようで、一般公開からプライベートやTeam限定など、制御することができるとのこと。とても便利。

今回はJava向けのライブラリを公開するために、Gradleプラグインを使った手順を紹介したいと思います。

GitHubPackagesにライブラリを公開する設定手順

以下の手順で進めます。

  1. app/build.gradleに設定を追加する。
  2. Gradleタスクを実行する。
  3. (任意)GitHub Actionで自動的に更新する。

順番に解説していきます。

app/build.gradleに設定を追加する

app/build.gradleに以下を追加します。

plugins {
  ...
  id 'maven-publish'
}

publishing {
  ...

  repositories {
    maven {
      name = "GitHubPackages"
      url = "https://maven.pkg.github.com/mkt120/sample_repository"
      credentials {
        username = System.getenv("USER_NAME")
        password = System.getenv("ACCESS_TOKEN")
      }
    }
  }
}
  • pluginmaven-publishを追加。ライブラリ公開を簡単に実行してくれるプラグインを組み込む。
  • urlはGitHubのリポジトリURL。
    • GitHubのリポジトリに対応したURLを設定。
  • usernamepasswordはログイン情報。
    • 特にpasswordはログインパスワードだと警告orエラーが発生するので、Githubからアクセストークンを取得しそれを設定する。直書きだとセキュリティ観点でリスクがあるので、Githubの secret and variables に設定しておいて、それを参照するようにしておくのが無難。

Gradleタスクを実行する

前項の設定を追加し、sync gradle を実行すると以下のタスクが追加されます。

publishGprPublicationToGitHubPackagesRepository

これをコマンドラインやGradleペインから実行することで、 GithubPackagesへの登録が行われます。

./gradlew publishGprPublicationToGitHubPackagesRepository

(GithubPackageによると)以下のタスクはGithubPackagesへの登録だけでなく、その前段階のライブラリのビルドなども一緒に実行してくれるようなので、こちらを利用するのが良さそうです。

./gradlew publish

(任意)GitHub Actionで自動的に更新する

ここまでだけでGitHubPackagesにパッケージを登録することができますが、GitHubにコミットをプッシュしたことを契機に、GitHubPackagesに更新を入れるようGitHub Actionで自動登録できるようにしておきます。

#masterブランチにプッシュされたら実行
on:
  push:
    branches: [ "master" ]
  ...

jobs:
  build:
  ...
  
  # name. githubAction のコンソール上で実行内容がわかりやすいように名前付けしておく
  - name: publish library 
    run: ./gradlew publish
    env:
      USER_NAME: ${{ secrets.USER_NAME }}
      ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}

まとめ

今回はGitHubPackagesにライブラリを公開する方法を解説しました。似たようなデータ形式・UIのアプリケーションをたくさん開発している方は、こういった機能を活用することで開発作業の効率化を図りたいですね。また、ライブラリ化したはいいけど、maven repository に登録するほどのものではないんだよなぁ...という方にも、GitHubPackagesという公開範囲を管理できる領域に登録することで適切にスケーリングすることもできるのではないかと思います。

参考

移行予定

どうも。どっことです。 タイトルの通りですが、諸事情により GitHubPage に移行予定です。 https://mkt120.github.io/ この備忘録に記載の内容を転記しつつ、今後はこちらのページを更新していく予定です。